[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Writing a proxy server - how "non-reentrant" is lwip ra
Re: [lwip-users] Writing a proxy server - how "non-reentrant" is lwip raw API?
Sat, 25 Jun 2011 11:58:55 +0200
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:184.108.40.206) Gecko/20110414 Thunderbird/3.1.10
A followup to this discussion; after further debugging I did find
the cause of my "flaky behavior" and it was because the call to
tcp_write above needs to have TCP_WRITE_FLAG_COPY set.
I was optimistically hoping that since I called tcp_write and
tcp_output() from my receive callback, that the transmit side
would have what it needed by the time my receive callback exited.
However, that doesn't appear to be the case; my packets were definitely
coming out with some bytes overwritten until I added that flag.
The reason for this is that without the copy flag, you tell TCP to
enqueue the data from original input pbufs for sending. This *can* work
only if you postpone freeing the original pbuf (the one passed to your
recv callback) until the copy you sent is ACKed. This would mean you
have to hold a pointer to the original pbuf on a list and then free it
in your sent-callback according to the number of bytes passed in to that
However, while the no-copy version saves some memcpy() calls, it bears
the risk of running out of PBUF_POOL pbufs: These are normally only used
for RX packets - you would now use them for TX, too. Since they then
stay allocated until the remote side ACKs them, you need more POOL pbufs
than you would need when copying data (where data is copied to PBUF_RAM
pbufs allocated on the mem-heap).