RE: [lwip-users] issues with resending out of order segments

[Kesten, Joerg]

I think with the ideas you gave me I finally found were the issue is, I am just 
not sure if it is a lwip issue or if I am using it wrongly ;-)

Here is what happens:
* some segments are send and added to the unacked queue (say n to n+5)
* segment "n" gets lost
* after some time tcp_rexmit moves segment n from the unacked back to the 
unsent queue.
* The current state is
   - one segment (number n) is in the unsent queue
   - some further segments are still in the unacked queue (n+1 .. n+5) (the 
actual count is not important here)
* Now tcp_enqueue is called, segments n+6 and n+7 get enqueued

!!* tcp_enqueue detects one non-full segment in the unsent queue (n) and 
concatenates/chains the first new segment (n+6) to it
!!* so what happens is that the data from segment n+6 gets appended to segment 
n, and n+7 gets added to the unsent-queue.

* tcp_output (re)sends segment n (piggybacking the data from n+6 which by this 
ends up in the nirvana)
* segment n is received correctly by the peer and all unacked segments are 
acked at once (up to n+5)
* next segment send is n+7


So the question would be (to me): Is tcp_enqueue just called in the wrong 
moment, or should the "chain" mechanism be improved to verify that the two 
segments it tries to chain are really consecutive? Or is there something else I 
am missing?

- Jörg


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Kieran Mansley
Sent: Montag, 21. September 2009 12:39
To: Mailing list for lwIP users
Subject: RE: [lwip-users] issues with resending out of order segments

On Mon, 2009-09-21 at 12:21 +0200, Kesten, Joerg wrote:
> 
> > Multithreaded sockets is something that is not well supported on lwIP,
> > so I'm not surprised you've had to add some extra locks.  If you're
> I am (painfully ;-)) aware of that. A completely other issue, but is
> it right that there is currently no intention to support this as there
> seem to be only very few people needing this? At least this was the
> impression I got from reading several discussions related to this on
> the homepage (bugs section)

I would like to get lwIP to the point where different threads using
separate sockets is fine, but not different threads using the same
socket.  There is a move towards a re-write of the sockets layer, and I
expect that this would be solved as part of that.  If there's a simple
bug we can fix in the meantime to improve things though I would be happy
to see it included. 

> > How do you call netif_add()?  This function specifies which function
> > will be called (stored in netif->input) when a packet is received by
> > ethernetif_input().
> Here is my call to netif_add:
> netif_add( netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, 
> tcpip_input));

That looks fine: tcpip_input should serialise received packets so they
are not processed at the same time as sending ones.

The only other contender would be TCP timer processing happening in
parallel with a data operation.  Perhaps that is worth checking,
although timer events are supposed to be dealt with by the tcpip module
in your situation without the need to call them externally.  Looking at
the code I think this could be the problem: timers are processed when a
thread blocks, so if one of your threads blocks (see comment to
sys_timeout() for full details) and this could be a different thread to
the one that owns the connection.  When the timer expires and the
tcp_tmr() function is called to process TCP operations, this could
therefore happen in parallel with a data operation on the same
connection.  I'm not sure what the best way to fix this is though: it
will need some thought.

> > No, if you're using the APIs correctly you shouldn't need to manually
> > lock these lists.
> Ok, thinks.
> BTW: There is this LWIP_TCPIP_CORE_LOCKING define in opt.h which
> obviously should not be used and therefore I did not change the
> default here... but to me it sounds as if this could be exactly the
> thing I'd need here?

Frederic Bernon is the expert on that and how it should be used, but it
might be worth trying.

Kieran



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users