lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] using two memory pools for pbuf


From: Kieran Mansley
Subject: Re: [lwip-users] using two memory pools for pbuf
Date: Thu, 07 Apr 2011 17:22:25 +0100

On Thu, 2011-04-07 at 15:54 +0200, Thomas Richter (TCD - DE/Dresden)
wrote:
> 
> I´m still working at the problematic that I have to inform from one
> side
> of the Ethernet connection to another side that RNR (receive not ready
> =
> can not handle more data, please wait) occurs.
> I thought that I can be use TCP buffer handling and if window size is
> 0
> (in TCP header) than the information will be transported from one to
> another side.

I really don't think this is going to work well.  The receiver is not
supposed to shrink the window (i.e. artificially reduce what it has
previously advertised as being available) and the sender is free to
ignore it if it does.

Why not:
 1) just buffer the data on the receiver in the TCP stack (i.e. don't
call recv()) when RNR is set, and use the standard TCP windowing to
limit the amount of buffering that is necessary.  This would require a
little bit of buffering on the receiver (which you might not have the
memory for) but (i) how much buffering is set by how large you open the
TCP window, which you can already easily control and (ii) it will work
the best of all the options I can think of.  This is better than any
system that notifies the sender as there is an inevitable time delay in
telling the sender, and so an inherent race.  If you buffer on the
receiver when RNR is set you can avoid the race entirely as delivery to
whatever is setting RNR is entirely within your control. 

 2) Or layer your own protocol on top of TCP that will have the
semantics that you want.  i.e. the receiver tells the sender when RNR is
set and the sender would stop sending.  You'll still have to deal with
the case where the "RNR set" message is in flight (so the sender doesn't
know yet) and the sender sends something.  In that case you might be
forced to just drop the packets (see 3) if you can't buffer them (see 1)

 3) Alternatively you might have to just drop packets at the receiver
when RNR is set.  If RNR is only on for a short time this might be OK.
The other side will soon retransmit them.  If RNR is on for a long time
then it might cause delays and connections to time out however.

Kieran




reply via email to

[Prev in Thread] Current Thread [Next in Thread]