Consider these two kinds of contexts / applications:
1) When you hit a button on a page containing several input fields (the page is not a HTML form), all the infos are retrieved and sent to the server. The server then performs several tasks with that data, such as:
a) ulpoad a provided image
b) register a new row in database according to info
...and so on.
After completing each of these steps, the server sends a message to the client to inform about which process is currently being carried out on the server-side.
To do all of this, I used WebSockets (Ratchet for PHP WebSocket Server configuration, JavaScript for Browser Client Side). So far so good.
2) Next, I want to make a simple chat application, real-time, similar as Whatsapp, Telegram, etc. To do so, I also want to use WebSockets (again with Ratchet PHP on server - side and Js on client - side), but in this context, I came across ZeroMQ, and I don't really understand its purpose, no matter how many guides I read / videos I watch.
From what I understood so far is that ZeroMQ would allow the WebSocket communication to flow across a separate TCP connection, while the actual website would keep running its habitual HTTP requests across another one. Is that the only difference? In other words, is it an absolute MUST to use ZeroMQ when building chat applications with WebSockets (Consider that I run the both the WebSocket Server script as well as the website on the same server).
Related
I am trying understand websockets.
I have seen 2 examples here in doc and also here.
Both examples are using endless loop cycling, listening for when a new client connects, when they do something interesting and when they are disconnected.
My question is: Is using websockets (with endless loop cycling) better than an ajax solution with http requests per x time ?
AJAX and WebSockets are vastly different. Asking if one is better than the other is like asking if a screwdriver is better than a hammer.
WebSockets are used for real time, interactive communication. Both sides of a WebSocket connection can send data and it will be received within milliseconds by the other end. The connection stays open, reducing latency due to connection negotiation.
However, it only sort of plays nicely with HTTP. That is, it plays nicely with proxies that are WebSocket aware, and with firewalls. WebSocket traffic is most definitely not HTTP traffic, except for the client's first packet, which requests switching from HTTP to the WebSocket protocol.
AJAX, on the other hand, is pure HTTP. The only difference between AJAX and a standard web request is that an AJAX request is initiated by client side scripts and the response is available to that same script rather than reloading the page.
In both AJAX and WebSockets, the client scripts can receive data and use it within that same script. That's where the similarities end.
WebSockets set up a permanent connection and both sides can send data at any time, or sit quietly at any time. With AJAX, the client makes a request and the server responds.
For instance, if you were to set up a new message notification system, if you were using WebSockets, then as soon as a new message is available, the server sends it straight to the browser. If there are no new messages, the server stays quiet. If you were using AJAX, the client would periodically send a request to the server, which would always respond, either saying there were no new messages, or delivering the notifications that are pending. There is no way for the server to initiate things on its end, it must wait for the AJAX request.
Server side, things diverge from the traditional PHP web development paradigms. A typical WebSocket server will be a stand alone, CLI application running as a daemon. (If that last sentence doesn't make sense, please spend a while taking the time to really understanding how to administer a server.)
This means that multiple clients will be connecting to the same script, and superglobal variables like $_GET and $_SESSION will be absolutely meaningless. It seems easy to conceptualize in a small use case, but remember that you will most likely want to get information from other parts of your site, which often means using libraries and frameworks that have absolutely no concept of accessing data outside of the HTTP request/response model.
Thus, for simplicity, you'll usually want to stick with AJAX requests and periodic polling, unless you have the means to rethink the network data and possibly re-implement things that your libraries automate, if you're looking to update standard web traffic.
As for the server's loop:
It is not a busy loop, it is an IO blocked loop.
If the server tries to read network data and none is available, the operating system will block (pause) the script and go off to do whatever else needs to be done. In my WS server, I block waiting for network traffic for at most 1 second at a time, before the script returns to check and see if anything else new happened that I should notify my clients of. Typically, this is barely a few milliseconds before the server goes right back to its IO blocked state waiting for new data on the wire. Some others have implemented my server using LibEv, which allows them to respond to events outside of the network IO without having to wait for the block to timeout.
This is the way nearly every server does things. This is why you can have Apache actively listening and serving web traffic without every server that runs Apache being pegged at 100% CPU usage even when there is no traffic.
In closing, WebSockets is a wonderful technology, but web libraries and frameworks are simply not built to use them. Thus, unless you're working in a system where waiting 3 seconds for a full AJAX request is far, far too long, it's probably best to use AJAX. If you're writing a multiplayer interactive game or a chat system, then you've found a perfect use for WebSockets.
I do heartily encourage everyone to learn WebSockets... but it's not a magic bullet, and few parts of the web are designed in ways where people can get real use out of it.
Yes, sockets are better in many cases.
It's not forever loop with 100% cpu utilizing, it's just liveloop, which exists in each daemon application.
Sync accept operation is where 99.99% of time we are.
Ajax heartbeat is more traffic, more server CPU and memory.
I too am in the learning phase. I have built a php-based websocket server and have it communicating with web pages. Perhaps my 2c perspective is useful.
Getting the websocket server (wss) working using available sources as a starting point is not that difficult, but what to do with it all next is.
The wss runs in CLI version of php. Late model browser loads a normal http or https page containing a request to the wss, along with anything else that page needs to do, a handshake occurs. Communication is then possible directly between browser and wss at the whim of either end. This is low overhead and hence fast and simple. Very cool. What is said over that link needs to be understood by both ends - subprotocol agreement. You may have to roll your own in php and in javascript. No more http headers, urls, etc etc.
The wss is a long-lived, stateful instance of php (very unlike apache etc which forget you on sending the page). An entire app can be run in the wss instance, keeping state for itself and each connected client. It used to be said that php was too leaky for long life but I don't hear that much any more. But I believe you still have to be careful with memory.
However, being a single php instance there is not the usual separation between client instances. For example statics in classes are shared with every class instance and hence every client. So for a single user style app sharing data with a heap of clients this is great. I can see that Ajax type calls can be replaced in this way, but if the app still had to rebuild state to service each client, and then release it to save resources, that seems to lessen the advantage.
Going a step further and keeping truly stateful instances for clients seems like a possible next step. Replicating the traditional session based system is one possibility, alternatively fork new php interpreters and look after communications between parent and children via sockets or suchlike. But this would require resources per client that would be severely limiting for any non-trivial app.
Or perhaps it is possible to put the bulk of the app in the parent and let the children just do the very client specific stuff. Or break the app design into small independent units that can communicate directly via sockets. Socket communication does seem to be catching on nowadays.
As Ghedpunk says in so many ways, the real world does not yet seem ready to realise the full potential of the web socket concept but it can certainly replace Ajax. The added advantage of the server sending without being asked opens up new possibilities previously too difficult to consider.
I'm looking for the 'way to go' (i.e. the most efficient, most used, general accepted way) when it comes to the reloading of data from a web server to a front end. In the end application, I will have several output fields where data has to be written to, for example like this:
The data streams will be different from each other in the end application. The lines will have to be reloaded with fresh, up to date data from the server.
I have been thinking of using Ajax requests to update like every second, but there has to be an other way to do this. Ajax requests will cause a lot data traffic. Also, when using the Facebook chat, you don't have to wait every second, chats are received almost instantly. Yet I don't see any Ajax polling requests being made when I use the developer tools of Mozilla Firefox. This made me think if there would be a different way to do this.
I've looked into Node.js, but it appears that isn't possible with my host.
I have heard people talking about Ajax Push, is that what I should use? If so, can you give me a basic usage example?
If not, what would then be the way to go when having multiple data streams that have to be reloaded within a second?
Requirements are speed and low data traffic. It therefore wouldn't be an option to continuously poll the server, I think, because that would create an enormous overhead.
I don't think it's of any importance, but I'm using PHP5.3 in the back end and JavaScript with jQuery 1.9.1 in the front end.
This question has been asked a number of times, but in a slightly different ways. Here are a few references that are worth a read:
What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?
Using comet with PHP?
Apache with Comet Support
Server Scalability - HTML 5 websockets vs Comet
How to implement event listening in PHP
In summary: if you are looking at building your solution using PHP on Apache then holding open persistent connections (HTTP long-polling or streaming) is going to use up resources very quickly (is highly inefficient). So, you would be better using a hosted solution (*disclaimer - I work for a hosted solution).
HTTP-Long polling and HTTP Streaming are solutions which have been superseded by Server-Sent Events and WebSockets. So, where possible (where the web client provides support) you should use one of these solutions before falling back to an HTTP-based solution. A good realtime web technology will automatically handle this for you.
Since your diagram shows you are subscribing to multiple data streams you should also consider a Publish/Subscribe solution that naturally fits with this. Again, a good realtime web tech solution will provide you with this.
Also see the realtime web technology guide.
I think what you are looking for is generally called Comet. The was this technique is often made to work is as follows:
The client (web browser) makes a request to the server for new data. This is not reloading the page, but rather is done in JavaScript
The server responds to the request when it has some data for the client. Again, this doesn't impact the UI since it isn't the page itself that's getting reloaded: the loaindg of data is done "in background" so to speak, in JavaScript code.
On the serve side, the request waits for new data, and returns the new data when available, or returns nothing if a timeout interval (defined on the server) is reached. This timeout is usually set to be lower than the browser HTTP timeout. The reason for this is so that the server can know whether a particular client got a particular piece of data. If the request is allowed to time out on the client side, the original request might be responded to by the server after the client has timed out, and the client will not get the data, even though the server thinks that it did.
The data is indeed usually transferred as JSON, but you can choose whatever encoding you'd like. See here for one example of how to do this. Goosh is another example of this technique, and so is Interactive Python Shell. The code for all is available.
On the PHP side you will want to create a page that will respond to these "background" JavaScript Comet requests. It could be the same page as the one that user loads, but let's say it is different, for ease of explanation. So the user loads index.php and the JavaScript Comet code calls getNewData.php to retrieve new data.
In your getNewData.php you will want to wait for your event and return the data then. You don't want to use polling for this, but there are PHP libraries that allow one to use various interprocess communication strategies to wait on events, see this question for instance. The high-level pseudocode for your getNewData.php would look as follows:
parse JSON request
Enter an efficient wait state (with timeout), waiting for your "new data is available" event
Did previous step time out?
Yes: send response indicating no data
No: send response with new data
I'm creating a mobile app with a server backend that will authenticate a user and continuously send them updates whilst listening for post data from the mobile app. These updates will be specific to the person, pulled from a database.
From my research it seems that I should use a websocket. I'm familiar with PHP so have tried Ratchet. I've created a simple chat script with Ratchet which queries a database onMessage and sends the data to the client.
My question is, are websockets right for this? When a server receives a connection it must query the db every 5 seconds and send updated info to the app. It must listen for messages that will change the db query. Everything in Ratchet's docs seems to be focussed on subscriptions to topics rather than treating each client individually, although I've gotten around this by using:
$client = $this->clients[$from->resourceId];
$client->send("whatever_message"):
Am I complicating things by using Ratchet? Or should I use a child process to handle each client?
I am sorry for a vague questions. I've researched as best I can but cannot establish whether I'm heading in the wrong direction! Thank you for any help.
That is a good formula. Sending post data from the apps while maintaining a socket connection is a good distribution of processes. However PHP might not be your best option for running the socket server.
The reason for this is PHP is a single threaded language which doesn't sport an elegant event system.
Take NodeJs as an alternative. It too is single threaded, however you can register events on socket servers allowing the software to run additional control processes while it waits for network activity.
This does not limit you to javascript however. Work can still be delegated to PHP processes from the NodeJs application (I use NodeJs as an example only, there are other options such as Java, Python, or good ol' native).
For moving work to PHP, you can either execute commands, or use a job server to enable synchronous and asynchronous tasks.
Here are a few resources you can combine to accomplish this:
http://nodejs.org/
http://socket.io/
http://gearman.org/
http://php.net/manual/en/book.gearman.php
And if you are using Symfony:
https://github.com/mmoreram/GearmanBundle
How to show continuous real time updates in browser like facebook ticker, meetup.com home page does? In python, PHP, node.js and what would be the performance impact at the server side ?
Also how could we achieve the same update thing if the page is cached by an CDN like akamai?
You have two options (that others have detailed above). In case you are not familiar with some of the conceptual ideas behind each option, I figured I'd give a line or two about them. Note that I'm presenting these concepts at a very, very high-level.
Your three options are:
Short-Polling
Web Socket
Comet / Long-Polling
Short Polling
Short Polling overcomes the one-way communication between Client-Server by forcing the client to continuously send requests to the server of the form:
Client: Do you have a message for me?
Server: No.
Client: (wait x seconds)
Client: Do you have a message for me?
Server: No.
Client: (wait x seconds)
Client: Do you have a message for me?
Server: Yes. Here it is!
Client: Yay!
Client: (update message)
The constant nagging on behalf of the Client is called Polling. In order to implement this structure, you'll need to set up your server to "listen" to these polling requests from the client. The server will also have to store those messages somewhere, so that when messages are ready, the server can deliver them. At a very high a simplistic level, your server needs to:
Accept general web requests
Accept polling requests
Run background jobs that fetch messages
Store these messages somewhere so that when polling requests come in, the server can check for them.
You will also need to tie these polling requests to some kind of session ID for the user, so that the right messages reach the right person. Overall, the paradigm is complicated and, in my opinion, inefficient.
Web Sockets
Web Sockets are new to HTML5. The basic idea behind them is that the Client can maintain a direct connection to the server and they can push information back and forth to each other. Therefore, instead of the usual: Clients sends GET request >> Server responds with content, Web Sockets allow you to maintain a continuous dialogue.
In order to set this up, however, you need:
Browsers that are WebSocket compliant (not all are).
A server that can handle web sockets (not sure how to articulate this, but not all servers are set up for this kind of arrangement).
The setup is somewhat complicated, albeit simpler than long polling:
Client maintains connection to Web-Socket-enabled connection to Server
Server pushes results to Client through web socket
Client updates page according to results
You'll see this pattern referred to as Push Notifications (certainly, if you own an iPhone you've experienced this) as the Server has been empowered to push "stuff" to the client (how impolite!). As there are lots of client and server nuances, I would recommend testing out something like Pusher, which is basically a web service to handle all the hard parts of Web Sockets. It'll be an easy way for you to test and play with the pattern before embarking on setting it up yourself. It has both client and server-side libraries.
Hope that information gives you a baseline to solve your problem. The other answers have more direct information on how to solve each scenario.
Comet / Long-Polling
An alternative, seemingly cross-browser approach to Web Sockets is Long-Polling (see Comet). In this case, your client establishes a connection to the server and leaves it hanging, waiting for data to be pushed back. The setup for this is somewhat complicated, but it does represent a middle ground between Short Polling and Web Sockets.
I would suggest implementing a socket like connection using SockJS or Socket.io as the client side JavaScript library and then using Tornado on the server side to publish any state changes to the client. The code is fairly simple.
The client side code depends on which library you choose. SockJS or SocketIO. Or if you just want to use Websockets directly it's very simple:
update_socket = new WebSocket("ws://my_server.com/listening_url");
update_socket.onmessage = function (evt) {
$("#my_div").html(evt);
};
The server side code is also pretty simple:
import tornado
class UpdateHandler(tornado.websocket.WebSocketHandler):
def open(self):
self.write_message('Hi client')
# listen for some events that are occurring
for message in function_that_generates_events():
self.write(message)
def on_message(self, message):
# Do something with incoming messages
def on_close(self):
# tidy up
app = tornado.web.Application(('r/listening_url',UpdateHandler))
app.listen(9000)
You could use a poll, long-poll or if you want a push system. Easiest would be a poll. However, all solutions require client side coding.
Performance impact depends on your solution. Easiest to implement would be a poll. A poll with short frequency does effectively a request every, say 100ms ot simulate real time. A long-poll would be of less impact, but it would keep open a lot of request during a more or less time.
Jetty
Ajax Push Engine
Socket.io
These are ways to implement Comet
I would recommend Socket.io, which is implemented with Node.js
because It leverages to use best available connection method
I have tried reading some articles, but I am not very clear on the concepts yet.
Would someone like to take a shot at explaining to me what these technologies are:
Long Polling
Server-Sent Events
Websockets
Comet
One thing that I came across every time was, the server keeps a connection open and pushes data to the client. How is the connection kept open, and how does the client get the pushed data? (How does the client use the data, maybe some code might help?)
Now, which one of them should I use for a real-time app. I have been hearing a lot about websockets (with socket.io [a node.js library]) but why not PHP?
In the examples below the client is the browser and the server is the webserver hosting the website.
Before you can understand these technologies, you have to understand classic HTTP web traffic first.
Regular HTTP:
A client requests a webpage from a server.
The server calculates the response
The server sends the response to the client.
Ajax Polling:
A client requests a webpage from a server using regular HTTP (see HTTP above).
The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server at regular intervals (e.g. 0.5 seconds).
The server calculates each response and sends it back, just like normal HTTP traffic.
Ajax Long-Polling:
A client requests a webpage from a server using regular HTTP (see HTTP above).
The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server.
The server does not immediately respond with the requested information but waits until there's new information available.
When there's new information available, the server responds with the new information.
The client receives the new information and immediately sends another request to the server, re-starting the process.
HTML5 Server Sent Events (SSE) / EventSource:
A client requests a webpage from a server using regular HTTP (see HTTP above).
The client receives the requested webpage and executes the JavaScript on the page which opens a connection to the server.
The server sends an event to the client when there's new information available.
Real-time traffic from server to client, mostly that's what you'll need
You'll want to use a server that has an event loop
Connections with servers from other domains are only possible with correct CORS settings
If you want to read more, I found these very useful: (article), (article), (article), (tutorial).
HTML5 Websockets:
A client requests a webpage from a server using regular http (see HTTP above).
The client receives the requested webpage and executes the JavaScript on the page which opens a connection with the server.
The server and the client can now send each other messages when new data (on either side) is available.
Real-time traffic from the server to the client and from the client to the server
You'll want to use a server that has an event loop
With WebSockets it is possible to connect with a server from another domain.
It is also possible to use a third party hosted websocket server, for example Pusher or others. This way you'll only have to implement the client side, which is very easy!
If you want to read more, I found these very useful: (article), (article) (tutorial).
Comet:
Comet is a collection of techniques prior to HTML5 which use streaming and long-polling to achieve real time applications. Read more on wikipedia or this article.
Now, which one of them should I use for a realtime app (that I need to
code). I have been hearing a lot about websockets (with socket.io [a
node.js library]) but why not PHP ?
You can use PHP with WebSockets, check out Ratchet.
Tieme put a lot of effort into his excellent answer, but I think the core of the OP's question is how these technologies relate to PHP rather than how each technology works.
PHP is the most used language in web development besides the obvious client side HTML, CSS, and Javascript. Yet PHP has 2 major issues when it comes to real-time applications:
PHP started as a very basic CGI. PHP has progressed very far since its early stage, but it happened in small steps. PHP already had many millions of users by the time it became the embed-able and flexible C library that it is today, most of whom were dependent on its earlier model of execution, so it hasn't yet made a solid attempt to escape the CGI model internally. Even the command line interface invokes the PHP library (libphp5.so on Linux, php5ts.dll on Windows, etc) as if it still a CGI processing a GET/POST request. It still executes code as if it just has to build a "page" and then end its life cycle. As a result, it has very little support for multi-thread or event-driven programming (within PHP userspace), making it currently unpractical for real-time, multi-user applications.
Note that PHP does have extensions to provide event loops (such as libevent) and threads (such as pthreads) in PHP userspace, but very, very, few of the applications use these.
PHP still has significant issues with garbage collection. Although these issues have been consistently improving (likely its greatest step to end the life cycle as described above), even the best attempts at creating long-running PHP applications require being restarted on a regular basis. This also makes it unpractical for real-time applications.
PHP 7 will be a great step to fix these issues as well, and seems very promising as a platform for real-time applications.
Polling
Basically, polling is a technique of requesting the information from the server after regular intervals. This connection happens by following HTTP protocol. There are two types of polling:
Short Polling
Long Polling
Short Polling
In short polling, the client requests information from the server. The server processes the request. If data is available for the request, server responds to the request with the required information. However, if the server has no data available for the client, server returns an empty response. In both the situation, the connection will be closed after returning the response. Clients keep issuing new requests even after server sends the empty responses. This mechanism increases the network cost on the server.
Long polling
In long polling, the clients can request information from the server with the expectation that the server may not respond immediately. When the server receives the request, if it has no fresh data for the client, rather than returning an empty response, the server keeps the request open and waits for data to arrive. When the server receives new data, it delivers the response to the client right away, completing the open request. The client can then send another request for new updates after getting the answer from the server. Long polling reduces costs by reducing the number of empty responses.
WebSocket
WebSocket is a protocol that provides two-way(bi-directional) communication channels over a single TCP connection. Websocket facilitates a persistent connection between a client and a server, allowing both parties to begin transferring data at any moment. The WebSocket handshake is the procedure through which the client creates a WebSocket connection. If the operation is successful, the server and client can send and receive data at any time. Mostly used in real-time web applications such as WhatsApp, Uber.
Server-sent event (SSE)
Unlike WebSockets, we can not issue requests from a client to a server using SSE since it's a one-way connection. When we require "near real-time" transmission from the server to the client, or if the server generates data in a loop, SSE is the ideal choice.
Comet
Comet is a web application design paradigm that describes a continuous, two-way interaction between a server and a web browser using native HTTP methods. Comet is an umbrella term. Ajax Push, HTTP Streaming, and HTTP Server Push are some of the HTTP mechanisms that may be used to provide this event-driven interaction.
You can easily use Node.JS in your web app only for real-time communication. Node.JS is really powerful when it's about WebSockets. Therefore "PHP Notifications via Node.js" would be a great concept.
See this example:
Creating a Real-Time Chat App with PHP and Node.js