Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 7 of 7
  1. #1
    New to the CF scene
    Join Date
    May 2011
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    HTTP Long polling

    Hi guys,
    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.

    CODE:
    PHP Code:
    while(!newMessage){  
         
    usleep(1000);//microseconds  
    }  

    echo 
    getMEssage(); 
    Code:
    $.ajax({
          type: "GET",
          url: "polling.php",
          async: true,
          cache: false,
          timeout:50000,
          success: function(data){ 
              //Nuovo messaggio
          },
          error: function(){
              //Timeout finito
          }
    });
    It could be a solution?
    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?

  • #2
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,020
    Thanks
    75
    Thanked 4,323 Times in 4,289 Posts
    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.

    You *could* do this with a JAVA (not JavaScript!) applet, because Java does allow you to open sockets (that is, avoid HTTP protocol), but of course not all people enable Java in their browser.

    ********

    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.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #3
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,020
    Thanks
    75
    Thanked 4,323 Times in 4,289 Posts
    Oh, and HTTP Long Polling requires a certain type of server. Unless you have your own dedicated server, you probably can't use it.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #4
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,189
    Thanks
    10
    Thanked 569 Times in 550 Posts
    Quote Originally Posted by Old Pedant View Post
    Oh, and HTTP Long Polling requires a certain type of server. Unless you have your own dedicated server, you probably can't use it.
    anything with PHP ought to be plenty, especially if it has APC installed. .NET works as well. I would recommend EventSource over ajax, but it's best to have a stack so you get high-efficiency pipes like WebSockets and backwards-compatibility via flash/ajax/jsonp so you can use a common high-level interface for all browsers.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/1/19) IE7:0.2, IE8:6.7, IE11:7.4, IE9:3.8, IE10:4.4, FF:18.3, CH:43.6, SF:7.8, MOBILE:27.5

  • #5
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,020
    Thanks
    75
    Thanked 4,323 Times in 4,289 Posts
    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?
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #6
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,189
    Thanks
    10
    Thanked 569 Times in 550 Posts
    Quote Originally Posted by Old Pedant View Post
    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?

    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?
    when i was big into node.js and socket.io, i wrote a server that turned around 1 million HTTP transactions per hour at 7% cpu on what's now a now five-year-old box. it trounced the php competition, especially anything using sql anything for state storage, since node uses a JS variable instead of a DB to pass data between connections. PHP's APC is a ram-cache, and though it still need serialization, it's WAY more apropos than a DB for real-time anything.

    if it's the same as it was when i was researching the competition to javascript, about a year and a half ago, ~2100-2600 open connections is the practical limit for a single core of apache and php, but usually, each connection will eat up at least 2mb of ram from just apache, plus whatever php each one needs, so you can't say for certain in any kind of general way what any system might handle; it depends on the app.

    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...
    Last edited by rnd me; 05-07-2013 at 03:48 AM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/1/19) IE7:0.2, IE8:6.7, IE11:7.4, IE9:3.8, IE10:4.4, FF:18.3, CH:43.6, SF:7.8, MOBILE:27.5

  • #7
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,020
    Thanks
    75
    Thanked 4,323 Times in 4,289 Posts
    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.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •