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

[Benjamin Renaud]

Our REST server would like to be notified when clients connect and
disconnect. Is there a facility (standard event?) in RabbitMQ for
this?

Thanks!
Benjamin

--
ben renaud
versly.com
b...@versly.com
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Simon MacMullen]

On 13/03/11 22:07, Benjamin Renaud wrote:
> Our REST server would like to be notified when clients connect and
> disconnect. Is there a facility (standard event?) in RabbitMQ for
> this?

Not ATM. I wonder about implementing such a thing since it occasionally
gets asked about, although I'm not sure what it would look like. Are you
talking about something that would send the sort of information that the
management plugin shows for connections, but as events on connect /
disconnect? Or something else?

Cheers, Simon

--
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware

[Miguel Morales]

I too would be interested in this.  Not sure if anything like this exists but basically it could be some sort of callback mechanism where we are notified of when a client has connected/disconnected to the broker.

--
~ Jeremiah:9:23-24
Android 2D MMORPG: http://solrpg.com/ http://www.youtube.com/user/revoltingx

[Matthias Radestock]

Miguel,

On 14/03/11 19:27, Miguel Morales wrote:
> I too would be interested in this. Not sure if anything like this
> exists but basically it could be some sort of callback mechanism where
> we are notified of when a client has connected/disconnected to the broker.

What do you need this for?

And what information would have to be passed to such a callback?

If you are just interested in network-level connect/disconnect events
then a simple TCP proxy could give you that information.

Or you could do some live processing of rabbit's log files, which,
amongst other things, contain all connect/disconnect events. Or you
could get the log events over AMQP by binding to the amq.rabbitmq.log
topic exchange.

Regards,

Matthias.

[Miguel Morales]

Mathias,

Well I haven't researched this, but it's something that I need to implement in the near future.

Basically, I have a public broker which clients (android devices in my case) connect and disconnect.  When they log-in it would be considered that they are 'active' if they log-out it would be considered that they are 'inactive.'

This is important because other clients need to know information about 'active' clients.

I haven't done much research into it because I'm avoiding it until I get closer to release it to the real world.

I am indeed interested in network connects/disconnects, but I would also need to know the username of the client that just logged in.

(for example, if the client suddenly disconnects I need to set their status to 'inactive' in my global database.)  

Other than that, I think my best choice would be to bind to the amq.rabbitmq.log exchange (didn't know about it before) and parse the log messages.  

However, that seems a bit brittle for me (might change between versions), but it would work well.

Thanks for your suggestions, it might help the original poster as well.

On Mon, Mar 14, 2011 at 12:43 PM, Matthias Radestock <matt...@rabbitmq.com> wrote:

Miguel,

On 14/03/11 19:27, Miguel Morales wrote:

I too would be interested in this.  Not sure if anything like this
exists but basically it could be some sort of callback mechanism where
we are notified of when a client has connected/disconnected to the broker.

What do you need this for?

And what information would have to be passed to such a callback?

If you are just interested in network-level connect/disconnect events then a simple TCP proxy could give you that information.

Or you could do some live processing of rabbit's log files, which, amongst other things, contain all connect/disconnect events. Or you could get the log events over AMQP by binding to the amq.rabbitmq.log topic exchange.


Regards,

Matthias.

[Matthias Radestock]

Miguel,

Miguel Morales wrote:
> Well I haven't researched this, but it's something that I need to
> implement in the near future. Basically, I have a public broker which
> clients (android devices in my case) connect and disconnect. When
> they log-in it would be considered that they are 'active' if they
> log-out it would be considered that they are 'inactive.'
>
> This is important because other clients need to know information
> about 'active' clients.

Ah, so this is about 'presence'. That has come up a few times before.
Might be worth searching the archives.

> I am indeed interested in network connects/disconnects, but I would
> also need to know the username of the client that just logged in.
> (for example, if the client suddenly disconnects I need to set their
> status to 'inactive' in my global database.)

Is the fact that a client has connected with a particular user name
really indicating presence? Or is their presence perhaps only
established when they start consuming from a queue?

> Other than that, I think my best choice would be to bind to the
> amq.rabbitmq.log exchange (didn't know about it before) and parse the
> log messages. However, that seems a bit brittle for me (might change
> between versions), but it would work well.

Unfortunately (for you) there is no log message containing the user name.

[Benjamin Renaud]

So we need it because our clients collaborate on the same resource,
and we want to use the connection essentially as 'presence'
information - that someone is working on the the same resource.

Ideally, we'd pass in a user id when connecting, and we could register
(on the exchange perhaps) to know when that a client comes in and out.

We have to deal with the issue where a user shuts their laptop and the
client goes away. It seems like Rabbit would be well positioned to
tell us that.

BR

--
ben renaud
versly.com
b...@versly.com

[Miguel Morales]

Mathias,
 

Is the fact that a client has connected with a particular user name really indicating presence? Or is their presence perhaps only established when they start consuming from a queue?

Well, presence is established when they subscribe to an exchange.  The way I have it now is that they have to 'announce' themselves when they log in by publishing a message.

However, I currently have no way of knowing when they disconnect and be able to tell the other clients that the user is no longer active.

 

Unfortunately (for you) there is no log message containing the user name.

Damn that sucks, I'll have to look through the archives and see if other people give hints as to a proper solution.

Thanks,

Miguel.

[Deepak Vijayvergiy]

Hi Miguel,

Even I have the same scenario, and I have my clients announcing(publishing) their connect and disconnect at the time of log-in and log-off resp. I have a deamon process running which is a pure consumer listening on 'register.*'. 

Would be interested to know if some better way exists.

Thanks

Regards

Deepak

[Matthias Radestock]

On 15/03/11 04:31, Deepak Vijayvergiy wrote:
> Hi Miguel,
> Even I have the same scenario, and I have my clients
> announcing(publishing) their connect and disconnect at the time of
> log-in and log-off resp. I have a deamon process running which is a pure
> consumer listening on 'register.*'.
> Would be interested to know if some better way exists.

'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.

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.

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

Regards,

Matthias.

[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...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

[Benjamin Renaud]

Hi Matthias,

Yes presence is a very application-specific bit of information.

Being notified of when a client connects or disconnect (even if rabbit
tries to auto-reconnect or other nice features under the covers) would
help application developers develop their own notion of presence.

In other words, rabbit is the one persistent connection we have to our
clients. When the rabbit connection disconnects or reconnects, Rabbit
is the only bit of software with that information.

Without having Rabbit interpret that information (let me do the
interpreting) it would be great to just know the information.

Benjamin

--
ben renaud
versly.com
b...@versly.com