<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Rod Dorman wrote:
<blockquote cite="mid111484294.20060306145624@polylogics.com"
type="cite">
<pre wrap="">On Monday, March 6, 2006, 14:26:59, Steve Kann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Adrian Sietsma wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> ...
This would imply that _all_ frames received subsequently would be
ignored, until frame #4 re-arrives, and resets the sequence ?
</pre>
</blockquote>
<pre wrap="">That's correct. That's how it works presently, and the way it would
have to work, unless the receiver stored out-of-order frames (which
would be a worthwhile optimization to make for the lossy link case, as
you note below). I think that such an "out-of-order" reciever store
could be done without changing the specs, though -- as long as it
doesn't _act_ on frames out-of-order, it could probably defer processing
them until it got the missing frame.
</pre>
</blockquote>
<pre wrap=""><!---->
Is it worth stating that explicitly by saying something along the lines
of:
"The receiver MAY store out-of-order frames but MUST NOT process
them until it receives the missing frame."
</pre>
</blockquote>
It wouldn't hurt to put that in there, so it's clear that clients may
do this, and it's a good hint to implementors about how they can
improve their implementation. I don't think there's a strong need for
this in current practice, where there are few full frames sent in a
typical call. I also don't think it would change anything, because as
far as the sender is concerned, it can't really tell that a client does
this, because the effect is basically the same as would happen if there
was or wasn't reordering in the network.<br>
<br>
<br>
-SteveK<br>
<br>
</body>
</html>