Send lwip-users mailing list submissions to address@hidden
To subscribe or unsubscribe via the World Wide Web, visit https://lists.nongnu.org/mailman/listinfo/lwip-users or, via email, send a message with subject or body 'help' to address@hidden
You can reach the person managing the list at address@hidden
When replying, please edit your Subject line so it is more specific than "Re: Contents of lwip-users digest..."
Today's Topics:
1. Re: Problem with fragmented TCP packets using slow 3G connection (Maciej Gajdzica) 2. Re: TCP socket thread safety (Pomeroy, Marty)
Message: 1 Date: Mon, 25 Feb 2013 15:23:00 +0100 From: Maciej Gajdzica <address@hidden> To: Mailing list for lwIP users <address@hidden> Subject: Re: [lwip-users] Problem with fragmented TCP packets using slow 3G connection Message-ID: <address@hidden> Content-Type: text/plain; charset="iso-8859-1"
I dont really know how to interpret these data. Maybe someone more familiar with tcp debug could help me?
Maybe that issue is fixed in 1.4.1, as there was some changes in tcp code according to 1.4.1 changelog. I will check it out.
On Fri, Feb 22, 2013 at 8:42 PM, Simon Goldschmidt <address@hidden> wrote:
> "address@hidden" wrote: > > Perhaps it could be, that there is still a Problem with Bug #24212. > > It has been said, that the Bug has been fixed. I dont really trust in > this. > > A statement like this belongs into the bug tracker or at least in a > suspected bug report on lwip-devel, not into a side-note on lwip-users. > > Unfortunately, I don't have much time for lwIP, lately. If that bug would > be reopened, it would make sure things don't get forgotten. > > Simon > > _______________________________________________ > lwip-users mailing list > address@hidden > https://lists.nongnu.org/mailman/listinfo/lwip-users >
-- 762687 INNOVATION CODE <http://www.762687.com> Tel: +48 783 367 232 Kom: +48 519 136 410 E-mail: address@hidden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.nongnu.org/archive/html/lwip-users/attachments/20130225/f68d29ec/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: lwip_debug.rar Type: application/rar Size: 10614 bytes Desc: not available URL: <http://lists.nongnu.org/archive/html/lwip-users/attachments/20130225/f68d29ec/attachment.rar>
------------------------------
Message: 2 Date: Mon, 25 Feb 2013 09:44:07 -0500 From: "Pomeroy, Marty" <address@hidden> To: "Mailing list for lwIP users" <address@hidden> Subject: Re: [lwip-users] TCP socket thread safety Message-ID: <address@hidden> Content-Type: text/plain; charset="us-ascii"
Late to the party, but full duplex is first an issue for your hardware and driver. If your hardware is set up to send and receive using DMA, data can be coming in at the same time it is going out. As long as you have enough receive buffers for the largest receive burst, and avoid promiscuous modes...
A single thread processing both directions has a disadvantage only in comparison to a multi-processor system, where you can farm the send and receive to separate cores in true parallel. That's really only needed on extremely high throughput applications, like a switch. On a single core, send and rcv will be ultimately sequential anyway, even if in different threads.
HTH!
Marty
-----Original Message----- From: address@hidden [mailto:address@hidden On Behalf Of Shaun Crampton Sent: Tuesday, February 12, 2013 12:03 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] TCP socket thread safety
Thanks for the quick response.
Duplex communication is pretty important for my application. Is there a way to do it with one of the other APIs (e.g. the raw API)?
------------------------------
_______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users
End of lwip-users Digest, Vol 114, Issue 22 *******************************************
[Prev in Thread]
Current Thread
[Next in Thread]
Re: [lwip-users] Problem with fragmented TCP packets using slow 3G,
address@hidden<=