Asked  7 Months ago    Answers:  5   Viewed   31 times

I run a website where users can chat with each other through the browser (think Facebook chat). What is the best way to handle the live interaction? (Right now I have a poll going every 30 seconds to update online users and new incoming messages, and another poll going on chat pages every second to get new messages.)

Things I've considered:

  • HTML5 Web Sockets: didn't use this because it doesn't work in all browsers (only chrome).
  • Flash Sockets: didn't use this because I wanted to eventually support mobile web.

Right now, I am using short polling because I don't know how scalable AJAX long polling would be. I'm running a VPS server from servint right now (running apache). Should I use long polling or short polling? I don't need absolutely immediate response times (just "good enough" for a chat app). Is short polling this often with a few hundred-thousand users going to kill my server? How do I scale this, please help!

 Answers

92

A few notes:

  • Polling every second is overkill. The app will still feel very responsive with a few seconds of delay between checks.
  • To save your db's traffic and speed responses, consider using an in memory cache to store undelivered messages. You could still persist messages to the db, the in memory cache would simply be used for queries for new messages to avoid queries to the db every x seconds by each user.
  • Timeout the user's chat after x seconds of inactivity to stop polling to your server. This assures someone leaving a window open won't continue to generate traffic. Offer a simple "Still there? Continue chatting." link for sessions that timeout and warn the user before the timeout so they can extend the timeout.
  • I'd suggest starting out with polling rather than comet/long polling/sockets. Polling is simple to build and support and will likely scale just fine in the short-term. If you get a lot of traffic you can throw hardware and a load balancer at the problem to scale. The entire web is based on polling - polling most certainly scales. There's a point where the complexity of alternatives like comet/long polling/etc make sense, but you need a lot of traffic before the extra development time/complexity are justified.
Wednesday, March 31, 2021
 
rasmusx
answered 7 Months ago
72

ok,from what i understand, you need a javascript function binded on the onclick event of the generated links that sends you back to a different page the link content. if that's what you need, i recommend using a library such as jquery (it's more easy ti use) and paste this code into the page:
$('a').click(function(){
$.post("url_of_the_page_you_want_to_send",
{data : $(this).html()}); });

hope this helps :|

Saturday, May 29, 2021
 
van_folmert
answered 5 Months ago
51

Secure for 08/15 website: yes
Secure for online banking: no

The method you use is equivalent to an unencrypted everyday login <form>. Albeit you should really not rely on a "user_id" cookie. Rather save the verified user_id in the session store only.

Also you might try to simply return the session cookie on the JSON result for the AJAX call. It usually sticks to all further HTTP requests, so you don't need (3) to set the cookie via Javascript additionally.

Saturday, May 29, 2021
 
Norgul
answered 5 Months ago
93
  • Short polling (a.k.a. AJAX based timer):

    Pros: simpler, not server consuming (if the time between requests is long).
    Cons: bad if you need to be notified WHEN the server event happens with no delay. Example (ItsNat based)

  • Long polling (a.k.a. Comet based on XHR)

    Pros: you are notified WHEN the server event happens with no delay. Cons: more complex and more server resources used. Example (ItsNat based)

Wednesday, June 2, 2021
 
Teno
answered 5 Months ago
95

The difference is this: long polling allows for some kind of event-driven notifying, so the server is able to actively send data to the client. Normal polling is a periodical checking for data to fetch, so to say. Wikipedia is quite detailed about that:

With long polling, the client requests information from the server in a way similar to a normal polling; however, if the server does not have any information available for the client, then instead of sending an empty response, the server holds the request and waits for information to become available (or for a suitable timeout event), after which a complete response is finally sent to the client.

Long polling reduces the amount of data that needs to be sent because the server only sends data when there really IS data, hence the client does not need to check at every interval x.

If you need a more performant (and imho more elegant) way of full duplex client/server communication, consider using the WebSocket protocol, it's great!

Sunday, August 8, 2021
 
Juriy
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :