HTTP Long polling
I'm designing a website and for this reason I have not started writing code.
THE PROBLEM IN SYNTHESIS IS THIS:
If I have two or more(up to 500) users connected to a page that need to exchange messages without any refresh, how can I?
Initially, I immediately thought of making an ajax call every 0.2 seconds that give back to me any new messages but this solution is absolutely counterproductive.
I have read a bit on the internet but have not found an effective solution
HOW would solve:
I would make an AJAX call (with a timeout) and the php code would do for an infinite long as there are no new messages.
I have read on the Internet and there is little talk of this HTTP Long polling and I can not find a solution. can you help me?
Really, a browser-based answer to this kind of thing is *NOT* the best solution.
What you really want is the capability to PUSH messages to particular individuals, and HTTP cannot do that.
Having said all that: Your long-timeout solution using AJAX isn't a bad one, but I'm not sure, then, that PHP Is the right choice for your server-side code. Likely a better choice would, again, be Java Servlets for the server-side coding.
Oh, and HTTP Long Polling requires a certain type of server. Unless you have your own dedicated server, you probably can't use it.
Hmmm...correct me if I'm wrong, then.
If you had 1000 web browsers all hitting you with long AJAX wait times, then wouldn't each one require a separate thread on the server? How else does the server keep track of which request a given server "page" is responding to?
Maybe 1000 threads is okay on Apache and PHP, though.
Don't get me wrong: I *can* imagine a server-side architecture that could say "oh, that HTTP response isn't ready yet, so I'll just put it in a queue and use this thread for a different HTTP request." But does PHP actually *do* that?
I know I can do that with Java Servlets. Have done it, in fact. But I didn't think that PHP was that...well, "smart" is the wrong word. "Flexible", perhaps?
if you are broadcasting, then a minimal php routine could be under 1mb, so figure 2.5mb/user as a starting place. if everyone needs their own history maintained and authentication and the whole 9 yards, 20mb/user is fairly conservative. If you server has 4gb of ram, and you app needs 4mb / user, that's 1000 users on an apache/php rig.
for the older comet techs (forever iframe, jsonp, ajax), you really need a "keep-alive" data packet to be sent every 29.99 seconds. accounting for lag and buffering, 27.5 is the most seconds i've found to be safe. turning around 2200 connections per hour should be no problem for an operational webserver. 10,000 per hour should be quite doable and provides 1,000 users a 12 msg/min message volume.
so, the answer i guess would be yes, php and apache can do that. node.js can do 10-1000X more, but php can do the 500 the OP needs...
Do you know, I utterly missed where he said "500 users" until you pointed it out.
Okay, you are clearly correct.
And the figures you cite for Node.js aren't really all that far off from Java Servlets if you strip your JSP server down to the minimum (maybe 2x to 4x better than servlets, but maybe not. My JSP is at least 5 years old now.). So yeah, it's doable.
|All times are GMT +1. The time now is 03:21 PM.|
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.