From javascript browser client-side to Postgresql [duplicate] - javascript

I have a c# tcp server, I want to connect to the server via a html client page.
The problem: There is no simple way to create TCP sockets in Javascript on a browser side. Although solutions like Websockets allow to create something that resemble sockets, you can use them to connect only to servers that support Websockets. Not to any random servers that know nothing about HTTP.
so is there a solution to connect to my srver.

No. There just isn't. The browser is a tightly locked down environment. The only socket connection that you can open from JavaScript is WebSocket. Since it's your server, adding WebSocket support shouldn't be too complicated, and there are WebSocket libraries available for C#.

Maybe someone else will have an idea for you, but...
The best solution I can think of is for your server to support websockets.
The situation you described - along with connectivity issues for traffic passing through proxies and routers - is one of the reasons Websockets were introduced in the first place.
Bare in mind that Websockets can send and receive binary data. It's just that javascript make it more comfortable to write text based messages.
Also, many NAT routers, Proxies and firewalls will block raw TCP/IP communication while allowing Http communication to pass through. This is why you have a better chance at connection establishment and retention when implementing the Websocket protocol.

Related

Is there a browser-based Websocket listener implementation?

I am interested to know if anyone has built a javascript websocket listener for a browser. Basically the server side of a websocket that runs in a client. This would allow messages to be sent to the client directly. Why? Because instead of having a Node.js, python, java, etc, server process sitting on or near the client/browser, I can just use a thread in the browser as a listening server thread. I don't think that any browsers support this currently.
I've run across answers like this: https://news.ycombinator.com/item?id=2316132
Just curious if anyone has done this. I believe that the current Websockets spec does not support listeners on the browser. It would make the deployment of various peer-to-peer applications a bit easier to deploy.
WebRTC allows for peer-to-peer connections to be made between browsers.
You would still need a server in order for individual users to discover each other but then they could connect directly to each other rather than having to pass all their traffic via a central server.
The idea.
You can use a simple echo server written in any language. Your script can send the data to the server then get it back, handle it on the same page with different functions/classes emulating the real server.
An example: http://www.websocket.org/echo.html
Then, you can think about different formats of packets to/from server to diffirentiate them inside one script.

html javascript connect to raw socket

I have a c# tcp server, I want to connect to the server via a html client page.
The problem: There is no simple way to create TCP sockets in Javascript on a browser side. Although solutions like Websockets allow to create something that resemble sockets, you can use them to connect only to servers that support Websockets. Not to any random servers that know nothing about HTTP.
so is there a solution to connect to my srver.
No. There just isn't. The browser is a tightly locked down environment. The only socket connection that you can open from JavaScript is WebSocket. Since it's your server, adding WebSocket support shouldn't be too complicated, and there are WebSocket libraries available for C#.
Maybe someone else will have an idea for you, but...
The best solution I can think of is for your server to support websockets.
The situation you described - along with connectivity issues for traffic passing through proxies and routers - is one of the reasons Websockets were introduced in the first place.
Bare in mind that Websockets can send and receive binary data. It's just that javascript make it more comfortable to write text based messages.
Also, many NAT routers, Proxies and firewalls will block raw TCP/IP communication while allowing Http communication to pass through. This is why you have a better chance at connection establishment and retention when implementing the Websocket protocol.

Why we have WebSockets but have not simple Sockets in Web? [duplicate]

