Manytimes clients ask for features like instant messaging (IM) and other client-to-client (P2P) communication for their web apps. Typically how is this done in normal web browsers? For example I've seen demos of Google Wave (and Gmail) that are able to IM from a regular browser. Is this via HTTP? Or does XmlHttpRequest (AJAX) provide the necessary backend for such communication?
More than anything I wonder how can a server "wake up" the remote client, lets say for sending an IM? Or does the client have to keep "polling" the message server for new IMs?
Typically the browser will poll the server for new messages. One approach that is often done to make this more efficient is the 'long poll' (see also this link) - the server responds immediately if it has anything; otherwise, it waits, keeping the connection open for a while. If a message comes in, it immediately wakes up and sends it, otherwise it comes back with a 'nope, check back' after a few tens of seconds. The client them immediately redials to go back into the long-polling state.
Related
I'm trying to implement a custom live chat program on the web, but I'm not sure how to handle the real-time (or near real-time) updates for users. Would it make more sense to send Ajax requests from the client side every second or so, polling the database for new comments?
Is there a way to somehow broadcast from the database each time a comment is added? If this is possible how would that work? I'm using Sql Server 2008 with Asp.net (c#).
Thanks!
Use long polling/server side push/comet:
http://en.wikipedia.org/wiki/Comet_(programming))
Also see:
http://en.wikipedia.org/wiki/Push_technology
I think when you use long polling you'll also want your web server to provide some support in the form of non-blocking io for requests, so that you aren't holding a thread per connection.
You could have each client poll the server, and at the server side keep the connection open without responding.
As soon there is a message detected at server side, this data is returned through the already open connection. On receipt, your client immediately issues a new request.
There's some complexity as you need to keep track server side which connections is associated with which session, and which should be responded upon to prevent timeouts.
I never actually did this but this should be the most resource efficient way.
Nope. use queuing systems like RabiitMq or ActiveMQ. Check mongoDB too.
A queuing system will give u a publish - subscribe facilities.
I was watching many presentations about Html 5 WebSockets , where server can initialize connection with client and push the data without the request from the client.
We don't need Polling etc.
And , I am curious , why Http was designed as a "pull" and not full duplex protocol in the first place ? What where the reasons behind that kind of decision ?
Because when http was first designed it was meant to be used to retrieve documents from a server. And the easiest way to do is when the client asks the server for a document and gets it delivered as response (or an error in case it does not exist). When you have push protocol that means the server would need to keep client connections around for potentially a long time creating more resource management problems - remember we are talking about early 1990s here.
Http was designed for simply retrieving hypertext documents from a server. There were no reasons to push anything to the client when the pages were just pure, static html without scripting capabilities.
Since there was no need at the time for pushing things back to the client, the protocol was kept simple.
HTTP is mainly a pull protocol—someone loads information on a Web server and
users use HTTP to pull the information from the server at their convenience. In particular,
the TCP connection is initiated by the machine that wants to receive the file.
I have a AJAX client which must receive messages from server. Some messages from server not like request-response type. For example, imaging game in which players can enter. Server must send to client info about player entering. But how can server send message to client via http without request from client?
Only decision that i can invent: client send request to server (getNewPlayerEnter request) with big timeout, server checks state of player set, if in set new players are, then server send info to client, if not server 'sleeps' on some time, and after 'sleeping' server checks players set again.
I think my desicion a little stupid(maybe not little). How implement it right?
p.s. sorry for my english
What you are referring to is "polling" where your client side code will make a request to the server every X seconds to check for updates.
It's an easy to implement solution, which is why you see it so often. However, a better solution is to use Comet.
In 2006, Alex Russell coined the term "Comet" to identify a technique whereby the client makes and HTTP request to the server and the server keeps that connection open indefinitely. With this open connection, the server can then push updates to the client in the response when there are updates.
When the response is received, the client immediately opens a new long-lived HTTP connection.
I encourage you to do a search for "Comet" and whatever server-side language you are using to find a framework that will get you started.
Comet Daily has some really great demos, from chat applications to games, that use Comet. If you have a tool like Firebug or Chrome Debugger, you can observe the response/request cycle of these real-time applications.
http://cometdaily.com/2009/10/23/concrete-comet-examples/
The way this typically would be done is for the client to ping the server on a regular interval (say, every 10-seconds). If there has been a change on the server, the change is sent back to the client. If there has been no change, either a blank response is sent, or some sort of "no-change" code that you specify.
I have created a simple chat server that is driven by client polling. Clients send requests for data every few seconds, and get handed any new messages as well as information about whether their peer is still connected.
Since the client is running on a mobile platform (iPhone), I've been looking for ways of getting rid of the polling, which quickly drains the battery. I've read that it's possible to keep an http connection open indefinitely, but haven't understood how to utilize this technique in practice. I'm also wondering whether such connections are stable enough to use in a mobile setting.
The ideal scenario would be that the server only sends data to clients when an event that affects them has occurred (such as a peer posting a message or going off line).
Is it advisable to try to accomplish this over http, or would I have to write my own protocol over tcp? How hard would it be to customize xmpp to my need (my chat server has some specialized features that I would have to easily implement).
How about push technology? see http://en.wikipedia.org/wiki/Comet_(programming)
I think you're describing XMPP over BOSH.
http://xmpp.org/extensions/xep-0206.html
I've used this http-binding method between a chat server and javascript client on non-mobile devices. It worked well for me.
You might like to check out this project which uses a variety of techniques including Comet. Release details are here, here's a snippet from that page
It’s my distinct pleasure to be able
to announce the first public showing
of a project that I’ve been working on
in my spare time in the last month or
two, a new Web Based IRC chat
application.
This project brings together a lot of
new technologies which had to be
developed to make this a feasible,
scalable and efficient.
Some of the underlying tools build to
make this posible that i consider
’stable enough’ are already released,
such as the php Socket Daemon library
i wrote to be able to deal with
hundreds up to many thousands of
“Comet” http connections, and an equal
amount of IRC client connections.
I just found this article myself, which describes the following technique (which I referred to in the question):
... have the client make an HTTP request
and have the server hold the request
on the queue until there is a message
to push. if the TCP/IP connection is
lost or times-out, the client will
make a new HTTP request, and the delay
will only be the round trip time for a
request/response pair . . . this model
effectively requires two TCP/IP
connections for HTTP, client to
server, though none permanent and
hence mobile friendly
I think this is nearly impossible and dangerous. The internet works stateless and connectionless meaning that the connection between client and server is always handled as unreliable. And this is not for fun.
By trying to get a stateful connection you are introducing new issues. Especially from a 3g application. What if the connection breaks? You have no control over the server and cannot push.
I think it would even be easier to send sms/text messages and have an application that handles that.
Links to articles would also be appreciated--I don't know the terminology to search for.
I'm looking to learn how a web application can allow for server-to-client communications. I know the web was not designed for this and that it has been something of a hurdle, and am just wondering what the state of this is, and what the best practices are.
An alternative is constant or occasional polling via ajax, but is it possible for web servers to maintain stateful connections to a web client?
Edit: Another way to ask this question is how does StackOverflow tell a page that new posts are available for it to display that little bar at the top?
StackOverflow polls the server to check if there is more data.
What you're looking for is Comet.
To get true two way communications from a browser you need to use a plugin technology like Silverlight, Flash, et al. Those plugins can create TCP connections that can establish a two way persistent connection with a server socket. Note that you can't really establish the TCP connection with the HTTP server so you'd have to create an additional server agent to do the communicating back to the browser.
Basically it's a completely differnet deployment model to what AJAX sites like Stackoverflow, Gmail etc. use. They all rely on the browser polling the server at set intervals.
Web browsers really aren't set up to handle this sort of communication. The communication is a one way street where the web server is listening on a port (typically 80 or 443) for for information to be sent to it.
I just read the link on comet, and it's interesting approach, but what has to be remembered is that it is still technically being opened by the client. The server is sending code for it to execute, but the browser is ultimately in control and determines when the server communicates with it.
With today's web browsers the server can never technically execute a message being sent to it without the help of the browser. Technically you might be able to get around that by executing some Active X control on the client machine...but I haven't tried it.
You can't, HTTP is stateless. A long time ago Netscape implemented HTTP Push but it wasn't a sucess.
I'd use polling with a web service or similar; no plugin (that is Flash, Java,Silverlight) will have rights in its sandbox to use raw sockets so it'll be a waste of time trying to implement it that way.