[Standards-JIG] Closing idle streams
stpeter at jabber.org
Thu Jun 1 19:48:03 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards