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