Linode.com Forum

[jcr]

I am running the following set up:
polling_client.php
Code: <?php
echo "<script type=\"text/javascript\" src=\"./prototype.js\"></script>";
echo "<script type=\"text/javascript\" src=\"./polling.js\"></script>";
?>
polling.js
Code: Event.observe(window, 'load', init, false);
function init()
{
  //setInterval('polling_fcgi();', 1000); 
  setInterval('polling();', 1000); 
}
function polling()
{
  new Ajax.Request
  ( 'polling_server.php',
    { onSuccess: function(transport)
      {
       
      }
    }
  );
}

polling_server.php
Code: <?php?>

From Firebug, I look at the console to follow the requests.

On my 360 linode (Atlanta data center with Centos 5.0, apache 2.2) the round-trip is around 100-120 ms, with periods where the round-trip takes a couple of seconds.
Once in a while, the request is lost. Firebug displays a red line with a time always around 74000 ms and the "response" tab reads 'loading'
It happens once in a a while that those "lost" requests create a jam that delays all subsequent requests (on my real application, this is the problem).
I ran the same setup on a lunarpages shared webhosting (the basic at $6.95 a month) and the round-trip takes on average 180 ms / 500ms. Slower and wide variations. But, I never get the "lost" requests.

Any idea what the problem might be?
Thanks

[Xan]

Packet delivery on the Internet is always "best-effort", never guaranteed. So no application should "jam up" because of a few lost packets.

That said, the Atlanta datacenter seems to have been dropping far too many packets recently. You may be a victim of that.

[zunzun]

Xan wrote: Packet delivery on the Internet is always "best-effort", never guaranteed.

I thought UDP was best effort only. Is that TCP too?

James

[Xan]

You're right; TCP provides guaranteed delivery on top of best-effort IP, by reordering and resending when necessary.

Of course a connection can be dropped if enough packets are lost.

Still, doesn't seem like an application should jam up.

[Bdragon]

Nah, I think it's an event order issue.

What you SHOULD be doing instead of setInterval is using setTimeout(), and then from onSuccess AND onError, doing setTimeout again. Then, it will always wait for success / error before "restarting the clock".