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 <[EMAIL PROTECTED]> Do: [email protected] 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. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
