|Subject:||RE: [lwip-users] Communication delays, if using lwIP in different network areas|
|Date:||Thu, 11 Nov 2010 14:12:43 -0500|
TCP tries to optimize network throughput by placing outgoing data on a transmit queue, and sending when needed (or after a delay as you are seeing) . For some connections (for example command/response type connections like ModbusTCP) this is extremely inefficient because there is usually only one small block of data written per outgoing packet anyway.
To circumvent the delay you are seeing, your application should call tcp_output() after queuing data with tcp_write().
Hope this helps,
today our testers found out a massive problem, when they were putting a device with lwIP 1.3.2 or 1.4.0.rc1 (they tested both) in a different network, than the host PC.
The PC is in the network 10.x.x.x (IP assignment via a DHCP server)
The device is in the network 192.x.x.x (IP assignment via a DHCP server)
The network routes are fine, otherwise some services would not work in our company J
Device config: lwIP 1.3.2 or 1.4.0.rc1, RTOS, netconn-API and sockets
Pinging a device is not a problem at all. The response is sent in <1ms most of the times.
The problem arises, if I send tcp data from the PC to the device to a specific port, which is kept open as a response channel by the device.
The ACK to the received packets is sent immediately from the device, as I can see in the dump of the router or in wireshark. So it seems that there is no problem with the router in between the networks.
Then the device takes a timeout of 1-2.5 seconds, before sending the response package (wireshark and router logs proof that the packet is sent after that time and not earlier).
In between the PC retransmits the last package of the data and then the device starts to send its response…
For me it seems like the stack in the device doesn’t know, where to send the data to until the next packet arrives. Is that possible somehow?
Usually we put both the device and the PC in the same network area i.e. 10.x.x.x. If we do so the communication is smooth and everything works fine.
The above described data exchange takes approximately 250ms at most.
Does anybody have a clou, what the problem could be?
Is there any setting in the options, that can have an influence on this behavior?
Furthermore (and maybe not related to the above problem) is the fact that sometimes the device sends packets (which I don’t know the content yet) to address 0.0.0.0, if we have to transfer quite a lot data from the PC to the device.
And this occurs only, if PC and device are not in the same network area.
|[Prev in Thread]||Current Thread||[Next in Thread]|