[Standards-JIG] Closing idle streams

Matthew A. Miller linuxwolf at outer-planes.net
Thu Jun 1 19:36:53 UTC 2006

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 

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

-  LW

"Got JABBER(R)?" <http://www.jabber.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3543 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060601/0845a4b8/attachment.bin>

More information about the Standards mailing list