reconnect socket after sleep - javascript

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.

Related

Socket.io - remove jitter?

I have not been able to get an answer to this anywhere online. I want to remove possible jitter from my nodejs server. I am using socket.io to create connections to node.
If a user goes to a specific part of my website, a connection is started. However, if the user refreshes the site too quickly and often, the connection is created very frequently, and issues arise with my server.
While I realized it's possible this could be solved a couple different ways, I am hoping a server solution is out there. Meaning, whenever a user connects, make sure the user is connected for at least 5 seconds. Then move on. Otherwise, disconnect the user. Thanks for any insight!
First off a little background. With a default configuration, when a socket.io connection starts, it first does 2-5 http connections and then once it has established the "logical" connection, it tries to establish a connection using the webSocket transport. If that is successful, then it keeps that webSocket connection as a long lasting connection and sends socket.io packets over it.
If the client refreshes in the middle of the transition to a webSocket connection, it creates a period of unknown state on the server where the server isn't sure if the user is just still in the middle of the transition to a lasting webSocket connection, if the user is gone entirely already, if the user is having some sort of connection issues or if the user is doing some refresh thing. You can easily end up with a situation where the server thinks there are multiple connections all from the same user in the process of being confirmed. It can be a bit messy if your server is sensitive to that kind of thing.
The quickest thing you can do is to force the connection process to go immediately to the webSocket transport. You can do that in the client by adding an options to your connection code:
let socket = io(yourURL, {transports: ["websocket"]});
You can also configure the server to only accept webSocket connections if you're try to protect against any other types of connections besides just from your own web pages.
This will then go through the usual webSocket connection which starts with a single http request that is then "upgraded" to the webSocket protocol. Once connection, one socket. The server will know right away, either the user is or isn't connected. And, once they've switched over to the webSocket protocol, the server will known immediately if the user hits refresh because the browser will close the webSocket immediately.
The "start with http first" feature in socket.io is largely present because in the early days of webSockets, there were some browsers that didn't yet support them and some network infrastructure (like corporate proxies) that didn't always support webSocket connections. The browser issue is completely gone now. All browsers in use support webSocket connections. I don't personally have any data on the corporate proxies issues, but I don't ever hear about any issues with people using webSockets these days so I don't think that's much of an issue any more either.
So, the above change will get you a quick, confirmed connection and get rid of the confusion around whether a user is or isn't connected early in the connection process.
Now, if you still have users who are messing things up by rapid refresh, you probably need to just implement some protection on your server for that. If you cookie each user that arrives on your server, you could create some middleware that would keep track of how many page requests in some recent time interval have come from the browser with this cookie and just return them an error page that explains they can't make requests that quickly. I would probably implement this at the web page level, not the webSocket level as that will give users better feedback to stop hitting refresh. If it's really a refresh you're trying to protect against and not general navigation on your site, then you can keep a record of a combination cookie and URL and if you see even two of those within a few seconds, then return the error page instead of the expected content. If you redirect to an error page, it forces a more conscious action to go back to the right page again before they can get to the content.

Socket.io when client Internet going to off

How can i callback from client to server internet going to off? I have users and i added their connections in the some room. But I can not know when they are Internet going to down. I want to callback their statues but I do not know how. My clients are android phone.
this function does not work.
socket.on("disconnect", function () {
var SocketRoom= socket.room;
socket.leave(SocketRoom);
});
The clients can't send a message through the socket connection, if they are not connected to the network/internet anymore. You might want to check for timeouts.
Once a client connects to the server, the server sends a message to the client in a fixed time interval (like every 5 seconds).
If the client responds to that message, you know, it's still conencted and continue with your program logic.
If the client does not respond to your message, then they are very likely not connected to the internet anymore (or are unreachable for other reasons). If this is the case, you can force them to leave the room (like in your socket.on("disconnect", ...) function).
Please note:
The higher the timeout interval, the less precise is the actual disconnect time, but the load on the connection is kept low.
If a client does not respond to a timeout-check, you might want to retry to send a message to that client a couple of times before force-closing the connection.

