tcp receive queue size at socket layer...

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

tcp receive queue size at socket layer...

Frédéric BERNON
Hi group,

In my device, I use lwip 1.1.1 (updated with last CVS release) with several sockets. One of them is a TCP socket sending large packets. This socket exchange datas with its peer, using a protocol like "server send a packet, client send a packet, server send a packet, etc...". The server (lwip) doesn't really need the client's packets. So I only do "n" recv()- in one time - after "n" send() - to reduce potential recv() delays. But it seems that I "block" the stack if "n" is too big : no ping answer, even other udp tasks don't reply to my requests, etc...

Can you confirm me that one socket which don't do any recv() - but packets are send to this socket - can "consume" all internals packets/memory/resources and so, can block other sockets (or do a deny of service like with ICMP)? If it's true (and with what I know about lwip, I'm sure at 90% it's true), is there any feature or patch (with socket layer) to give a limit to socket receive queue size (to drop input packets when this queue is "full")?

With Microsoft winsock, it's possible to give a limit to recv queue size with SO_RCVBUF option. Is anyone already implement something like that?

Thank you about your ideas...

And Happy Halloween !!!!
 
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: tcp receive queue size at socket layer...

Jonathan Larmour
Frédéric BERNON wrote:

> Hi group,
>
> In my device, I use lwip 1.1.1 (updated with last CVS release) with
> several sockets. One of them is a TCP socket sending large packets. This
> socket exchange datas with its peer, using a protocol like "server send
> a packet, client send a packet, server send a packet, etc...". The
> server (lwip) doesn't really need the client's packets. So I only do "n"
> recv()- in one time - after "n" send() - to reduce potential recv()
> delays. But it seems that I "block" the stack if "n" is too big : no
> ping answer, even other udp tasks don't reply to my requests, etc...
>
> Can you confirm me that one socket which don't do any recv() - but
> packets are send to this socket - can "consume" all internals
> packets/memory/resources and so, can block other sockets (or do a deny
> of service like with ICMP)?

All the resources (packet/memory) can be configured, so one solution is
just to increase them as needed, but ultimately there is a finite amount of
everything and you may be memory-constrained.

> If it's true (and with what I know about
> lwip, I'm sure at 90% it's true), is there any feature or patch (with
> socket layer) to give a limit to socket receive queue size (to drop
> input packets when this queue is "full")?

You could reduce TCP_WND. That sets the maximum amount of space advertised
to the remote end, per socket. Obviously that can affect performance, but
it's an obvious way to stop each one eating up too many resources.

> With Microsoft winsock, it's possible to give a limit to recv queue size
> with SO_RCVBUF option. Is anyone already implement something like that?

lwip doesn't implement that. I don't believe there's anything that
presently allows the queue size to be set dynamically at run-time for each
socket. It wouldn't be hard to add though, but probably isn't important
enough to take space in the standard stack distribution.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users