Revisiting connected user count

[Gabriel Benmergui]

Hey Alex. Conanbatt from github here.

I run into this matter with my current gaming site, and its a revisit
of the proposed solution in the documentation(and holla example) of
counting connected users.

To give some context, my gaming site is a Go server. Users chat a lot,
and also play/observe games. By our current design, those activities
are not in the same page.

Games are listed and players can join to watch or play which open up a
new tab. Often, more by mistake than by intent, users enter twice into
the same game.
At this point, the user has "3" jugger connections (main page, and
twice into the same game).

He is also connected, by the ruby-server terms, to "main page" and
"game page". So here comes an issue, because he has 3 jugger
connections, but really 2 in how one would model being in a channel or
not.

So this shows its face when a user disconnects from one of the game
pages. I can tell he reduced his connections from such a page, but i
cannot tell if he is not really watching that game still, from another
page : the only thing i have is a number (juggernaut connection
counter).

To fix this, i would need to track exactly which connection counter
goes to which channel, so users have an indefinite amount of counters
("main_page_jugger_conenction_counter",
"game_page_jugger_connection_counter") etc etc. (or channels have them
by connected user).

This is definitely a solution,but it lead me to think that maybe it
would be better for juggernaut to provide some mechanisms to make this
easier.

Another solution would be to not allow the user to connect twice to a
game like that, for example. But that brings a another dimension of
things to consider that are particular of my application. For example,
since i cannot disconnect him from the juggernaut channels, i would
only prohibit him from opening a new page, which could be
uncomfortable if he doesnt find the previous one.

This lack of information is a weakness in the adoption of juggernaut
(as it is uncomfortable to start with) and it is also error-prone.

So far the n#1 reason of stale information on connected users happen
from the case above. The counter is probably precise, but i cannot
tell to which channels the user is really connected to.

The #2 is from times the observer crashed by an exception, and there
was a time-window where disconnects where not properly processed.
although this is rare because the observer is light and rarely has
bugs, i have no way of recovering the information not processed at
that point. My only option is to clean out every single users account
and eventually when hey log back in it gets back on track.

Maybe a concise question would be "will juggernaut ever support user
connection tracking?". Otherwise im sharing some design issues im
going through, maybe for insight by someone that has more intricate
knowledge of the techincal solution or that has gone through similar.

[Nicolas Cavigliano]

Conanbatt,

I won't speak for Alex, but from what I gather, juggernaut won't support user tracking or user connection tracking. I don't think it should either. It's purely a push server and shouldn't have more logic than that. It scales well and is very well modularized to handle what you throw at it.

That being said, if I was to do this, which I will be doing soon, I would abstract user tracking out to another nodejs class or module; either by creating a separate module or extending juggernaut myself. You can subscribe to certain events and do the tracking yourself through some other means and persistence store. I haven't messed around with juggernaut for a few months, but the whole point of not building this logic in is to keep it abstract enough to scale as need be. Juggernaut doesn't need to know who is who, it just does it's job and leaves it up to you to extend if you need more client logic.

--
You received this message because you are subscribed to the Google Groups "Juggernaut 2" group.
To post to this group, send email to juggernaut...@googlegroups.com.
To unsubscribe from this group, send email to juggernaut-for-r...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/juggernaut-for-rails?hl=en.

[Gabriel Benmergui]

I like your idea of extending juggernaut with modules and such, which
is what i think should somehow be thought of .

I understand the desire to keep juggernaut clean and lean, but being
forced to mimick juggernaut's channel system on my application just to
keep track of user count is not DRY or logical in anyway.
So maybe that should be the kickstart of the discussion: can
juggernaut 2 be extended with optional modules that do this?

[Bill Walton]

I haven't had time to dig into the Juggernaut code, so I apologize in
advance for the uninformed nature of this question, but, from an
architecture perspective, is the user count mechanism most logically
an extension of Juggernaut? Or of node.js or redis ? My impression
is that the subscriptions themselves are not 'kept' in Juggernaut.

Thanks,
Bil

[Nicolas Cavigliano]

Well, yes, you can extend the classes or prototype objects if you wish. I've actually done that a bit with my implementation. The major problem you have with including roster logic in juggernaut is once you start clustering the juggernaut server across n machines. Each juggernaut server is responsible for itself and doesn't know, or need to know about the other n instances running. 

The way I'm doing this now, in pseudocode...

Juggernaut running N instances with some extending and included methods (for prototype extension)

Separate process listens to same channel in redis (pub/sub)

Parse out the subscribe/unsubscribe messages and do something, in this case manage a user roster

Include more information than just a user_id in the subscribe and unsubscribe events, such as the socket uid so you can differentiate between socket connections, and not just a given user

Store info somewhere

Now I can see for debugging purposes, it might be necessary to ping a jug server for it's current Client hash. That can be extended fairly easily, but you really don't want to make that the norm. 

Make sense?

[Nicolas Cavigliano]

Sorry, I wanted to add one more thing.

There are benefits to modularizing and separating out the roster stuff. The websocket spec, I think, is now finished? But for the longest time browser implementations were different and inconsistent (thus socketio). So you can't assume once a socket is established, it will stay established without a user state change. To solve the problem of "user x left. user x joined" because of constant socket reconnects, you can have this separate process use a timeout or TTL for certain events that wouldn't be as natural to do in nodejs. 

Another thing came to mind, being able to admin connections. I haven't given much thought yet, but the first thing that comes to mind would be to extend juggernaut to include a blacklist or maybe even utilize the existing redis store to do a check to see if a certain message should be published to or from a specific socket connection. Either way, I think this should also be done through this separate service that is silently monitoring the redis pub/sub channel