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

[goldsimon]

Am 31. Juli 2018 11:13:00 MESZ schrieb Mike Danby <address@hidden>:
>Hello,
>
>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 ?

Yes.

>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.

20 seconds is much too long. I'd expect to see some 100ms Delay. Could it be 
that your timers aren't running?

>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?

No. That doesn't necessarily work.

> 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.

If you really want them immediately, disable nagle. But that's not standard 
either. If, by "almost immediately", you mean some 100ms maximum, lwip does 
that normally. There must be something wrong in your setup.

>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

This is really much too old. No wonder you have problems ;-)

> and FreeRTOS 9 (both of these come
>packaged with the Xilinx SDK along with the drivers for the hardware).

Check the list archive: the drivers have/had bugs.

Simon