I'm trying to make a web socket connection on my webserver. The connection is run from a client in javascript and connects to a php script on the webserver. The javascript is also placed on the webserver, but runned from a clients webbrowser.
The problem is that hostgator doesn't allow inbound socket connections unless you buy a dedicated server, but I'm not aware if this counts as an inbound socket connection.
So does anyone know if this counts as an inbound socket connection or any other web hosting sites that would allow inbound connections?
Thank you in advance :)
A websocket connection starts life as an incoming HTTP connection (usually on the same port as is being used for web requests) with some custom headers on it which is something all web servers have to be configured to accept (or they wouldn't be any use as a web server). After a brief exchange with the client, the client requests an upgrade and a switch to the websocket protocol (the initial connection was the HTTP protocol). That connection which started life as an HTTP connection then becomes a webSocket connection (if the web server agrees to the protocol switch).
So, yes it is an incoming connection to the web server, but it's an incoming HTTP connection which your web server has to already accept. webSockets were designed this way on purpose to make them highly compatible with existing HTTP networking infrastructure, firewalls, etc... so they could be used by only upgrading the HTTP server software (to support the webSocket protocol) and not changing any of the networking infrastructure.
FYI, there are other hosting issues with using webSockets. A webSocket is a continuous, long lasting socket connection. In order to use it, you typically need a continuous, long lasting server process. Many of the lower cost, shared hosting environments do not support that. They tend to accept an incoming HTTP request, dispatch it to whatever script it is supposed to run (e.g. a PHP script), let it run on that request and then the script exits and your server process does not continue to run. This works well for low cost, shared hosting because no server resources are consumed by your app when it is not actively in the middle of serving a page. But, that model won't work for webSockets where you must have a continuous server process for the webSocket to be connected to.
I don't know specifically about hostgator, but this is another issue to look into. On my shared hosting on Dreamhost, I cannot have a long running server process. On Dreamhost this requires a VPS hosting plan and from what I've read this is common for other shared hosting environments too.
Related
I am trying to build an app to retrieve data from a local database, The structure of the app that I have a mobile app, server(on a hosting service), and local server(on my pc), I am trying to make the mobile app request data from the server via a normal HTTP request then the server request the data from the local server but the problem that I could not be able to connect with my local server I believe that I could not connect to my local server because my local server does not have a public IP, so I am trying to find a better way to achieve my idea.
I read something about Websocket but I don't know if it suitable for my idea beacuse it is Bi-directional connection and It most used for chatting app
I want to build the app with NodeJs, so what should I do to implement this idea, and thank you for the help.
Each server is on a different network the main server is on Heroku host and the local server is on my personal computer
Life would be a lot easier for you if you move your local server to Heroku where they can much more easily and securely talk to one another.
You can't connect from your Heroku server to the server on your private local network because it is behind a firewall in your home router. To allow such a connection, you have to configure a known public IP address for your home network (that won't change or use DDNS if it can change) and configure port forwarding in your firewall/router so incoming connections from the internet on a specific port can reach your local server. You will then have to harden your local server against random internet attacks since it will then be open to the internet.
One other possibility is that you could have your local server connect to your Heroku server (perhaps with a webSocket connection using some sort of secret credential). Since your Heroku server is already reachable from your home network, this would require less networking configuration change. Depending upon what you're trying to do between the two servers, you could either have the local server just make a regular http request to the Heroku server (either sending data or asking for data) or you could make a webSocket connection and then data can be sent either way of the webSocket connection.
I'd like to know if there's any way to establish a P2P connection between two browsers using socket.io-client (but I'm willing to use anything else that may do the trick).
Both browsers are currently connected to a node.js app serving HTTP requests with Express, which stores both clients's IP addresses (and ports when running locally). What I'd like to do is add a third connection that links both clients (let's call them A and B) directly, so that messages/data will go straight from one client to another, without transiting through the node.js server.
Is that feasible? If so, how?
So far, I've tried connecting the two clients (let's call them A and B) with the following code:
Client A:
A_to_server_socket = io();
A_to_server_socket.on('p2p', function(address_B){
A_to_B_socket = io(address_B); // Instantiates a new socket
A_to_B_socket.on('connect', function() {
console.log('Connected!');
});
});
I'm not sure about the code for client B. However I've tried:
repeat the above code for B, using B's own address (to override the default of connecting to the server)
repeat the above code for B, this time using A's address
having B_to_server_socket listen for a new connect event
However regardless of B's code, when running A's code I'm confronted with a "Cross-Origin Request blocked" error on Firefox, or "Failed to load resource: net::ERR_CONNECTION_REFUSED" followed by "net::ERR_CONNECTION_REFUSED" on Chrome.
Any hints towards a solution, or insights for better understanding the problem and how sockets work would be most welcome.
I'll try to summarize my comments into an answer.
In TCP, a connection is made when one endpoint A connects to another endpoint B. To connect to endpoint B, that host must be "listening" for incoming connections originating from other hosts. In a typical web request, the browser establishes a TCP connection to the web server and this works because the web server is listening for incoming requests on a specific port and when one of those requests comes in, it accepts the incoming request to establish an active TCP connection. So, you must have one side initiating the request and another side listening for the request.
For various security reasons, browsers themselves don't "listen" for incoming connections so you can't connect directly to them. They only allow you to connect outbound to some other listening agent on the internet. So, if a browser never listens for an incoming webSocket connection, then you can't establish a true peer-to-peer (e.g. browser-to-browser) webSocket connection.
Furthermore, TCP is designed so that you can't have two browsers both connect to a common server and then somehow have that server connect up their pipelines such that the two browser are now just wired directly to each other. TCP just doesn't work that way. It is possible to have an agent in the middle forwarding packets from one client to another via a separate connection to each (that's how Chat applications generally work), but the agent in the middle can't simply plug the two TCP connections together such that the packets go directly from one client to the other (and no longer go through the server) as a fireman would connect two firehoses. TCP just doens't work that way. It might be possible to have some complicated scheme that involved rewriting packet headers to a packet sent from endPoint A was forwarded to endPoint B and looked like it came from the server instead, but that still involves the server as the middleman or proxy.
The usual way to solve this problem is to just let each browser connect to a common server and have the server act as the middleman or traffic cop, forwarding packets from one browser to another.
Existing P2P applications (outside of browsers) work by having each client actually listen for incoming connections (act like a server) so that another client can connect directly to them. P2P itself is more complicated than this because one needs to have a means of discovering an IP address to connect to (since clients typically aren't in DNS) and often there are firewalls in the way that need some cooperation between the two ends in order to make the firewall allow the incoming connection. But, alas, this capability of listening for an incoming connection is not something a browser from plain javascript will allow you to do.
There is no something like "connection between two browsers using socket.io-client."
But there is "Both browsers are connected to a node.js app serving HTTP requests with Express, which keeps track of both clients's IP addresses (and ports when running locally)."
If you want to have P2P connection between two browser, following may be a way to do so.
when you get client A connection, join to a room "P2P"
when you get client B connection, join to a room "P2P"
to exchange between client A and client B, use
socket.broadcast.to('P2P').emit("message", "Good Morning");
Hope this may help.
I begin with this technology. I want to establish a TCP/IP connection with an electronic card that has an IP address (the server's map).
I wonder if the WebSocket allow me to make this connection, knowing that at present my interface communicates with the card through a socket implanted in an applet.
Does anyone know the syntax to connect with WebSocket as a parameter an IP address: 135.120.138.105
Thank you
WebSockets are not raw TCP sockets. They have many of the same characteristics (low overhead, persistent, bidirectional, full-duplex) as raw TCP sockets, but they have an initial HTTP-like handshake to implement CORS security and allow easier integration with web servers and existing firewall policies. WebSockets are also message based and have a small header on each frame (2 bytes overhead for small payloads).
You have a couple of options. You can use a program that bridges/proxies between WebSockets and raw TCP sockets such websockify (Disclaimer: I made websockify) or you can implement the server side of the WebSocket protocol in your server.
WebSockets won't work in your case. While they use TCP/IP, WebSockets have a different API that's designed for higher-level messages to be passed between server and client and it requires support on the server as well, so unless the card contains a WebSocket-enabled web server I think you're out of luck and you'll have to continue with your applet-based design.
I don't quite know how to search this in google:
"client to client websocket connections"
"browser to browser websockets"
"websockets without a server"
Haha, is there a way for someone on a webpage in the browser to communicate directly to another person on a web page in the browser, without touching the server?
I am very familiar with socket.io, but that requires all clients emit messages to the server, which can broadcast them to the other connected clients. I am not familiar with the details of web sockets though, so maybe there's a way to communicate without sending messages through the server.
Is this possible? I just want to know the scope of web socket functionality, the limits you can take them too, etc.
Not Web Sockets, but four years later and now we've got browser-to-browser communication!
http://www.webrtc.org/
There are JS libraries built around it to make it easier (e.g. https://simplewebrtc.com/). However, it does still require a server to orchestrate connections.
I know this question is ancient, but it showed up in Google when I searched so it likely will for others!
This is not possible, you have to have the server in the middle.
For an application to accept connections, it has to have a server port open and listening for incoming requests. You cannot have a server socket exposed from a browser. I dont know if you can expose a server socket from within an applet. But even if you could, you would need to know the IP address of the other client for establishing a peer to peer connection.
Well, technically when you broadcast, the client emits to the server, the server broadcasts to everyone. I don't think with the current architecture of the web peer to peer connections like this is possible.
But it is possible that a client send a message to server specifying another client ID, and the server sending it to the other clients using sessions.
The moment you have a client listening for websockets (which you have to do in other to communicate), it becomes a server.
I have been thinking about building a client to client program. But the way I want is to use the broswer to do it, helped by a server that can make that connection.
The troubles comes when I need to have an unnconected socket (or pasive) in a client, waiting for a connection.
I have been thinking about Html5 WebSockets, but it doesn't give to the client the posibility of having a pasive socket without connecting it with a TCP protocol.
I'm learning this and trying to find the way to do this. All ideas are wellcome :D.
You can have a passive socket in Java applets, Flash and other browser plugins, but in general that can be problematic for public web applications.
First of all it will be difficult to get through firewalls, etc, and you'll need to depend and write code for a browser plugin that implements a socket API, and bridge it to JavaScript. If you are interested in some solutions, you may want to check out the following Stack Overflow post:
How can I communicate over TCP sockets from JavaScript?
The traditional approach for peer-to-peer communications between browsers is to have your server acting as a gateway for all the connections. Browsers initiate the connection (either with WebSockets or with XMLHttpRequest) and keep an active connection to the server at all times, re-establishing it if it drops. Since the server application will always find an open TCP connection to all the connected browsers, it can easily route messages to/from all clients.
As Daniel says, you are going to have a very hard time trying to do true peer-to-peer (a la Skype etc) in the browser, and it is certainly not possible without the use of plugins. And even Skype etc rely on falling back to a server acting as a gateway when a direct connection cannot be established (due to firewalls etc).
So you really need to have a gateway server regardless, and that there are a number of options. Try searching here for 'comet'. Some options that I have played with include Orbited (http://orbited.org/) and Hookbox (http://hookbox.org/) but there are many others.