<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
'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.<br>
<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br></blockquote><div><br></div><div>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.</div>
<div>Also, if one wants to detect absence as soon as possible. The client would have to rapidly be transmitting status packets.</div><div><br></div><div>The other option would be to map the users by their ip and detect events via a tcp proxy as you suggested earlier. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this scheme<br>
<br>
- the notion of presence is not tied to the lifetime of connections, or queues, or bindings<br>
<br>
- 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<br>
<br>
- presence can be more than just a flag, i.e. all kinds of complex status information can be transmitted<br>
<br></blockquote><div><br></div><div>I think this is a fundamental flaw in my setup is that clients are tied to users. </div><div>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.</div>
<div><br></div><div>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.)</div>
<div><br></div><div>Thanks for your help,</div><div>Miguel. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br><font color="#888888">
<br>
Matthias.</font><div><div></div><div><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>~ Jeremiah:9:23-24<br>Android 2D MMORPG: <a href="http://solrpg.com/" target="_blank">http://solrpg.com/</a> <a href="http://www.youtube.com/user/revoltingx" target="_blank">http://www.youtube.com/user/revoltingx</a><br>