-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ella Sent: Friday, November 15, 2013 12:25 AM To: [email protected] 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 _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
