Re: [lwip-users] Handle received data only partial

[Simon Goldschmidt]

Michael Steinberg wrote:
> Oh, and wait for the update that fixes leaking tcp_ucbs on remote-close
> with this approach, hehe. Or did this land already?

Bug #51937 has been fixed in master, yes. This ans some other fixed bugs make 
me think of releasing a tiny-fix 2.0.3 version soon...


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

[Michael Steinberg]

Hello,

My proposal: Chain up the handed pbufs in the recv callback 
("push_back", instead of handling) to a private chain of pending 
data, and call tcp_recved with the amount of bytes you consume from this 
received-chain at your own discretion at some other point in time (and 
be sure to free the pbufs as you walk across pbuf-borders, ie 
"pop_front"). There are quite enough helper functions for handling the 
pbufs (and copy data across borders). Oh, and wait for the update that 
fixes leaking tcp_ucbs on remote-close with this approach, hehe. Or did 
this land already?


Michael


Am 13.09.2017 um 07:13 schrieb Simon Goldschmidt:

Paul Plankton wrote:

So when I do not want the window to be enlarged, I call this function not with 
the amount of data received but with a fixed value? E.g. with the window size 
like it is defined in lwipots.h?

I'm not sure I understand your question.

For a working TCP connection, you'll have to call 'tcp_recved()' eventually. 
The amount of bytes (coutn value) you pass to this function has to be the exact 
length of the received data or things will go wrong at some point.

Now you have the option to throttle the sender by only sending a full window of 
data until you are ready to process more data (in your application, the stack 
internals tell the remote host they have processed the data by sending an ACK, 
no a window update).

This is done by *not* calling 'tcp_recved()' directly from the recv callback 
but at a later point (watch out for threading issues here!).

However, you *always* must keep the byte count correct, you cannot just pass in 
any constant value!


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users



___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

[Simon Goldschmidt]

Paul Plankton wrote:
> So when I do not want the window to be enlarged, I call this function not 
> with the amount of data received but with a fixed value? E.g. with the window 
> size like it is defined in lwipots.h?

I'm not sure I understand your question.

For a working TCP connection, you'll have to call 'tcp_recved()' eventually. 
The amount of bytes (coutn value) you pass to this function has to be the exact 
length of the received data or things will go wrong at some point.

Now you have the option to throttle the sender by only sending a full window of 
data until you are ready to process more data (in your application, the stack 
internals tell the remote host they have processed the data by sending an ACK, 
no a window update).

This is done by *not* calling 'tcp_recved()' directly from the recv callback 
but at a later point (watch out for threading issues here!).

However, you *always* must keep the byte count correct, you cannot just pass in 
any constant value!


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

[Paul Plankton]

OK, I have read this manual but on a third party webpage, that's why I did
not really trusted the explanation :-o

So when I do not want the window to be enlarged, I call this function not
with the amount of data received but with a fixed value? E.g. with the
window size like it is defined in lwipots.h?

2017-09-12 11:31 GMT+02:00 Simon Goldschmidt :

> Paul Plankton wrote:
> > So what does tcp_recved() do?
>
> RTFM :-)
>
> From http://www.nongnu.org/lwip/2_0_x/group__tcp__raw.html#
> gabdac0856a52b5789dc897d4c7137ec44
> "This function should be called by the application when it has processed
> the data. The purpose is to advertise a larger window when the data has
> been processed."
>
> Cheers,
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

[Simon Goldschmidt]

Paul Plankton wrote:
> So what does tcp_recved() do?

RTFM :-)

>From 
>http://www.nongnu.org/lwip/2_0_x/group__tcp__raw.html#gabdac0856a52b5789dc897d4c7137ec44
"This function should be called by the application when it has processed the 
data. The purpose is to advertise a larger window when the data has been 
processed."

Cheers,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

[Paul Plankton]

Hm, OK, thanks for the feedback.

I thought tcp_recved() could be what I'm looking for but it seems not. Btw:
what is this function used for exactly? At the moment I always hand over
the total received data length but in parrallel also release the pBuf. So
what does tcp_recved() do?


2017-09-08 22:01 GMT+02:00 goldsi...@gmx.de :

> Paul Plankton wrote:
>
>> My problem: I'm running on an embedded system where I can't waste too
>> much time with handling network data.
>>
>
> This and the statement about handling "1460 bytes during one interrupt
> call" is somewhat disturbing. Are you sure you don't violate lwIP's
> threading requirements?
>
> Also, Embedded and "too much time" is not really good phrasing. Either you
> need realtime or you need TCP ;-)
>
> [..]
>> My question: is there a possibility to do one of both? If yes - how can
>> this be done?
>>
>
> No. The only thing I can think of is: don't use TCP if you want a
> message-oriented protocol. Use UDP instead! TCP is about data streams, not
> about telegrams.
>
> If you're stuck to TCP and still want it your way, you'll have to
> implement the buffering at your application layer. There's no code in the
> core stack that does this for you.
>
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Handle received data only partial

[goldsi...@gmx.de]

Paul Plankton wrote:
My problem: I'm running on an embedded system where I can't waste too 
much time with handling network data.


This and the statement about handling "1460 bytes during one interrupt 
call" is somewhat disturbing. Are you sure you don't violate lwIP's 
threading requirements?


Also, Embedded and "too much time" is not really good phrasing. Either 
you need realtime or you need TCP ;-)



[..]
My question: is there a possibility to do one of both? If yes - how 
can this be done?


No. The only thing I can think of is: don't use TCP if you want a 
message-oriented protocol. Use UDP instead! TCP is about data streams, 
not about telegrams.


If you're stuck to TCP and still want it your way, you'll have to 
implement the buffering at your application layer. There's no code in 
the core stack that does this for you.


Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] Handle received data only partial

[Paul Plankton]

Hello,

within my tcp_recv()-function the "struct pbuf" which hands over the
received data sometimes contains chained buffers pbuf->next where "next"
points to the next buffer of data.

My problem: I'm running on an embedded system where I can't waste too much
time with handling network data. So I would prefer to

a) get tcp_recv() called with only one pbuf-element in order to deal with
1460 bytes at max during one interrupt call

b) return from tcp_recv() without having fetched all data (means I handle
only one pbuf and get the remaining ones during next call of tcp_recv())

My question: is there a possibility to do one of both? If yes - how can
this be done?

Thanks!

Paul
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users