Adrian Sietsma wrote:
Steve Kann wrote:
but if we get 1,2,4,5,3 then it is 4
Here's what happens for each frame:
1: OK, acked
2: OK, acked
4: this is out-of-order, ignored (vnak could be sent, but it doesn't
really matter)
5: same as 4.
3: This is OK, and gets acked.
...
If that is so,then how do frames 4 & 5 ever get acked ?
They would be retransmitted, because they are not acked the first
time they're sent, and eventually, the retransmits would be acked.
Ok, got it.
This would imply that _all_ frames received subsequently would be
ignored, until frame #4 re-arrives, and resets the sequence ?
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.
I have noticed that iaxclint goes into a "retry frenzy" if hammered
with too many full frames (text) too quickly, over a lossy (wireless)
link. Ethereal reports blocks of packets being retried, despite being
recieved ok.
Adrian
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
