We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
Are you talking to a windows machine? This could be the source of your issues.
TCP, unlike UDP, requires an ACK message to be sent back. Windows machines use a delayed ACK, which means for every other packet received, will the machine send back an ACK.
To bypass this issue, I recommend using TCP_Check_send:
www.keil.com/.../rlarm_tcp_check_send.htm
From the manual: "[tcp_check_send] does this by checking whether the TCP connection has been established and whether the socket has received an acknowledgment from the remote machine for the previously sent data"
yes, it's a windows machine. And I am using tcp_check_send. But it seems like to use it I need to do it this way:
while (tcp_check_send(socket_tcp) != __TRUE) { timer_poll(); main_TcpNet(); }
My system timer currently is at 100 mS, so it definitely is not going to send multiple messages every 10 mS. And when I get system timer down to 1 mS, the connection is not stable - controller disconnects. I have no idea why.
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.
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.