I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them. "ws:"
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Here are my random stabs in the dark
Applets sockets provided by Java (need java installed)
Flash sockets provided by Flash (need flash installed)
But about HTML5, Why are they called WebSockets if they aren't Sockets?
Is the websocket protocol so simple to implement that it is "almost"-sockets?
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them.
[Is the] websocket protocol so simple to implement that [it is] "almost"-sockets?
Allowing regular socket connections directly from the browser is never going to happen because it opens up a huge risk. WebSockets is about as close to raw sockets from the browser as you are going to get. The initial WebSockets handshake is similar to an HTTP handshake (allowing web servers to proxy/bridge it) and adds CORS type security. In addition, WebSockets is a message based transport (rather than streaming as raw TCP) and this is done using a two byte header on each message frame.
Even flash is not able to quite make raw TCP connections. Flash sockets also add CORS security, but instead of an in-band handshake, flash socket connections make a connection to port 843 on the target server to request a security policy file.
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Yes, you can use my websockify bridge/proxy which allows a WebSockets enabled browser to connect directly to a TCP socket via websockify.
But about HTML5, Why are they called WebSockets if they aren't Sockets?
WebSockets are a transport built on TCP sockets. After the handshake there is very minimal overhead (typically just a two byte header).
I can't improve on Kanaka's answers to your secondary questions, and I know this question is a year old. But for the main question, Is there any way of doing a pure socket connection from a web browser, to enliven webpages? There is a project called the Java / JavaScript Socket Bridge that might be what you (or anyone coming across this page from a Google search) are looking for. The advantage of this method over what others have mentioned is that it does not require either a client-side or a server-side service to be run. So, for instance, if you wanted to implement an IRC client purely in JavaScript but your web host does not allow you sufficient rights to proxy the connection, this Java applet would be the way to go. The only concern is making sure the client has Java installed and allowed.
You can just send data between a client and a server with WebSockets. Simply speaking, the only difference that WebSockets introduces is that the client:
adds some header bytes, like the type of data and the length
adds masks and encodes the data using them
The server also has to add header bytes, but does not need to encode the data.
If you implement the protocol correctly (server side, that is, since the browser already has an implementation), you can use it with ease to send text and binary data. (Although browser support is narrow, especially for the latter.)
The benefit of WebSocket is that it is HTTP based. You can use it also in environments there http proxies are used. Thus Websocket has a higher infrastructure compatibility as plain tcp.
Additionally http/WebSocket is providing you some features which you otherwise have to specify on your own:
Redirect
NAT keepalive
Multiplexing via URI
Framing
If you are asking for some data to be pushed from server it is widely termed as COMET or Reverse Ajax.
Web sockets is still not very popular as there are inherent firewall issues and minimal support yet from popular browsers.
You can take a look at http://www.ape-project.org/ as this is one of the most popular implementations (but native to unix/linux only for now. For windows they suggest using a virtual box or vmware based implementation)

What role does Socket.IO have with Node.js

