|
From: | Noam Weissman |
Subject: | Re: [lwip-users] TCP Raw API questions about efficiency and threads |
Date: | Tue, 7 Jun 2016 19:30:33 +0000 |
Hi,
What are you sending there ?
I think you should process all the data as it comes and not collect 3-4k and then process.
For example I have a TCP server (like Telnet but RAW TCP) I get a pBuf and process it. I copy
byte by byte to a temporary buffer until I find CR, line terminator. The data is then copied again
into a queue for later processing by the parser task.
RX function continues the copy of one by one until it finds another CR. If it does not it will exit the RX call-back and continue on next pBuf...
I have no problems there. I can run it all day.
Sure you can load your code here. You can also send it privately as an attachment.
If you prefer to send it directly to me use: address@hidden
BR, Noam. From: lwip-users <lwip-users-bounces+address@hidden> on behalf of Pîrvu Mihai <address@hidden>
Sent: Tuesday, June 7, 2016 8:26 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] TCP Raw API questions about efficiency and threads What you are describing is exactly what I did in my first implementation. Handle all the data in the pbuf in recv function and then call tcp_recved(pBuf->tot_len). By handle I mean copy the data, cycle through all the possible packets, and send
the data to the peers it is intended to.
> I meant that if you get a request (like in HTTP) and you need to send lots of data you start the send process it in the
recv and continue in the poll call-back, if needed.
This might be the part that I don't understand. When do I decide it's okay to stop the data transmission in recv callback, and save the rest of the packets for poll callback ? As far as I understand, if I stay too long in recv callback (tcp thread), I
block incoming packets and if I stay too long in poll callback (main thread) I block the poll for other active pcbs.
I don't see how either way I can achieve good performance. I have a similar netconn code on UDP and my ping is 4-5ms between clients. It's just netconn has some transparency to what happens behind the scenes (raw udp) and I'd rather not dig (yet) and ask
here.
I am aware of the contrib directory (only http-raw and smtp client are relevant tho). The more I read, the more I see that other programs don't copy the pbuf chains into a big continous char buffer (I memcpy all of them until I get to BUFSIZE or pbuf->tot_len)
and then process the data inside this buffer. The problem is that I can receive multiple client packets in different pbufs (I think). For example Client A send 3 ICMP requests to Client B and I receive them as
111 -> 112222 -> 23333 -> 333. (4 nodes in pbuf list containing 3 different client packets, am I wrong on this?). I have a little delimitator at the beginning of clients' packets (just the size of the packet, actually), so what I do, is that I loop my
contigous array, from packetSize to packetSize (based on those first 2 bytes at beginning of any packet), process it (see destination based on data link header) and send the packetSize bytes. Then go further in the buffer of packets (with an offset of packetSize)
and do the same thing.
Is it okay if I upload some parts of the code (~130 lines) and analyze on it ?
Mihai
On Tue, Jun 7, 2016 at 6:09 PM, Noam Weissman
<address@hidden> wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |