5

I was implementing a chat application. I am not in server and the page which contains javascript file can be any html page on file system with the embeded javascript/socket.io in it.

Now the problem is page reload by definition will always trigger a new request resulting in new socket. 

$(document).ready(function() {

var messages = [];
socket = io.connect(connectionString);
///next code sequence
});

what I want to achive is even after page reload my session should persist. now the classic way to implement is.

1) I can keep a classic implementation. fire disconnect; once done I can actually keep the previous sessionid and from database could refetch the previous session/ chats and continue.

but the above approach is very clumsy and time consuming.

is there anything better that can be done ????

ManMohan Vyas
  • 4,004
  • 4
  • 27
  • 40

2 Answers2

7

webSockets will disconnect and reconnect anytime a page is reloaded or anytime the user navigated. As it sounds like you know, that is just how they work.

If you want a persistent session for the user, then you can simply do the same thing that any web page would do to identify a session or user using a cookie. If your site has user login, when a user connects, you grab that user's identify from their login cookie and use that as a persistent user identifier for any webSocket connection. Since any webSocket connection starts with an http request, that cookie will always be there.

If/when the user reloads or navigates to another page on the site, the webSocket will disconnect and when it reconnects, the user login cookie will again be there.

If you don't already have a user login cookie, then you can detect that there is no user identifying cookie when the user first connects and you can set such a cookie so that it is there for future reconnects. The identifier in this cookie will then be a key into your database so you can correlate a browser with a given user's data.

If your server needs to know when a user is actually gone, then you can implement some sort of server-side timeout and when a user remains disconnected for some period of time (e.g. some number of minutes), then it is clear that the user is not just momentarily navigating between pages and you can mark them as logged out now. But, on a normal reload or page navigation, the user will always reconnect within a few seconds of the disconnect, so your server won't log them out.

If you have data that is truly client-side only, you can also store that in local storage in the browser to improve efficiency when going from page to page (so they data can be stored and then read locally rather than getting it from the server), but that makes the data only available in that specific browser on that specific computer which is often not what you want if the data is tied to a user login and you want the data available to that user no matter which browser or computer they login on.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • the only problem with server disconnect time increase - approch is that on relaod socket gets changed. – ManMohan Vyas May 04 '15 at 05:16
  • @ManMohanVyas - yes, a reload causes a new socket to be connected. You cannot avoid that. – jfriend00 May 04 '15 at 05:35
  • I was maintaining session based on socket, as on disconnect I get nothing more than socket. the last thing on which I need answer is does setInterval() function uses more resources if I use that freequently my chat application will have around 10k concurrent users?? – ManMohan Vyas May 04 '15 at 05:52
  • @ManMohanVyas - It depends upon how often you're calling `setInterval()` and what you're doing each time you call it. Used poorly, it could take a lot of sever resources. Used occasionally, it wouldn't even be noticed. You should identify your users by something other than just their socket (e.g. a cookie that you can see when they connect) and then put that identifier on the socket object as a custom property. – jfriend00 May 04 '15 at 06:01
  • This is the exact approach I took. In my case I placed the logic for reading the cookie in the connection listener which gets called when a new client connects to the socket. Then if the cookie is present, I simply load the former state from my database and this is done just once for the lifetime of the connection. If the client disconnects again, I do the same again. As for knowing when the client refreshes, my thought will be to set a counter variable in your cookie that is incremented on each page refresh. The server reads this cookie and knows if the client refreshed or not. – Dave Kalu Jun 23 '19 at 20:34
0

You could store a value on the client side using the following module: https://github.com/grevory/angular-local-storage

It will use HTML5 local storage with a fallback to cookies.

braks
  • 1,505
  • 15
  • 23