I'm fairly new to the world of JS and its abundance of libraries. I'm looking to get into a project that involves network communication (sockets) between clients and a server. In a world with tons of libraries, I cannot make a decision as to which to use. I'm looking for something that will bring efficiency and stability.
I've been told that Node.js is like the middleman between you, as the developer, and Socket.IO. I've been told it's a huge framework that you may not use at least half of. I've been told that to maximize efficiency, you're better off using Socket.IO to make your own functionalities. I've done some research on my own and found that Socket.IO NEEDS Node.js and Node.js DOESN'T NEED Socket.IO. Which is completely opposite of what I was told. Then I find that most developers use both Socket.IO and Node.js at the same time?
Like I said, I'm fairly new, but I cannot find the right resources that would help me accomplish a websocket communication between a client and a server with maximum efficiency, or at least explain the difference between Socket.IO and Node.js. If anyone here could, please let me know! I would greatly appreciate it.
node.js is a general purpose javascript-based run-time environment (somewhat similar to other language runtimes like python in scope). You can create apps in it that don't even use the network. It is often used as a web server for created web apps and has a great set of tools and rich library of add-ons for doing so. It does not need socket.io.
socket.io is a specific library to enable web-socket-like communication between a client and a server (e.g. a chat room app is the canonical example). The server side of socket.io assumes a javascript run-time (because it's written in javascript) so that generally means node.js (though I'm not sure if a different JS runtime could perhaps be substituted).
You can think of node.js like the platform and socket.io like a specific tool to do a specific job that runs on that platform. You would use socket.io (on top of node.js) if you needed web socket connectivity between client and server.
You would use only node.js if you need any of the other things node is good at, but did not need websocket connectivity.
websockets themselves can be programmed on the server side without socket.io and without node.js. They could be programmed in strait C++ or in Java. But socket.io (running in node) provides a very easy way to set them up because the socket.io library covers both client and server in one library and one API and it's all in the same language (javascript). Look at the chat room app example on the socket.io site and you will be unlikely to find any other solution that can accomplish that in as few lines of code as it does and with the same interface on client and server.
If you were only setting up a websocket server (no web server or web app of any kind), you could still use node and socket.io and use it just for the websocket server and it would still be quite efficient. While node is capable of doing lots of other things, if you don't configure and install all those other things, they aren't costing you anything - they are just unused capabilities that aren't running.
I should add that one other thing the socket.io library does is it handles an auto-negotiation between client and server to find the best channel for the client and server to communicate on. If websockets are available, then socket.io will likely use them, but if web sockets are not available, socket.io has alternate methods that will work (even in older browsers). That functionality comes for free in socket.io without you even doing anything.
In case this isn't completely clear to you, websockets are typically used to provide real-time communication between client and server. While clients can ask for data from a server at any time with an ajax call or a web page request, what websockets allow is a two way real-time communication between client and server and the biggest advantage of websockets is that a server can send a client real-time data at any time while they are connected.
For example, I have a web page that receives real-time data from my server anytime the web page is open. The web page is served over the typical node.js web server installation, but the real-time data is sent from server to client over a websocket connection.
In addition, if there's a chatty conversation happening between client and server, websockets can be much more efficient than a series of ajax calls because with a websocket, a connection is opened once and used repeatedly whereas with ajax, each successive ajax call is like a new connection.
Node.js is a runtime environment. It's a javascript engine with a standard library built around asynchronous I/O. It plays the same role that Java, Python, Ruby, .NET, etc., play for many other web applications.
I've been told it's a huge framework that you may not use at least half of.
It might be true that most people never use most of the standard library, but I wouldn't think it's more true of Node.js than other runtimes. "Framework" isn't an accurate word to describe it.
I've been told that to maximize efficiency, you're better off using Socket.IO to make your own functionalities.
Whoever told you that was mistaken, or meant that to maximize efficiency, you're better off using [Node.js and] Socket.IO [instead of other solutions]. Many other non-Node.js solutions require a single thread or process per connection, which limits the number of simultaneous connections a server can handle. Node.js is built around asynchronous I/O which is better for keeping many connections open at once, and Socket.IO is a library for Node.js for using WebSockets.
TL;DR: Socket.IO can fire events in realtime between your client and server, so there is no need for you to reload the page to notice something changing. This can be used for "live" applications like collaborative drawing, live chats, online games and more!

Communication with javascript and localhost

I have a JavaScript code running on internet browser and in the same machine in local host is running a python code.
I need to find a way to communicate between them.
Socket client-server is not possible because JavaScript donĀ“t support sockets.
How to Use Sockets in JavaScript\HTML?: "There is no facility to use general-purpose sockets in JS or HTML. It would be a security disaster, for one."
And communication through server not interest me. I need a direct communication on localhost.
Is there any way to communicate with JavaScript and localhost without sockets?
No, by the definition JavaScript cannot use TCP/IP sockets because that would be super super big security hole in the web security model.
You can use
HTTP requests (AJAX)
WebSockets
WebRTC
... to communicate with localhost. The easiest solution is to spin up a SimpleHTTPServer and then make JavaScript AJAX requests against it.
Please note that these communications might not work with HTML files opened file:// and you might need to use a local dev server.
httprelay.io requires no additional libraries and can be used for simple http client to client communication. In your case on browser side use AJAX calls and on Python side use any HTTP client.

Categories

Resources