Re: [lwip-users] Re: Sending too slow.

[Mateusz Plocinski]

Well, it looks like TCP_NODELAY is used only in functions
setsockapt
getsockapt
They are probably available for user as TCP_NODELAY is described in tcp.h:
/*
 * User-settable options (used with setsockopt).
 */

But these functions arent described in lwip.pdf and they arent used in code (or 
maybe I cant find where). They could probably be used with BSD socket library 
but I dont use it (I use only Network connection functions from 16th part of 
documentation).
It looks like I should use getsockapt to set flag TF_NODELAY for the socket 
(first I have to use BSD style sockets).
Please correct me if I'm wrong.
Also, did anybody tried to use lwIP for similiar purposes like me, eg. sending 
much data over ethernet without waiting for ACK? I still dont know if my 
problem is because lwip doesnt allow that without some changes in code or is 
this only the problem of my port?
I use lwip-1.1.0 with freertos on Atmel ARM at91SAM7X256.
It looks like lwip has the needed mechanisms to do that but why it doesnt?
Someone has written in older topic that this problem is connected with lack of 
free memory. I can imagine the following situation: lwIP doesnt send next 
packet because it dont have free memory and it has to wait for ACK for last 
packet to free its memory and then load a new packet into buffer.
At this state of knowledge I'm not able to check it, but I'll keep lerning lwip 
code and trying.

Mateusz Plocinski
---- Wiadomość Oryginalna ----
Od: Kelvin Lawson <address@hidden>
Do: address@hidden
Data: Tue, 12 Sep 2006 16:28:33 +0100
Temat: [lwip-users] Re: Sending too slow.

> Hi Mateusz,
> 
> Have you tried setting TCP_NODELAY?
> 
> According to do_write() in api_msg.c:
> 
>        /* This is the Nagle algorithm: inhibit the sending of new TCP
>     segments when new outgoing data arrives from the user if any
>     previously transmitted data on the connection remains
>     unacknowledged. */
>     if(err == ERR_OK && (msg->conn->pcb.tcp->unacked == NULL || 
> (msg->conn->pcb.tcp->flags & TF_NODELAY)) ) {
>    tcp_output(msg->conn->pcb.tcp);
>        }
> 
> I'm not sure that this is correct - it seems to be doing only part of 
> the Nagle algorithm. As I understand it, it should buffer up any 
> outgoing data until all outstanding data is acked, but also permit a 
> send when a full packets' worth of data is ready to send. Judging from 
> the statement above, we do wait for outstanding data to be acked, but 
> don't permit a send when a full packet's worth is ready.
> 
> Kelvin.