Using AJAX for this would give you MUCH less accuracy than plain-old JavaScript with time delta of user time to server time:
If you just need to time sync - you could receive server time once (remembering user time, when you sent request for server time), then just compensate user time with that value.
In PSEUDO-JavaScript (client-side):
// do this once:
var user_time = (new Date()).getTime();
ajax.call('/server-time-in-sec-since-epoch',
callback:
delta_time = recvd_server_time - user_time;
)
// then at any given second real server time is:
var current_server_time = (new Date()).getTime() + delta_time;
// no need for ajax calls
For more accuracy you should divide delta_time by 2 (since it's round-trip).
The reason it has to continually sync is that any user could place a bid at any moment. This makes the timer increase and top bidder change, so every user must be notified of the change. Its asking the server for how much time is left in each auction not what time it is in the real world. Sorry for the confusion.
This is interesting. Would this work if I was on the site for say an hour? Or is there some limit to the amount of time you can send data like this? I have never tried anything like this. What is the overhead like?
I've only used it on smaller projects. Facebook use it on their frontpage for progressive loading (check the source for `<script>big_pipe.onPageletArrive(..);</script>`).
Longer running connections are a little more problematic, but some client side code should be able to handle the connection being closed. You just need to make sure your web server can handle the number of connections your are expecting. Apache is particularly bad for this. Something like nginx should perform better.
Not hard. The client could notice if the connection dies (JQuery has AJAX failure callbacks, for example) and then attempt to reconnect; that's the important thing.
Personally I'd go with simple Python WSGI app or node.js app. Actually even PHP can handle 150 reqs/sec (your load at 150 users with 1 req/s) if used as nginx+php-fpm+eaccelerator. By my measures it can actually do about 1000 reqs/sec.
Yes, it would handle it and we could have kept scaling the server up to handle more and more of it. With the C app all those problems went away. It has almost no footprint and uses almost no processor power.
Using AJAX for this would give you MUCH less accuracy than plain-old JavaScript with time delta of user time to server time:
If you just need to time sync - you could receive server time once (remembering user time, when you sent request for server time), then just compensate user time with that value.
In PSEUDO-JavaScript (client-side):
For more accuracy you should divide delta_time by 2 (since it's round-trip).