This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Patch redboot tcp, suggestion
- From: Hendrik Ruijter <hendrik dot ruijter at axis dot com>
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Mon, 04 Mar 2002 09:30:29 +0100
- Subject: Re: [ECOS] Patch redboot tcp, suggestion
- Organization: Axis Communications AB
- References: <3C7CDEC1.90704@axis.com> <3C7FD166.654D2AAE@redhat.com>
Jonathan Larmour wrote:
> Hendrik Ruijter wrote:
>
>>Acknowledgements for retransmissions of segments
>>with sequence numbers lower than the assumed last
>>acknowledged were never sent.
>>
>>The code at present sends an ACK on every segment
>>which should be improved together with proper window
>>advertisment.
> I'm not completely convinced that this can be completely correct - the
> problem you describe may exist, but this fix may have other side effects.
It is not. The problem exists. The side effect I saw
is that a handshake-protocol is implemented by the fix.
> So just so I can be clear on this: the code you've #if 0'd out could cause
> an ack to be sent for a sequence number later than the one that the
> retransmission was actually requesting?
To be honest, neither I nor the collegue i consulted for
a sanity check could understand the comment. It may be a
misunderstanding of acknowledgement handling by the implementation.
We together assumed that:
* we can't send an ack if our write packet is holding
* outgoing data pending an incoming ack.
meant something handshaky which, if so, is completely
wrong. Either an ack may be piggy-backed or sent as a delayed
ack.
We further thought that the non-implementation of window advertisments
may have caused severe problems, e.g. the packet exhaustion debug code
in enet.c. The state variables there are used in a similar manner.
".. retransmission was actually requesting?" I think the question is
not well-formed. It is a stream. If a segment is retransmitted, the
receiving side may have buffered later segments correctly, and the
ack sent is not requested, it is a consequence of the number of segments
correctly received.
> But if so, what _will_ send the ack?
I do not understand the question, I am afraid.
I have time allocated in a project starting soon. I will try to
provide something better than a fix.
Brgrds,
Hendrik Ruijter
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss