My server broadcasts a packet to a browser client every now and then.
Is there any way to figure out how long it took from the packet from:
server --> client
I'm trying to time something, so ideally my JavaScript function would be like:
var travelTime = {amount of time it took packet to get to me};
setTimeout('myFunction()', 3000 + travelTime);
Also, I'm not requesting this packet so I can't log the send time, and log the recieve time on the client side. This packet request is not bi-directional, as I establish a socket with the server and the server has the ability to just fire me a packet.
Any advice is appriciated!
EDIT: comet-style connection
You could include a timestamp in the packet, but that would depend on both systems being synchronized to the same clock (using NTP, for instance). If you don't have control of both server and client then what you are asking is impossible without a round-trip. Even with NTP synchronization there will be some jitter depending on how often the clocks synch. With a round trip your latency calculation will only be an estimate anyway, subject to serious deviations as network conditions change unless both client and server are on the same LAN.
Related
I am using streaming provided by a vendor using socket.io using the following code:
var socket = io.connect('https://streamer.vendor-company.com/');
var subscription = ['sub1', 'sub2', 'sub3', 'sub4'];
socket.emit('SubAdd', { subs: subscription });
socket.on("m", function(message) {
console.log(message);
var messageType = message.substring(0, message.indexOf("~"));
if (messageType == someMessageType) {
dataUnpack(message);
}
else if (messageType == otherMessageType) {
anotherDataUnpack(message);
}
});
The method dataUnpack and anotherDataUnpack perform some processing on the received message and display to the webpage. Now here, the array subscription may have around 45 subscriptions.
I want to know the affect on performance on my website. Does socket.io have some way for not flooding the client or are there any serious performance consideration? Is socket.io designed for such usage?
Updates
This is different from: Too many on-connection events with Socket.io, does it hurt? as mine is for Javascript/jquery and the question to which I gave link is for node.js.
The server is not under my control. Looking at jfriend00's answer, It seems that if I have 50 subscriptions and I get around 20-30 messages per sec, I need to handle this on client side. If so, what is the amount of incoming messages I should worry at? And if possible, any technique/strategy for handling high rate of incoming messages?
Does socket.io have some way for not flooding the client
No. If your server sends a message to the client, socket.io delivers it. It's all up to your server how many messages it sends and socket.io's job is to deliver every one of them you tell it to send.
or are there any serious performance consideration?
If you send a ton of messages to a ton of clients, that will potentially take a lot of processing and bandwidth. socket.io is just a messaging layer on top of webSocket which is a layer on top of TCP. So, if you send a socket.io message from server to a client or from server to all clients, it's one of more TCP packets being sent to the client(s). The only way to not flood the client is for your server to not send it more than it wants or can handle.
Is socket.io designed for such usage?
Socket.io is designed to reliably deliver messages from server to client or client to server. It just does what you tell it. If you tell it to deliver 1000 messages, that's what it will do.
If you have concerns about too many messages being sent to the client, then you need to modify your server to control that. For example, you might decide that a client should not be notified more than once every 5 seconds (for efficiency reasons). To implement that, you'd need an extra layer (of your own design) on the server. That is not something that socket.io has built-in features for.
If you're getting 20-30 messages per sec per subscription and each client has 50 subscriptions, that's 1000-1500 messages per second per client. That is indeed a lot and probably not sustainable at either the client side or the server side, especially on the server-side as you get lots of clients all doing the same thing. At 1000 messages per second, you have to process a message in under 1ms in order to keep from falling behind.
There are no special techniques for handling a high rate of incoming messages other than be extremely careful to limit what you do when each message arrives. For example, you would not want to be touching the browser DOM on each message. Perhaps you would queue them and modify the DOM in batch only once per second. Further advice would need to see what you're trying to do with these messages.
The better path would be to find a way to limit the number of messages being sent to each client, either by being smarter about what you subscribe to, finding ways to configure the subscription to not send you so much or creating an intervening server of your own that can be smarter about what is sent to each client.
I have a node.js server which is communicating from a net socket to python socket. When the user sends an asynchronous ajax request with the data, the node server passes it to the python and gets data back to the server and from there to the client.
The problem occurs when the user sends the ajax request: he has to wait for the response and if the python process takes too much time then the ajax is already timed out.
I tried to create a socket server in node.js and a client that connects to the socket server in python with the data to process. The node server responds to the client with a loading screen. When the data is processed the python socket client connects to the node.js socket server and passes the processed data. However the client can not request the processed data because he doesn't know when it's done.
So you have three systems, and an asynchronous request. I solved a problem like this recently using PHP and the box.com API. PHP doesn't allow keeping a connection open indefinitely so I had a similar problem.
To solve the problem, I would use a recursive request. It's not 'real-time' but that is unlikely to matter.
How this works:
The client browser sends the "Get my download thing" request to the Node.js server. The Node.js server returns a unique request id to the client browser.
The client browser starts a 10 second poll, using the unique request id to see if anything has changed. Currently, the answer is no.
The Node.js server receives this and sends a "Go get his download thing" request to the Python server. (The client browser is still polling every 10 seconds, the answer is still no)
The python server actually goes and gets his download thing, sticks it in a place, creates a URL and returns that to the Node.js server. (The client browser is still polling every 10 seconds, the answer is still no)
The Node.js server receives a message back from the Python server with the URL to the thing. It stores the URL against the request id it started with. At this point, its state changes to "Yes, I have your download thing, and here it is! - URL).
The client browser receives the lovely data packet with its URL, stops polling now, and skips happily away into the sunset. (or similar more appropriate digital response).
Hope this helps to give you a rough idea of how you might solve this problem without depending on push technology. Consider tweaking your poll interval (I suggested 10 seconds to start) depending on how long the download takes. You could even get tricky, wait 30 seconds, and then poll every 2 seconds. Fine tune it to your problem.
I am doing a real-time application where it matter to the server to know exactly what time did the client do an action in order to do latency compensation on the server side.
For example if a client asks for a particular resource on the server (e.g, the exact time), and the server know that this request took 1 second to go from the client to server, then the server can send a response to the client with a 1 second compensation to the client.
Anyone know how I can get the trip time from Meteor.method call ? Or what other technique I can use to achieve the above ?
Thank you
I found this: mizzao:time-sync, looking in the code I see that it calculates round trip. Maybe it's a starting point.
I am trying to learn sockets in Perl. It is common that user closes the lid and socket connection gets disconnected.Is there any way that the server can get to know about client going to sleep mode. Please Help.I am using Net::WebSocket::Server
The usual means of detecting a socket that was not actively closed, but has suddenly become unreachable is for a heartbeat packet to be sent on some agreed upon schedule. The other end of the socket is supposed to response with a heartbeat response each time it receives a heartbeat packet.
If the server sends out the heartbeat and does not receive a response in a reasonable amount of time, then it can assume that the client is no longer actively connected.
Socket libraries like socket.io implement this very technique for detecting when the connection has gone dead for use with websockets, but the same technique can be used with any type of socket.
The heartbeat can be used from either end of the connection (just depending upon how you want to do it and what each side expects). So, if the server is sending the heartbeat, a client could assume that if it goes X amount of time without receiving any heartbeat requests, then it's connection to the server must have gone dead so it should close the socket and reconnect.
I'm pretty new to web development, so excuse my ignorance.
What I'd like to know is if there's a way to have the server broadcast a message to clients. An example of this would be a client page that has a newsfeed, and every time a new story comes in to the server, the server sends that information out to the client and the client updates its page's newsfeed. I don't want the client to constantly be polling the server every few seconds, asking "hey, is there a new story now? what about now? what about now???" I want the client to be doing its own thing, and then be interrupted by a message from the server.
Is there a way to do this?
For newer browsers, you can use web sockets to open a continuous connection to a server and then client/server can send each other messages whenever they want.
For older browsers, the way this is typically done is that the client has to "poll" the server to ask the server on some regular schedule if the server has any new messages for it. The server usually cannot connect directly to the client because of firewalls, local security settings, unknown location, etc... so the client has to connect to the server. Polling can either be of the regular variety, poll every 60 seconds with an ajax call to ask if there's anything new or it can be more of a long poll where the client asks if there is something new and, if there is something new, the server returns right away with that data. But, there's nothing new, the server hangs onto the polling request for some time period waiting to see if there is something new. Eventually, the server will either return that it has nothing or return with a new message if there is one. When the client gets the response, it starts the "long poll" sequence over again. Comet is an example of the "long poll" in a library form that makes it easier to implement.
Pusher is tailor-made
http://pusher.com/