Re: [lwip-users] Advanced lwip raw API questions

[Bill Auerbach]

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of ella
Sent: Friday, November 15, 2013 12:25 AM
To: address@hidden
Subject: [lwip-users] Advanced lwip raw API questions

Hi,
Before I dive in to source code and spend hours I decided to ask people here
a few questions:

1. After issuing tcp_output and getting ERR_OK in return am I guaranteed to
get ANY tcp_sent callback?
In what cases there will be no callback? What if disconnect happened or
there is no ACK from remote peer?
In my server implementation it's thread blocks waiting for sent callback and
I'm not sure if I'm not risking to get stuck where forever.

2. API says that after tcp_close I still can receive data on the
disconnected pcb. What does it mean? Should I expect to get tcp_recv
callback even after tcp_close? When can I free resources allocated for such
closed connection and be sure nothing will happen anymore with it?

3. tcp_recv callback gets err argument. What kind of error should I expect
where and how to deal with it?

4. Are tcp_* functions thread safe? I mean can I have server running in
separate thread and make calls to tcp_* functions from that thread and not
from callback running in native tcp thread?

Thanks.

Just a few fillings. I tried to implement own TCP server based on raw API
and actually got it working but it looks pretty complex as I'm trying to
take care of all possible cases. I found out that it is not trivial to sync
between callback and server thread. So I've started to look at netconn API
assuming that same job was done and was TESTED already. Especially
considering the fact that I will need a number of different servers in my
application to implement external interfaces. 

---------------------------------------------------------

Hi,

I will answer what I can based mostly on experience using lwIP, which goes
back now almost 10 years - all RAW API.

1.  tcp sent is called when there is buffer space, meaning when sent data
has been acked.  Unacked packets  and other issues (disconnects) would cause
tcp_sent to not be called.  I've never worried about it.  If tcp sent is
called, I check to see if I have more data to send.  If so, I do.  If not, I
set tcp_sent to NULL.  I reset it on the next send.  Pretty much just like
the raw http server demo.

2. Not totally sure except that I think you'll get more tcp received
callbacks if there is incoming data.  You know you won't receive more if tcp
received is called with a NULL pbuf or by a tcp error callback.

3.  I only use it if p is NULL and err is ERR_OK to indicate a closed
socket.  Again deriving this from an lwIP example.

4.  No.

One thing I've learned the hard way is that the tcp receive callback cannot
spend a lot of time or it disrupts tcp timing.  It will correct itself, but
when I saw errors in wireshark (e.g. retransmits) it pointed to something in
my system that was slower than normal that I did in the callback.

In order to not have nasty state-checking for all the possible callback
things I'd have to handle, I used tcp receive to create a pbuf chain which
would hold all of the incoming data.  When tcp received was called I called
back my application handler with how much data was in the chain.  If there
was enough to process the callback, I'd pull data off the of head to
process. Too often it happened that one callback would have my message
header and a second had the payload and it was hard to process that in 2
callbacks.

Bill