Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I was just reading how FaceBook designed their chat system, and it reads:
“and having that iframe’s JavaScript make an HTTP GET request over a persistent connection that doesn’t return until the server has data for the client. The request gets reestablished if it’s interrupted or times out. This isn’t by any means a new technique: it’s a variation of Comet, specifically XHR long polling, and/or BOSH.”
Can someone explain how you can a persistent request to a web server?
Esentially, you just hold the request on the server until either 1) there’s data available or 2) the server hits a threshold and says “forget it, reestablish so I know you’re really still there”. The difficulty with this approach is the scalability of the server-side, since typically web servers are designed to execute as quickly as possible, and spawning lots of threads/processes for the incoming “long-held” requests is difficult.
This long-held request is typically Xhr, if on the same domain, or JSONP if cross-domain.
We’ve written a full comet client for our IIS/ASP.NET Comet server (WebSync), which you can check out and maybe get an idea. Browse the source for the client.js file (tack on ?debug=true to see the uncompressed version), and you’ll see some references to “connect” requests – those are the long-poll requests to the server, which wait for ~25s each request, assuming no data arrives.