For a push notification, is a websocket mandatory?

I have PHP on the server side, and HTML and javascript on the client side.
I am making an app where a stakeholder types a message that is broadcasted to multiple recievers of a group in real time.
I did some research on google and I understand I need to use WebSockets or Comet for real time push notifications. Is WebSocket or Comet mandatory for sending mass notifications to users?
Is my understanding correct? Any references to start with?
If the client is a browser, then the ONLY two ways a standard browser can connect to a server is via an Ajax (e.g. http) request or a webSocket connection. So, if you want a client to get notified of something from the outside world it has to use one of those two mechanisms.
HTTP requests are transitory. The client makes a request of a server, the server responds. HTTP requests are perfect for the client requesting information from the server. They are not very good at the server sending information to the client because normally the client is not connected. There are hacks and work-arounds where the client "polls" the server on some interval and maybe even the server uses longer running requests to try to simulate a "push" type system, but they are sub-optimal hacks at best.
webSockets are continuous connections. The client connects and the connection remains in place for as long as both sides want. This allows either side the ability to send a message to the other side whenever they want. That means the server can "push" data to the client whenever it wants. webSockets are efficient for push connections and are recommended (this is one of the main things they were designed for).
Comet is a library that was originally built for using HTTP to try to "hack" or "simulate" push before webSockets were invented and then before they were widely supported. I can think of no reason why one would want to use Comet instead of a webSocket unless you had such an old browser that webSocket was not supported.
So, if you are trying to do "realtime server push" to a browser, then you must have a continuously connected socket from the client which means webSocket (or something built on top of webSocket like socket.io).
For phone apps where you have access to the phone SDK, you can use the "push" system built into the OS to push some messages from server to client. This isn't quite the same as the two way webSocket channel, but since you asked about "push notifications", the OS push services available in both Android and IOS could also be an option for pushing notifications from server to client. Here's info on iOS notifications and Google Cloud Messaging
As of 2016, one can also use Server-sent events in all modern browsers except Microsoft browsers (not supported yet in Edge or IE) to push data from server to client. Here's a browser compatibility table. Server-sent events use a long lasting HTTP connection, a special MIME type and a supporting client in order to be able to send events from server to client at any time. Unlike webSockets, server-sent events are one way only (from server to client). A client would then use a traditional Ajax call in order to be able to send data to a server (whereas with a webSocket data can be sent either way over the same webSocket connection).
Here's a good description of how server-sent events work: How do server-sent events actually work?
Is your client application a SPA? (Single Page application)?
It's very important because if not, you have to consider that everytime a client change page, connection with websocket server will be lost.
In this case you have to manage a queue because if stakeholder send a multicast request when one client is disconnected, client won't receive nothing.
Polling won't solve this situation too and it's an orrible solution because mobile clients (for example) with typical internet plan, will consume megabytes for unuseful "ping" traffic.
A real example of polling is a child in a car asking his dad every minute if they are arrived to a destination!
So, Is there a solution without using spa?
Yes, using a "shared storage" between stakeholder and clients, and using websocket only for "wake up" online clients saying: Hey there is something new, go to check!
Everytime a client open a page it will receive from backend also not-read notifications, taken from the storage.
When a stakeholder want to notify something, it will just store the notification message in the shared storage and send a "pulse" to notification server.
Notification server will forward the "pulse" to online clients (just in case someone is stuck reading a page).
If a "pulse" is lost because a client is changing page there is no problem because the client will bring notifications from the storage.
Every page will contain this logic:
Retrive number or unread notifications (server side)
Connect to the notification server after 5 seconds (javascript side).
Hope it helps.
I would suggest that using webSockets is a more efficient way compared to other options, why is this? Well when a client receives a notification that there's a change in the server there is no need to create an AJAX call to the server to get that change, it can be sent to the client with the same webSocket connection more easily than AJAX. This means efficient code and a faster running App!

how to get the server to talk to the client

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/

Calculating packet travel time in JavaScript

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.

Categories

Resources