1) You should *never* handle any other pcb than your own! Don't iterate tcp_active_pcbs! 2) You disabled nagle for the first pcb on the list, not necessarily the one you want. Simon Gesendet: Mittwoc
The nagle algorithm can be disabled... Daniel --Original Message-- It worked but I noticed a relatively big latency (about 200ms or more) between arrival of buf_n and buf_n+1. Where does it come from
Hi Simon, That would be excellent - and exactly the feedback I would look for. As stated previously, my intention is for these to be "reference" implementations, which is why I am using both the raw
In fact, the lwipopts.h settings are the most interesting here. Would you mind sending your file (as attachment)? There are some things I don't (yet) understand in the traces (e.g. why does the clien
Hi Simon, et al, I have not got the Microblaze hardware out again, but I have tried the same code on an LPC1769 now, and get the same result. I had to change lwipopts.h slightly to reduce the RAM foo
Hi Simon, Yes - the windows simulator does not really tell me anything about the timing of the TCP/IP applications, so I didn't recognise there was a problem when using the simulator. I only recognis
Felipe de Andrade Neves L. wrote: May I ask something, how came the Nagle's algorithm has caused the problem, as it is suppose to group small data until receive the next ack, but the JPG has lots of
You are allowed to disable/enable the nagle algorithm where you like, but if you want to do so before sending the first segment, any place of these is equally good: - at initialization time (as you d
Richard, excellent information you've provided. May I ask something, how came the Nagle's algorithm has caused the problem, as it is suppose to group small data until receive the next ack, but the
This is a *very* bad example since you are accessing internals of the stack. Please use this code instead: tcp_nagle_enable(xNewConn->pcb.tcp); The tcp_nagle_*() functions were added in 1.4.0 only (I
I think there's a little confusion here. Simon said "The only thing changed by disabling nagle is that tcp_output always sends everything that is enqueued." but this isn't quite right. Disabling Nagl
Hi all, I have a problem that I have seen lots or users straggling with, but without any real solution. I am trying to send data in a loop. I have triad closing NAGLE as follows: // this should shut
Hi Tim, Have you tried disabling the Nagle algorithm? I had a similar issue as I am only sending small packets of data. Once I had disabled the Nagle algorithm responses to the client were much faste
Kieran, thanks for the reply I can't find TCP_SND_WND in lwipopts.h (see attachment) Nagle's algorithm shouldn't affect my application since I am always sending 1200 bytes data all the time. On Mon,
<SNIP> This all seems a little confused. You're trying to close a data PCB but then to re-open it you're creating a listening PCB. Do you not still have the bound listening PCB from when you first ac
I have some questions about using lwip but first some background. I am using a Stellaris 9b92 eval board and want to create two sockets (servers) to listen on two different ports and each port can se
Nagle's algorithm and the delayed ACK algorithm were both developed at around the same time, and interact badly. There are ways to work around this, but none of them are perfect. Kieran
Kieran, Thanks for the valuable informations! I ran my program and looked for the ACKs. I observed that in the correct part of my program (the HTTP server) all packages are alwayes acked, but when I
TCP won't free the segments until it has finished with them, which means waiting for an ACK from the other end. This could take some time. You should be able to disable Nagle's algorithm, and so avoi
Hi Stojan, No, I created my own HTTP handler code, but I have an example of one made by Luminary Micro. My version is much more simple. I just process the HTTP packeges in tcp_recv callback function.