[Standards-JIG] Closing idle streams

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
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

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

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

iD8DBQFEf0RzNF1RSzyt3NURAoDFAKCpmoShXNFJJKRwswIOsQffchnqIwCeJjYT
1HE2jyJrX1I306MHoxeZXSM=
=4Wyf
-----END PGP SIGNATURE-----
-------------- 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/smime.bin