I have node server working locally and I connect to this server by my webbrowser. I use websocket to communication between client and server. I want to measure accurate time of sending websocket message to the server and from the server. I use javascript function Date.now(), but the problem is that in my results sometimes message was received by server before it was sent by client. I guess that there is difference between client "clock" and server "clock". But there are on the same machine.
I will be gratefull for explanation and links for resources.
As John Resig outlined in one of his blog articles javascripts time is not accurate. The clock you can access with javascript only "ticks" every few milliseconds. That means that it can be roughly ~7ms off the accurate time. Now if your request takes shorter than this small timespan (which can happen if it stays on localhost) it could look like that it was received before it was sent.
real time: 1000ms
js time: 1000ms
travel time: 5ms
real time: 1005ms
js time: 998ms // inaccuracy
difference: -2ms
We can't do anything to improve this as performance.now() was disabled for security reasons. So the only thing we can do is to introduce network latency :), but then the clocks time is probably more off...
Related
I've read a bit about Server Side Events and it seems to me that the biggest difference between SSE and Ajax Polling is that in latter you're supposed to query server yourself after each response, while with SSE a browser does that for you. Is it correct?
And in terms of server handling, there is almost no difference between SSE and Ajax Polling, with a minor difference of formatting the response in a certain way and including Content-type: text/event-stream header?
As Seabizkit basically said, one method polls the server (as much as it wants), and the other sends messages (when the server decides to send them).
If there was a single update of some data per day, can you see what the difference would be if all clients were checking once per minute, or the server sending the message once to all who have subscribed to the event?
In your question you ask if this is correct: 'the biggest difference between SSE and Ajax Polling is that in latter you're supposed to query server yourself after each response, while with SSE a browser does that for you'. To me this means you've basically asked if the browser is doing the requests for you.
Ajax Polling is asking for data - so you can check to see if it has changed etc. (similar to a web page request) on a timed basis.
An SSE sends a message to all that want to know of the change ONLY when the change has occurred.
Polling is not querying after each response, it is querying as much as you want, when you want (10 times per second if you wish, a 100, a 1,000, whatever you deem fit).
Events occur WHEN something has happened, and subscribers are then notified (hopefully just the once).
Imagine if I wanted to know if my parcel delivery driver will be turning up within the next 30 minutes.
I could call once a minute and ask - I could do this all day long if I wanted, or the driver can just call me and let me know they are 30 minutes away.
You stated in your comment to Seabizkit that client side initiates communication. No it doesn't. It adds an event handler for an event that is available on the server. The communication after that is the server sending a message to the client, be it 5 seconds later, 5 minutes later, or 50 times per second - the client doesn't request again, it has subscribed to the event and will be notified every time it fires.
Please bear in mind that this is a general explanation - not a technical one, because your question was fairly open in asking what the difference is between the two.
In the context of browsers...
The difference is: One Polls and the other responds to an Event(*).
Polling; is started at the browser end.
Make a request... receive response...do something. (usually change the UI)
Polling is expensive (relative to what you are doing!).
Polling is far easier to setup compared to handling server change on the browser.
Server side Events/Changes; is started at the server.
How to notify the browser?
Browsers out of the box have no way to respond to service side changes.
basically the browser has no idea that anything happened on the server.
You are left to handle this on your own.
Luckily library such as SignalR http://signalr.net/
Can be used simplify this a lot for you. But the complexity is still quite high compared to that of simple page with polling.
It requires you to handle socket connections between "clients".
(*) = pinch of salt, technically not worded correctly.
if this doesn't answer your question or you want more info ask.
I have Node.js application which is dedicated to listen and emit websockets only. My stack is up-to-date. I'm using clean Socket.io client server setup from this page:
http://socket.io/docs/
I discovered that once in a while it takes about 15-25 seconds to get a response from node js server. Usually it takes up to 5 ms but one every
20, 30 or 40 calls take up to 25 seconds. I found that out when I send some message to server, receive a response and calculate time spend on that
transaction (like most benchmarking apps do). I tried different configuration, transport method etc, and it's the same.
I run it on Apache/2.2.14. I prepared quickly similar test for Sock.js and response time never goes above 5 ms.
Did anyone have the same issue? What could be the reason? I know I can just use Sock.js but the thing is that big app is already done on Socket.io and it would be hard to rewrite it to use different socket package.
Cheers.
After couple of hours of debugging I found a problem which is... Kaspersky antivirus on my local machine. I've setup socket my server on port 8080. Kaspersky does not block websockets but is scanning this port. And 1 in 20 sockets takes 20 seconds to get a response. Solution: changing the port to something that is not scanned by antiviruses (not sure but 3000 or 843 should do the trick).
Why make the server push data to get notifications, like using SingleR while it can be made client side?
Using a javascript timing event, that checks for recent updates at specified time intervals user can get notifications as long as he remains connected to the server.
So my question is why do more work at the server that the client can already do?
It's not more work to the server, it's less work. Suppose that you have 10000 clients (and the number could easily be in the 100K or even millions for popular web-sites) polling the server every X seconds to find out if there's new data available for them. The server would have to handle 10000 requests every X seconds even if there's no new data to return to the clients. That's huge overhead.
When the server pushes updates to the clients, the server knows when an update is available and it can send it to just the clients this data is relevant to. This reduces the network traffic significantly.
In addition it makes the client code much simpler, but I think the server is the critical concern here.
First if you didn't use server push you will not get instant update for example you can't do chat application, second why bothering the client to do job that it is not designed to do it? third you will have performance issue on the client cause like #Ash said server is a lot more powerful than a client computer.
We're building a latency-sensitive web application that uses websockets (or a Flash fallback) for sending messages to the server. While there is an excellent tool called Yahoo Boomerang for measuring bandwidth/latency for web apps, the latency value produced by Boomerang also includes the time necessary to establish HTTP connection, which is not what I need, since the websockets connection is already established and we actually only need to measure the ping time. Is there any way to solve it?
Second, Boomerang appears to fire only once when the page is loaded and doesn't seem to rerun the tests later even if commanded to. Is it possible to force it to run connection tests e.g. every 60 seconds?
Seems pretty trivial to me.
Send PING to the server. Time is t1.
Read PONG response. Time is t2 now.
ping time = t2 - t1
Repeat every once in a while (and optionally report to the stats server).
Obviously, your server would have to know to send PONG in response to a PING command.
I am building an application where it is important to know exactly when a user submitted a request to the server. This is different from the time at which the server received the request, because there is an interval of time -- that is often subject to the vagaries of network traffic and cell reception -- between the moment the user presses submit and the server receives the POST request.
The interaction is through a web browser with JavaScript, so any solution that involves JavaScript is acceptable. I thought about getting current time on the user's computer or smartphone using JavaScript and using that as a timestamp on the submitted request, but that by itself wouldn't be reliable because the clock on the user's computer could be off. Please assume that the clock on the server is accurate.
I don't think it's possible to get an exact value. I think the best you can do is send a very small calibration AJAX request that equivalents the client time with the server time. That's what I've done anyhow.
Edit for elaboration
Basically make an AJAX call to a server endpoint with the client timestamp (clock). As soon as the server receives the client timestamp retrieve and store the server timestamp along with it. At this point you can assume the times are relatively equivalent. You won't know the network overhead, so they will be different; also their clock could be in a different time zone or just "off".
After you have this equivalence you can use the difference of the two times to calibrate any other times from the client:
clientTime0 - serverTime0 = clientServerDelta
(clientTimeX - clentServerDelta) will be about the same in server time as when clientTimeX was recorded.
You could try this:
http://jehiah.cz/a/ntp-for-javascript
to calculate an accurate JavaScript clock, then pass that value with your POST request.