lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] proper pbuf usage for TCP -> real-time in raw API NO_SYS=1


From: Sergio R. Caprile
Subject: [lwip-users] proper pbuf usage for TCP -> real-time in raw API NO_SYS=1
Date: Sun, 23 Mar 2014 11:49:34 -0300
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Hi,
let's have this scenario:

Data received from TCP is going to some real-time usage, let's say we
are writing to an SD card or something like that. The point is that when
data comes from TCP, the application might not be ready to use it for
some (hundreds of) milliseconds.

LWIP_ASSERT( please check my assumptions are true);
The application might already have an outstanding pbuf, so the receiving
function pbuf_cat()s the new pbuf.
When the application is finished handling prior data, it will tell the
receiver the amount of data freed, so it can tcp_recved() that amount of
data (in the long run, the TCP window will somehow adjust the throughput).

Then, at some point, the amount of data used will cross a pbuf boundary,
so it should be freed. Furthermore, as I (think I) understand, pbufs
could be chained, and the two pbufs I mention are in fact chains of
pbufs (a full Ethernet frame coming into a PBUF_POOL ?)

1) I wonder if there is a proper "standard" way of handling this
situation, an example application, or whatever.
2) I thought of using pbuf_header(), but I noticed it only adjusts
->tot_len for the first pbuf in the chain; so I guess I'll have to
manually move pbuf by pbuf, comparing to their ->len, freeing them one
by one, and then adjusting with pbuf_header() for the last in chain ?
2.a) If so, then, could we add this function to pbuf.c ?

Clue:
(1) Please, don't point me straight through to the POST code in
httpserver_raw, cause I see it does (2) to remove the header, but I
don't see it doing any pbuf_free later on for the rest of the content
(except probably for the last one, didn't check too hard)

Best regards.

-- 




reply via email to

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