LwIP tweaking the TCP stack behavior

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

LwIP tweaking the TCP stack behavior

lwip-users mailing list
Hello,

I have a small device that sends data over TCP at a fast rate, this is a
small and not very cable hardware.
Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets so
it could re-transmit if it has to.
In my implementation, there is no need to handle ACKs at all.
Obviously it could be argued why not use UDP or RAW socket?
Well I wish I could, but the other listening device is an old and slow
machine that knows only TCP and can't be changed.

Since I don't care about respecting re-transmissions, and loosing few
packets is not an issue,
I assume that removing the ACK handling logic from the TCP stack will create
a non standard TCP server,
but a very fast transmitter with low memory requirements and with very
little delay between each call to tcp_write(),
since packets will not have to be buffred until the other side acknowledge
them.

Can someone here guide me through this? or better, is there any magical flag
that does this?
Thank you
Eitan.






--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

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

Re: LwIP tweaking the TCP stack behavior

goldsimon@gmx.de


Am 20. Februar 2020 17:00:46 MEZ schrieb eitan via lwip-users <[hidden email]>:
>Hello,
>
>I have a small device that sends data over TCP at a fast rate, this is
>a
>small and not very cable hardware.
>Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets
>so
>it could re-transmit if it has to.
>In my implementation, there is no need to handle ACKs at all.

Short answer: disable the whole tcp code by setting LWIP_TCP to 0 and implement it yourself by using raw a pcb.

You won't easily do this by changing our tcp code.

And yes, I wouldn't do this at all ;-)

Regards,
Simon

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

Re: LwIP tweaking the TCP stack behavior

Patrick Klos-2
In reply to this post by lwip-users mailing list
On 2/20/2020 11:00 AM, eitan via lwip-users wrote:

> Hello,
>
> I have a small device that sends data over TCP at a fast rate, this is a
> small and not very cable hardware.
> Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets so
> it could re-transmit if it has to.
> In my implementation, there is no need to handle ACKs at all.
> Obviously it could be argued why not use UDP or RAW socket?
> Well I wish I could, but the other listening device is an old and slow
> machine that knows only TCP and can't be changed.
>
> Since I don't care about respecting re-transmissions, and loosing few
> packets is not an issue,
> I assume that removing the ACK handling logic from the TCP stack will create
> a non standard TCP server,
> but a very fast transmitter with low memory requirements and with very
> little delay between each call to tcp_write(),
> since packets will not have to be buffred until the other side acknowledge
> them.
>
> Can someone here guide me through this? or better, is there any magical flag
> that does this?
> Thank you
> Eitan.

I think you answered your own question.  You said "the other listening
device is an old and slow machine that knows only TCP and can't be
changed".  If you change the behavior of your LwIP TCP stack, the "other
listening device" will not understand your broken TCP implementation and
won't work properly with it.

Patrick Klos


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