I m working on Node js server.
In order to communicate with client i open websocket which should last for the whole user session. I need also to check if a user goes offiline. One way should to be to check the state of the web socket i.e. isReady or closed. I read there some situation which the onclose is not called. So what can be a trustable way to count the real current connected users?
Related
Currently I am using an API to get chatList, so the user cannot know if they have received a new msg. They have to refresh the page in order to know that there is a new message.
I am connecting with the socket when the user is in chat and they get disconnected with socket when they leave chat and move to some other page.
But I want them to stay connected if they move to some other page.
Can you please guide me how can I achieve that? Is there any general socket available for applications ?
socket.io and webSocket connections cannot survive from one page to the next. When you leave one page and go to another, all resources from the first page (including any webSocket or socket.io connections) will be closed. That's how the browser works.
You can make a single page app (SPA) where the user clicks on things and the view changes, but it's just loading dynamic content into the same page so the actual web page never closes in the browser and thus the socket.io connection can persist.
Or, you can tag the user with a cookie so that when they leave the page, their connection closes and then they load another page and a new connection is established, your server can see that they are the same user that was just connected and your server can set things up appropriately for them to continue as if the connection was never redone.
Is there any general socket available for applications ?
No, there is not.
I am connecting with the socket when the user is in chat and they get disconnected with socket when they leave chat and move to some other page.
Yes, all browsers disconnect when the web page closes.
I am looking for a solution to my problem. I have Node.js server serving my web application where user can log in. I want to handle a situation where one user A performs specific action and user B associated with this action gets real life notification. Is there a module that would help me or there is some other solution?
What you are describing is "server push" where the server proactively notifies a user on their site of some activity or event. In the web browser world these days, there are basically two underlying technology options:
webSocket (or some use socket.io, a more feature rich library built on top of webSocket)
server sent events (SSE).
For webSocket or socket.io, the basic idea is that the web page connects back to the server with a webSocket or socket.io connection. That connection stays live (unlike a typical http connection that would connect, send a request, receive a response, then close the connection). So, with that live connection, the server is free to send the client (which is the web page in a user's browser), notifications at any time. The Javascript in the web page then listens for incoming data on the connection and, based on what data it receives, then uses Javascript to update the currently displayed web page to show something to the user.
For server sent events, you open an event source on the client-side and that also creates a lasting connection to the server, but this connection is one-way only (the server can send events to the client) and it's completely built on HTTP. This is a newer technology than webSocket, but is more limited in purpose.
In both of these cases, the server has to keep track of which connection belongs to which user so when something interesting happens on the server, it can know which connection to notify of the event.
Another solution occasionally used is client-side polling. In this case, the web page just regularly sends an ajax call to the server asking if there are any new events. Anything new yet? Anything new yet? Anything new yet? While this is conceptually a bit simpler, it's typically far less efficient unless the polling intervals are spaced far apart, say 10 or 15 minutes which limits the timeliness of any notifications. This is because most polling requests (particularly when done rapidly) return no data and are just wasted cycles on your server.
If you want to notify userB, when both of you are simultaneously online during the action, then use websockets to pass message to a two-way channel to notify userB.
If you want to notify them whenever, regardless of online status, use a message queue.
What is the best method to send user specific data from node server to client using socket io. Should I create each socket connections for users (probably hit the performance) or should I open each channel based on user.
----- Update on 09/16/2014-----
Recently i have tried creating multiple rooms corresponding to each userid based on login and in the UI layer i'm only getting user specific data. Everything works fine.
But if we look into Chrome Web Developer Websocket tab and click the connection and Frames subtab i could still see other user data. Does this means we have to spin off different socket connection for each user rather than creating rooms for user.
I have broadcasted data for 3 id
1.starts with dGhvY
2.starts with bnZIZ
3.starts with dXZIb
Please find screenshot to get more idea
I'm writing an application where I open up a socket when a user visits my site, record information by sending data over the socket while the user is on the site, and store the information in a database once the user leaves the site.
The problem I am currently facing is that while I can detect when a socket disconnects from my server, I don't know which socket corresponds to what information, so I don't know what information to store into the database.
Below is where I believe I need to put in code
socket.on('disconnect',function() {
//insert data corresponding to current socket into database
console.log('The client has disconnected!');
});
Thanks!
It sounds like you want to keep some kind of state associated with the socket connection. I think what you are looking for is socket.io sessions.
Plenty of examples around on the net, this thread has a lot of good information: socket.io and session?
I found this particularly usefull: http://www.danielbaulig.de/socket-ioexpress/
Scenario:
The browser submits a HTTP request to a server.
The user simultaneously clicks on a bookmark or on another link on the page resulting in a new request to the server.
The server now sends back two HTTP responses (or the browser gets responses from two servers).
How does the browser decide which of the responses to actually process?
I know what will happen - am trying to understand why. Any references or websites that explain this would also be much appreciated.
Thank you,
vivek.
Edit: Saw this similar question after asking. Please merge/delete if appropriate.
The short answer to your specific question is that receiving a server's response (within a browser) is different from receiving a browser's request (within a server). When the browser opens a new connection to the server, what it's doing is creating a socket and then calling connect and send on that socket. When the server gets this incoming connection, it might not care if this is the same client as some previous connection. If does care (e.g. it has logged-in sessions or shopping carts) it has to use cookies or whatnot if to associate this connection with previous ones. (I'm ignoring persistent connections, which are beyond the scope of your question.)
But when the browser receives the response from the server, it does so by calling recv on the same socket that it used to send the request, so it knows which request that response goes with before it even starts reading it. In theoretical terms, the browser is maintaining state information about the connections it has open. In practical terms, it has a list or array of sockets.
The browser also keeps track of which windows and tabs are associated with which sockets. This is how it can update the spinners and status lines to reflect the status of the corresponding connections. And if the user clicks the stop button, it knows which socket (or sockets) to close.
So in your scenario, the user has clicked a link or bookmark in a window or tab associated with an existing socket representing a connection to a server where the server's response hasn't been received yet. The browser can simply close that socket as if the user had clicked the stop button. And even if it didn't close it, the browser knows the user no longer wants to see the response. Meanwhile it opens a new socket to the server the user is interested in.