lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] TCP Raw API questions about efficiency and threads


From: Noam Weissman
Subject: Re: [lwip-users] TCP Raw API questions about efficiency and threads
Date: Fri, 3 Jun 2016 07:21:51 +0000


Hi,


LwIP RAW API is simple once you understand it.


You do not create separate threads, all the connections are handled in one thread !


The way to have multiple connections is to add a user ARG value. Every connection has

its own PCB. Meaning for every connection the TCP stack will allocate a new PCB and when

it calls your accept cal-back you use this PCB to differentiate from other connections.


Also inside your accept call-back you can allocate your own structure and assign it to the

new connection. You assigns it to ARG !


Inside recv or any other call-back you simply read the ARG parameter and use it to differentiate

the connections.


You can either allocate your structure from the TCP memory or reallocate it statically and define

a maximum connection that you will be handling.


In order to use RAW API efficiently you can use the poll call back to send more data. What do I

mean by that ?


Lets assume you got some request for data and you are handling it inside the recv function.

If you send back all the data you are busy inside that recv instant and blocking other parallel

connections. One way to avoid this is to start sending (a portion) and get out of the recv. The rest of the send will be handled inside the poll function. the poll function is called periodically as long as the

current connection is a live... house keeping.


Once you no longer need that connection can gracefully close it from inside the poll function.


Another way to use the poll call back is to put some data in a queue (from main thread) while from

inside the poll call back (TCP own thread) read that data and send it to the open connection.


Regarding the ping... 200-300 ms is very slow even on the WAN. You are doing something wrong.


Check for the examples that are around and get some ideas how implement your code.


Hope that above helped.


BR,

Noam.








From: lwip-users <lwip-users-bounces+address@hidden> on behalf of Pîrvu Mihai <address@hidden>
Sent: Friday, June 3, 2016 12:15 AM
To: Mailing list for lwIP users
Subject: [lwip-users] TCP Raw API questions about efficiency and threads
 
Hello guys, I've just ported my application to tcp raw API and I was wondering a few things. 

I've noticed that the performance is a bit too bad (300-500 ms for pings, between local clients) and I was wondering if I'm doing some things wrong.

Firstly,  I'm doing all my packet processing + sending of replies in tcp_recv callback. Is this normal, or shall I save the data somehow and process it later. My idea is that this blocks the main thread and the next packets are delayed. But I don't know this for sure.

I don't understand how I can use multiple threads using this API. It's callback based, so where do I create the threads? Let's say I want to process the entire callback saved using tcp_recv on a separate thread. Is that possible or do I have to create a new thread inside the callback?

The application I'm using is a vpn server that has to inspect the packets (so I do that in tcp_recv), see where to forward one packet (from a list of connected clients to the server) and send that data to the client. I saw that each tcp_pcb has a unique memory address (obv.), so I save that in an array and if the client IP/MAC is the same as on in the array, I send my data to that pcb from the array. I can also send broadcasts (if mac is FF:FF:FF:FF:FF:FF). This is the "processing" that is done. 

One bad thing is that I copy the entire pbuf into a local buffer and free it (I saw that there's some idea to save it for later use, would love to see some examples on that).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]