Re: How is a client crash communicated to the XMPP server?
Jonathan Dickinson <jonathanD <at> k2.com>
2008-06-02 08:57:27 GMT
Good question.
You will find that the Coversant XMPP communicator does not send a <presence type="unavailable"/> stanza
when it logs out. From what I can tell is that most servers will do that on behalf of the client: it caused me a
few minutes of debugging :).
If you want to tell when the client disconnects unexpectedly from another client (e.g. if you have a contact
that represents your server availability or something) you could do something like:
<presence type="available">
...
<!-- NB: No 'graceful' element -->
</presence>
<presence type="unavailable">
...
<graceful xmlns="http://www.tempuri.org/xmpp.org/graceful">
</presence>
If you receive a stanza without the graceful element you can be sure that the client quit unexpectedly
(server sent 'unavailable' on behalf of the client).
This raises another important question: most servers AND clients are not XMPP compliant. It is very
strange and annoying. Should I take a 'tough luck, you should behave properly' approach to non-compliant
clients and servers?
> -----Original Message-----
> From: jdev-bounces <at> jabber.org [mailto:jdev-bounces <at> jabber.org] On Behalf Of
> JabberForum
> Sent: 02 June 2008 10:25 AM
> To: jdev <at> jabber.org
> Subject: [jdev] How is a client crash communicated to the XMPP server?
>
>
> Hi,
> I would like to discuss about what happens when an XMPP client crashes
> and how this information is communicated to the server..
>
> I have a server S and 2 clients C1 and C2 connected to the server. C1
> has C2 in its roster list and C2 has C1 in its roster list.
>
> If C1 gracefully logs out, then an iq stanza of type unavailable is
> sent to the server and the server broadcasts that stanza to all JIDs
> which have a subscription of from or both.
>
> However, I have been trying to search for what happens when the
> client crashes (or exits ungracefully). I havent arrived at the answer
> yet. Here is what RFC 3291 says :
>
> "5.1.5. Unavailable Presence
>
> Before ending its session with a server, a client SHOULD gracefully
> become
> unavailable by sending a final presence stanza that possesses no 'to'
> attribute and that possesses a 'type' attribute whose value is
> "unavailable" (optionally, the final presence stanza MAY contain one or
>
> more <status/> elements specifying the reason why the user is no longer
>
> available). *However, the user's server MUST NOT depend on receiving
> final
> presence from an available resource, since the resource may become
> unavailable unexpectedly or may be timed out by the server. If one of
> the
> user's resources becomes unavailable for any reason (either gracefully
> or
> ungracefully), the user's server MUST broadcast unavailable presence to
>
> all contacts *(1) that are in the user's roster with a subscription
> type of
> "from" or "both", (2) to whom the user has not blocked outbound
> presence,
> and (3) from whom the server has not received a presence error during
> the
> user's session; the user's server MUST also send that unavailable
> presence
> stanza to any of the user's other available resources, as well as to
> any
> entities to which the user has sent directed presence during the user's
>
> session for that resource (if the user has not yet sent directed
> unavailable presence to that entity). Any presence stanza with no
> 'type'
> attribute and no 'to' attribute that is sent after sending directed
> unavailable presence or broadcasted unavailable presence MUST be
> broadcasted by the server to all subscribers. "
>
> Do we interpret that as : "the server will 'somehow' know that the
> client has crashed and then publish the unavailable stanzas to everyone
> subscribed to that JID ?
>
> Please clarify.. 
>
> -santhosh
>
>
> --
> santhosh.kulandaiyan
> ------------------------------------------------------------------------
> santhosh.kulandaiyan's Profile:
> http://www.jabberforum.org/member.php?userid=16912
> View this thread: http://www.jabberforum.org/showthread.php?t=200
>
> _______________________________________________
> JDev mailing list
> FAQ: http://www.jabber.org/discussion-lists/jdev-faq
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe <at> jabber.org
> _______________________________________________
_______________________________________________
JDev mailing list
FAQ: http://www.jabber.org/discussion-lists/jdev-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe <at> jabber.org
_______________________________________________
>>
>> Peter
>>
>
> Hi,
>
> even though I have some idea about this, could you give an example
> (even a bad one conceptually, just to have a concrete example) about
> this, for instance in the context of what Kelly wants to do please?
> Thanks.
The old pubsub.com service is a good example. They build a nice web
interface for choosing your feeds. Most of those used keyword matching
(e.g., send me all entries that match either "Jabber" or "XMPP") but you
didn't have to worry about the exact NodeID syntax over XMPP, they did
that in their application layer above XEP-0060.
Peter
RSS Feed