[rabbitmq-discuss] Client connect/disconnect events on the server side

[Miguel Morales]

> 'presence' is a highly application dependent concept. Support for it in the
> messaging system itself could only accommodate a very restricted set of use
> cases. So it's best handled by applications.
>
>
Yeah, definetly.  It would be *kind of* cool to have that built into
rabbitmq but not a necessity by any means.  There are several points where
one may want to hook into such as when the connection happens, when a bind
has been made, etc.


> One fairly generic and flexible way is to get clients to publish a presence
> message every so often to some dedicated exchange. That message can contain
> all kinds of application specific information, e.g. to identify the user,
> what their status is, etc. An app can then consume these messages, update
> some db with status information, send status change messages to clients
> interested and authorised to see them (e.g. 'friends'). The app can also
> detect the absence of the messages and mark the user as absent.
>
>
Yeah, this was the road I was heading toward.  In my use case this is fine.
 However, I think that it might be difficult for an app that doesn't require
the client to publish any messages in order to be active.  For example, in a
cell phone where one wants to send the least amount of data but still wants
to receive any small messages from the server.
Also, if one wants to detect absence as soon as possible.  The client would
have to rapidly be transmitting status packets.

The other option would be to map the users by their ip and detect events via
a tcp proxy as you suggested earlier.

In this scheme
>
> - the notion of presence is not tied to the lifetime of connections, or
> queues, or bindings
>
> - the notion of users (or, more generally, 'the things of which we want to
> know the presence') is not tied to that of AMQP users
>
> - presence can be more than just a flag, i.e. all kinds of complex status
> information can be transmitted
>
>
I think this is a fundamental flaw in my setup is that clients are tied to
users.
But even is a single user scheme is implemented, it would still be difficult
to detect when clients connect/disconnect in real time.  I'm probably
missing something though.

The way I'm going to detect this is by having the client have another tcp
socket connection open to another port on my server.  Then a server side app
that listens on that port can detect if the client connected/disconnected at
the socket level.  (It uses the same credentials as the rabbitmq server so
the client has to 'log-in' to both services.)

Thanks for your help,
Miguel.


> Regards,
>
> Matthias.
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>



-- 
~ Jeremiah:9:23-24
Android 2D MMORPG: http://solrpg.com/ http://www.youtube.com/user/revoltingx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110315/4c9e048c/attachment.htm>