[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Socket API send command packaging up data

From: Mike Danby
Subject: [lwip-users] Socket API send command packaging up data
Date: Tue, 31 Jul 2018 09:13:00 +0000



Forgive my ignorance I am new to the TCP/IP stack scene. I am currently trying to get the LWIP stack up and running with FreeRTOS on a Microblaze based system. I have successfully started a TCP server and managed to connect a client. The test code I have hacked together simply writes a string containing an incremental count from the server to the client (15 bytes or so at 1Hz), which the client receives and then prints to the screen.


I am aware that the when sending data to LWIP it is under no obligation to put the data on the wire as soon as it receives it (I think that is part of the TCP protocol). It can wait a period of time to see if new data arrives so it can send it in more efficient manner. Are these statements correct ?


Using Wireshark, I am seeing the data packaged up into various size frames (maximum about 300 bytes). LWIP can do this for approximately 20 seconds, however, the client does not seem to be losing any data.


What are the parameters of the stack that govern this behaviour? Can LWIP be configured (lwipopts.h) to minimize this effect? Would this be in keeping the TCP protocol design principles?


I have read using the raw API tcp_output can be used to ‘flush’ the queued data. Is this recommended? I am trying to gauge whether the behaviour I am seeing is a problem or not. My previous experience with TCP (always at the application level) is that send data through the socket should produce frames almost immediately.


I have used the stats functionality and activated some of the debug in the TCP layers, they do not seem to be indicating there is an issue. I have checked that the timer is firing periodically at the correct tick rate and set the threads (TCP thread and the xemacif input thread) be the highest priority. There is one other thread in the test that is lower in priority and periodically outputs to the console, again 1Hz)


I am using LWIP version 1.4.1 and FreeRTOS 9 (both of these come packaged with the Xilinx SDK along with the drivers for the hardware).


A period of time into the test (after approximately after 300 messages) and begin to see re transmissions on Wireshark and the server starts to struggle sending data.


Any insight into any of the questions have posed would be appreciated.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]