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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
