tcp client connection running out of sock_writable(&socket) space

Question

Dynamic C 10.72, Rabbit BL4S160 1M

The Rabbit implements a TCP client and sends data packets every 200ms to a server.
This works fine for about 10-15 minutes.
During this time the sock_writable(&socket) function returns a value of about 4096 bytes (the value which is configured).

Then suddenly the value is reduced after each call to sock_fastwrite().
The current implementation is, that no more data are send if the available space is not sufficient.

But the available space after stopping to send data does NOT increase anymore.
The tcp_tick(with the used socket) function is called in the main loop.

Before the implementation was to use the sock_write function. But then the SW got blocked in the sock_write function and a virtual watchdog event occurred.

It seems that the send buffer is not cleaned up out of whatever reason?!

Your help is very much needed! and appreciated!

Answer 1

What is on the remote end, and can you monitor its receipt of data? When does the remote end stop receiving? Is the connection still open on the remote end? Is there a network problem forcing the Rabbit to buffer data until it's able to send? Is this over Ethernet or PPP? Does adding a sock_flush() call help?

Comments

One last thought, are you reading from that socket as well?  If the remote end is sending lots of data, it might be possible that received data is filling the socket buffers.  I thought the TCP/IP stack split the buffers between transmit and receive so one couldn't starve the other, but it would be good to investigate.

You could run a build in the debugger with TCP_VERBOSE defined in your project and see if it prints any debug information to indicate what's happening to your socket.

And you could stop the program and then check the fields of the tcp_Socket structure for anything unusual.

---

Thanks for your answer!
1. The remote end is a signal generator. and i have no equipment to monitor the communication between rabbit and the generator.
2. the generator is up and does not stop working.
3. it is a one way communication, rabbit to generator only.
4. communication via Ethernet (not PPP).

Basically the strange thing is that the communication fails after not a really determinable time. sometimes a few minutes or after half an hour.
and the number of packets send to the generator is always the same.

but now the problem seems(!) to be solved.

now the tcp_tick functions is called on every rabbit main loop with the socket. before tcp_tick(NULL) every 10ms.
 the rabbit has two Ethernet client connections, one to the generator one to a windows program with the function to log the rabbit activities.
 there seems to be a difference between tcp_tick(NULL) and tcp_tick(&socket) which is in my understanding not documented.

i replaced the generator with a Windows TCP/server simulating the generator and in a second try replaced the rabbit with a windows TCP/client program.
i monitored the data exchange with wireshark.
the generator does not respond (ACK) to each packet, only to very second packet.
but the Windows client program continued to work. no errors were reported.

running the rabbit against a windows tcp/server program worked as well.
the windows tcp/server responses to each packet with ACK.

at the moment i do not know
-if the problem is really solved or if it will happen after some hours.
-is the generator implementation to only answer to every second packet nominal?
 the windows client program does not have a problem with it.
 
thanks!

---

How are you declaring your socket variables?  They should be globals, or declared as "static" to whatever function creates them.

tcp_tick(NULL) should work the same as calling tcp_tick with the address of a socket.  Just make sure you're calling it in a context that has access to all of the sockets.  In a multitasking application, having a socket structure on one task's stack will cause problems.

It's possible you need to configure the Rabbit to run in half duplex if the generator doesn't support full duplex. You could use pd_networkmode() to force a network configuration to see if that helps with this issue.

I'm not sure why the generator behaves the way it does -- you'd have to contact that company about the issue.