[Standards-JIG] Closing idle streams

Peter Saint-Andre stpeter at jabber.org
Thu Jun 1 19:48:03 UTC 2006

Hash: SHA1

Matthew A. Miller wrote:
> Carlo v. Loesch wrote:
>> Matthew A. Miller typeth:
>> | Maybe my reading comprehension skills are lacking, but I read this
>> to | mean what one MUST do is:
>> | 1)  send  the appropriate <stream:error/>
>> | 2)  send the closing </stream:stream>
>> | 3)  terminate the underlying TCP connection
>> No you understood perfectly, only that by terminating the connection
>> you no longer give the other side the chance to finish whatever it
>> may have started sending, thus risking loss of data.
> Usually, when I see "<connection-timeout/>", it means that one side got
> "stuck", not that it's an idle timeout.
> If it's an idle connection, and if the other side were sending
> something, it would not be idle, at least within the TCP stacks
> (tcpdump/ethereal can be very educational about this).
> If it's a true stream error (e.g. resource constraints, malformed XML,
> etc), the "closer" can almost never do anything with the "closee's" data
> anyway.
> I can see there being a possible race condition, so possibly making a
> change from ", send the closing </stream> tag, and" to something like ",
> close both sides of the <stream> document if possible, and".  I add "if
> possible" because there are times when it might not be possible to
> receive/process any more data anyway (I would argue that this is the
> rule, not the exception).
> However, I can also see (in the idle connection case) that the stream is
> merely ended, without any error.  To me, this does not really seem to be
> an error condition, per se, but the matching of some policy condition
> (note I did not say "policy violation").  In which case, you should be
> waiting for the other </stream:stream>.

Aha, that reasoning makes sense to me -- in a sense, there is no active
error condition, just a kind of passive reason to drop the stream.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060601/98421db2/attachment.bin>

More information about the Standards mailing list