On Thu, Aug 17, 2006 at 11:38:46PM -0700, Damien Neil wrote: > I think that TCP blocking is unimportant; only the remote system > processing (database, etc.) is important. If the TCP connection > blocks, then the remote peer unquestionably has pending messages > available to reset its tReceive timer--problems only occur when the > remote peer stops reading additional messages, regardless of whether > the TCP channel has blocked or not. If the remote peer stops reading any message at all, that blocks the TCP stream, from a certain point of view. So it all leads back to TCP blocking, and that makes it the easiest way to describe the problem. > To look at this in a different light: If a peer has a TCP receive > buffer of infinite size, such that the TCP connection never blocks, I think if the document intended that it was specifically a TCP protocol layer blocking issue that it epxected to avoid, it would have said "...cause the TCP window size to reach zero." I think the term "TCP blocking" is more generic, and covers a variety of situations we're all familiar with. It's possible other words would acheive the same result without being too specific, however. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpf4ZGA7WX4g.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg