Cross-posted to lwip-devel since it's relevant. A lot of people start with this, or use it as is, for a basic WEB server. I'm not complaining - it does work and shows the callback concept. This is a
of the file about every 200msec. 200msec rings a bell: this is the delay windows waits before sending a (delayed) ACK: normally, it prevents sending an ACK for every packet to keep the total packet c
Bill, I will try this in the accept call back and advise the results. The httpd.c module we are using is one that was supplied by Luminary Micro with their function library. It was modified from the
Rick, I did this in the accept callback. I haven’t seen an lwipopts method to do this. Which httpd server? The one in lwIP contrib/apps doesn’t have the tcp_output you mention. Bill. From
Bill, Thanks for the prompt response. That would make sense to me. Where/how would I include this in the code? Do you know if there is a way to change this in the lwipopt.h file? I do see that the ht
Actually I'm not sure what he's seeing - all he said so far is that his program is blocked when he sends data. I probably haven't been paying a huge amount of attention to other mails that have been
tcp_write is not the problem (it only enqueues the data for sending). You have to call tcp_output and that is also the point where it doesn't send any more. But since this is no error but intended be
Hi again I went back to my first method of answering telnet commands and disabled the Nagle algoritm and it worked as it did before. Many Thanks. What I said about the stack locking up I could not re
Hi Roland, So, perhaps it's something you could comment in bug #20531 to keep a trace of this issue? Hi Frédéric First of all... thank you for your help. I talked with a friend of mine about the pr
Hi Frédéric First of all... thank you for your help. I talked with a friend of mine about the problem of the send(), because he did some testing again. You were right (... sorry about the trouble I
To disable Nagle algorithm at socket layer, call: int iValue = 1; setsockopt( hSocket, IPPROTO_TCP, TCP_NODELAY, (char*)&iValue, sizeof(iValue)); On your socket == Frédéric BERNON HYMATOM SA Chef d
had exactly the same problem like In looking at implementing the Nagle algorithm suggestions, I see I’ve previously found the suggested improvement thread and was running the Nagle update, checking
Hi Mateusz , The way that the packets are being sent (1460 followed by 40) is because of an issue in tcp_enqueue that I noticed last November, unfortunately I haven't had time to submit what would be
This is a report of the issues I found in my very slow running ftp application. Thanks Kieran for all your help. Thanks Jim also for your reply. ( SYS_LIGHTWEIGHT_PROT was\is 1 ) 1. The window was be
Sorry to be piping into your exchange with Kieran, but the mention of the ISR brings up an issue that I have faced in the past. You should check your lwipopts.h and be sure that you have Anything els
Kieran, I am using tcpip_input to communicate with the stack via the ISR in case the assumption was that I was running the full stack in real time. Thanks again. Tom --Original Message-- From: addres
Thanks Kieran. I'll look around. The file is being written to compact flash so that slows down things on the receiver, but it is a bother that the ACK takes so long. I'm in an multithreaded environme
Great, thanks. First off, you seem to have a very slow node (216.101.63.81)! It takes it well over a second to respond to the SYN-ACK (packet 2) with an ACK (packet 3). This suggests either it's seri
Am 31. Juli 2018 14:34:14 MESZ schrieb "Sergio R. Caprile" <address@hidden>: I thought so, too, but if he is seeing 20 seconds delay, it's not Nagle but some bug. In fact, nagle should only hold off
I'll go over your lwipopts and see whether I missed something. In addition, I will attempt to useSO_SNDTIMEO and SO_RCVTIMEO instead of polling in parallel to write and read(I understand by the samp