This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

consecutive tcp messages

I am using Keil's RL-TCPnet for network communications.
The controller (STM32F107) is supposed to send up to 10 consecutive tcp messages every 10 ms.
I am calling timer_poll() and main_TcpNet every cycle (every 10 ms), system timer is 100 ms.
When I am sending consecutive messages, only the first one goes through.
I tried to insert

while (tcp_check_send(socket_tcp) != __TRUE) {;}

before each message. In this case the controller just hangs there.

What can I do to send all the messages in succession?
Any suggestions are highly appreciated.

Gennady

Parents
  • When you are calling tcp_get_socket, you do have the option to make a socket type TCP_TYPE_DELAY_ACK

    www.keil.com/.../rlarm_tcp_get_socket.htm

    This turns on delayed acknowledgment mode for this socket. A description of what this does is found here From: http://www.keil.com/forum/9213/

    "To improve the performance of HTTP server we split HTTP outgoing packets into 2 parts, one big and one very small packet with only a few bytes (because of a delayed ACK impact). It is thus normal if you see here and there a small TCP outgoing packet."

    So the 2nd small packet forces windows to send an ACK, which speeds up the transmit speed.

Reply
  • When you are calling tcp_get_socket, you do have the option to make a socket type TCP_TYPE_DELAY_ACK

    www.keil.com/.../rlarm_tcp_get_socket.htm

    This turns on delayed acknowledgment mode for this socket. A description of what this does is found here From: http://www.keil.com/forum/9213/

    "To improve the performance of HTTP server we split HTTP outgoing packets into 2 parts, one big and one very small packet with only a few bytes (because of a delayed ACK impact). It is thus normal if you see here and there a small TCP outgoing packet."

    So the 2nd small packet forces windows to send an ACK, which speeds up the transmit speed.

Children
  • The Delayed ACK that windows is using is based off of RFC 2581. Here is a good description of this RFC:

    "The delayed ACK algorithm is also a method for congestion control (RFC 2581), so the receiver won't flood the network with ACK packets. When the receiver has to sent an ACK in response to a packet, then it waits a little (200 ms or until it has 2 outstanding ACKs) to see if more packets should arrive that it can acknowledge with that single ACK."

    From smallvoid.com/.../winnt-nagle-algorithm.html

    So since we send 2 packets - one big, one small - this creates a 2 outstanding ACK scenario, and windows will respond to both packets.

    Since these devices will not be able to attain full 100 MB/s speeds anyways, the Delayed ACK does not help.