I have built a website with PHP + Apache + JS + HTML 5. Now there is a point where I have to tell the user every second if the server is connected and ready to receive data and/or internet connection is lost/available or whatever else which can tell the user to not to send data to server because of unavailability of Server or internet connection.
For this purpose I can either move to Long Polling with Ajax and keep pinging my server every second but surely this will cause alot of network overhead on my Apache Server where my clients are about tens of thousands live at a time so keep pinging the server is not a good option. Therefore, I decided to use WebSockets.
I have been googling for about 2 days but yet could not find enough good article to answer my 3 basic questions regarding WebSocket and Apache + PHP.
1) If once the WebSocket connection is made with server, then does it remain active like Long Polling with Server or what is the mechanism behind it? I mean how does WebSocket maintain its relation with server does it keep polling with server and hence there is always a connection between Client and Server?
2) If your answer to above question is yes then what network/IO overhead would be on server side if I use websockets because there is a continuous connection between Client and Server. And imagine if there are hundreds of thousands of clients online at a time what load will it create on Server Network or IO?
3) What is the Best approach to use WebSockets when using Apache + PHP on server? Any good article on this where I can study how to communicate with Apache Server using WebSockets? I found this question, but it doesn't answer well Using WebSocket on Apache server. In this question, it limits the experts to not to include any answer which has sysadmin tools, while I am asking for it if any required.
I have a VPS Server so tunning and installing some tools isn't a problem.
Any help would be highly appreciated. Thanks with Regards.
1) If once the WebSocket connection is made with server, then does it remain active like Long Polling with Server or what is the mechanism behind it? I mean how does WebSocket maintain its relation with server does it keep polling with server and hence there is always a connection between Client and Server?
Yes, it remains active and there is always a connection between Client and Server. However, the client needs to maintain the connection and on connection exceptions. In this case, it is your javascript code.
2) If your answer to above question is yes then what network/IO overhead would be on server side if I use websockets because there is a continuous connection between Client and Server. And imagine if there are hundreds of thousands of clients online at a time what load will it create on Server Network or IO?
WebSocket connections are handled on TCP/IP level and by definition, they are not resource consuming operations when there is no data going through the TCP tunnel. So rather than worrying about your CPU and memory conception, you need to worry about the limit on the number of connections. Consider using a load balancer for your socket connections and utilize multiple servers if you are expecting more than 10000 concurrent connections.
3) What is the Best approach to use WebSockets when using Apache + PHP on server? Any good article on this where I can study how to communicate with Apache Server using WebSockets? I found this question, but it doesn't answer well Using WebSocket on Apache server. In this question, it limits the experts to not to include any answer which has sysadmin tools, while I am asking for it if any required.
For such a use case of yours - getting the status of the server, I would suggest using a message broker rather than load this simple operation to Apache.
Please consider looking at mosquitto, hivemq or rabbitmq
All of them are supporting WebSockets and all of them have their pros and cons. Do the small proof of concepts over them and choose what is best for you.
Related
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.
I am building a small chat application for friends, but unsure about how to get information in a timely manner that is not as manual or as rudimentary as forcing a page refresh.
Currently, I am implementing this using simple AJAX, but this has the disadvantage of regularly hitting the server when a short timer elapses.
In researching long/short polling, I ran across HTML5 WebSockets. This seems easy to implement, but I'm not sure if there are some hidden disadvantages. For example, I think WebSockets is only supported by certain browsers. Are there other disadvantages to WebSockets that I should be aware of?
Since it seems like both technologies do the same thing, in what sorts of scenarios would one prefer to use one over the other? More specifically, has HTML5 WebSockets made AJAX long/short polling obsolete, or are there compelling reasons to prefer AJAX over WebSockets?
WebSockets is definitely the future now.
Long polling is a dirty workaround to prevent creating connections for each request like AJAX does - but long polling was created when WebSockets didn't exist. Now due to WebSockets,
long polling is going away no more.
WebRTC allows for peer-to-peer communication.
I recommend learning WebSockets.
Comparison:
of different communication techniques on the web
AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection.
Supported in all major browsers.
Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic.
support chart (full) | wikipedia
WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted.
support chart (very good) | wikipedia
WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required.
support chart (medium) | wikipedia
Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia
Advantages:
The main advantage of WebSockets server-side, is that it is not an HTTP request (after handshake), but a proper message based communication protocol. This enables you to achieve huge performance and architecture advantages. For example, in node.js, you can share the same memory for different socket connections, so they can each access shared variables. Therefore, you don't need to use a database as an exchange point in the middle (like with AJAX or Long Polling with a language like PHP).
You can store data in RAM, or even republish between sockets straight away.
Security considerations
People are often concerned about the security of WebSockets. The reality is that it makes little difference or even puts WebSockets as better option. First of all, with AJAX, there is a higher chance of MITM, as each request is a new TCP connection that is traversing through internet infrastructure. With WebSockets, once it's connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, which requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).
P.S.
Remember that WebSockets generally have a very different approach of logic for networking, more like real-time games had all this time, and not like http.
One contending technology you've omitted is Server-Sent Events / Event Source. What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? has a good discussion of all of these. Keep in mind that some of these are easier than others to integrate with on the server side.
For chat applications or any other application that is in constant conversation with the server, WebSockets are the best option. However, you can only use WebSockets with a server that supports them, so that may limit your ability to use them if you cannot install the required libraries. In which case, you would need to use Long Polling to obtain similar functionality.
XHR polling A Request is answered when the event occurs (could be straight away, or after a delay). Subsequent requests will need to made to receive further events.
The browser makes an asynchronous request of the server,
which may wait for data to be available before responding. The
response can contain encoded data (typically XML or JSON) or
Javascript to be executed by the client. At the end of the processing
of the response, the browser creates and sends another XHR, to await
the next event. Thus the browser always keeps a request outstanding
with the server, to be answered as each event occurs. Wikipedia
Server Sent Events Client sends request to server. Server sends new data to webpage at any time.
Traditionally, a web page has to send a request to the server to
receive new data; that is, the page requests data from the server.
With server-sent events, it's possible for a server to send new data
to a web page at any time, by pushing messages to the web page. These
incoming messages can be treated as Events + data inside the web page. Mozilla
WebSockets After the initial handshake (via HTTP protocol). Communication is done bidirectionally using the WebSocket protocol.
The handshake starts with an HTTP request/response, allowing servers
to handle HTTP connections as well as WebSocket connections on the
same port. Once the connection is established, communication switches
to a bidirectional binary protocol which does not conform to the HTTP
protocol. Wikipedia
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.
I am building a small chat application for friends, but unsure about how to get information in a timely manner that is not as manual or as rudimentary as forcing a page refresh.
Currently, I am implementing this using simple AJAX, but this has the disadvantage of regularly hitting the server when a short timer elapses.
In researching long/short polling, I ran across HTML5 WebSockets. This seems easy to implement, but I'm not sure if there are some hidden disadvantages. For example, I think WebSockets is only supported by certain browsers. Are there other disadvantages to WebSockets that I should be aware of?
Since it seems like both technologies do the same thing, in what sorts of scenarios would one prefer to use one over the other? More specifically, has HTML5 WebSockets made AJAX long/short polling obsolete, or are there compelling reasons to prefer AJAX over WebSockets?
WebSockets is definitely the future now.
Long polling is a dirty workaround to prevent creating connections for each request like AJAX does - but long polling was created when WebSockets didn't exist. Now due to WebSockets,
long polling is going away no more.
WebRTC allows for peer-to-peer communication.
I recommend learning WebSockets.
Comparison:
of different communication techniques on the web
AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection.
Supported in all major browsers.
Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic.
support chart (full) | wikipedia
WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted.
support chart (very good) | wikipedia
WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required.
support chart (medium) | wikipedia
Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia
Advantages:
The main advantage of WebSockets server-side, is that it is not an HTTP request (after handshake), but a proper message based communication protocol. This enables you to achieve huge performance and architecture advantages. For example, in node.js, you can share the same memory for different socket connections, so they can each access shared variables. Therefore, you don't need to use a database as an exchange point in the middle (like with AJAX or Long Polling with a language like PHP).
You can store data in RAM, or even republish between sockets straight away.
Security considerations
People are often concerned about the security of WebSockets. The reality is that it makes little difference or even puts WebSockets as better option. First of all, with AJAX, there is a higher chance of MITM, as each request is a new TCP connection that is traversing through internet infrastructure. With WebSockets, once it's connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, which requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).
P.S.
Remember that WebSockets generally have a very different approach of logic for networking, more like real-time games had all this time, and not like http.
One contending technology you've omitted is Server-Sent Events / Event Source. What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? has a good discussion of all of these. Keep in mind that some of these are easier than others to integrate with on the server side.
For chat applications or any other application that is in constant conversation with the server, WebSockets are the best option. However, you can only use WebSockets with a server that supports them, so that may limit your ability to use them if you cannot install the required libraries. In which case, you would need to use Long Polling to obtain similar functionality.
XHR polling A Request is answered when the event occurs (could be straight away, or after a delay). Subsequent requests will need to made to receive further events.
The browser makes an asynchronous request of the server,
which may wait for data to be available before responding. The
response can contain encoded data (typically XML or JSON) or
Javascript to be executed by the client. At the end of the processing
of the response, the browser creates and sends another XHR, to await
the next event. Thus the browser always keeps a request outstanding
with the server, to be answered as each event occurs. Wikipedia
Server Sent Events Client sends request to server. Server sends new data to webpage at any time.
Traditionally, a web page has to send a request to the server to
receive new data; that is, the page requests data from the server.
With server-sent events, it's possible for a server to send new data
to a web page at any time, by pushing messages to the web page. These
incoming messages can be treated as Events + data inside the web page. Mozilla
WebSockets After the initial handshake (via HTTP protocol). Communication is done bidirectionally using the WebSocket protocol.
The handshake starts with an HTTP request/response, allowing servers
to handle HTTP connections as well as WebSocket connections on the
same port. Once the connection is established, communication switches
to a bidirectional binary protocol which does not conform to the HTTP
protocol. Wikipedia
I have created server daemon, that produces some data, like messages and so. But, what im interested in - client monitoring. For example i have web page, and i need to establish persistent Tcp connection to server and show all incoming data into textbox. I know it can be done with flash, but im searching for JS implementation.
Is it possible and what`s the best practices ?
What you're asking for is known as Comet. Plenty of server software and client libraries exist - see the linked Wikipedia page.
WebSockets is designed to solve this problem.