Simple TCP Messaging (STM)

[smithd]

That VI is, I believe, correct. Those specific errors indicate that the connection itself was closed, while error 56 means the operation timed out. That is, error 56's meaning will depend on your application not on the API. For example if you're expecting a heartbeat every 100 ms and you don't recieve any message for a full 5 seconds, then yes error 56 means something bad happened. But if messages can come at any time then error 56 doesn't really mean anything and should be ignored.

[ryank]

Also, closing a connection on timeout is dangeous in some cases.  When using a static server port if you close the server port the server's socket will be placed in TIME_WAIT locking out your static port for ~60 seconds.  The other errors in that list imply that the connection is already dead (i.e. the other end of the connection closed it or something went horribly awry) and therefore there is no harm in closing the connection and trying to reconnect.

[Scott_Campbell]

OK so what is recommended action? what currently happens is the error then we loose communications and it will not reconnect.  communication slows down to host that did not timeout.  trapping the error and closing the connection allows it to be reconnected. 

[Scott_Campbell]

Actually I believe the TCPIP Connection is not closed, just the connection refnum is removed from connections.

[Scott_Campbell]

The reallity is that the timeout actuall indicates we lost the connection (WIFI) Ref number storred is not valid and will not reconnect so things did go horribly wrong

[ryank]

In general the suggested behavior on a timeout is to retry and wait longer.  A timeout indicates that the other side of the connection simply hasn't sent anything.  If you were expecting something in that time it means one of three things:

A.  The packet is delayed.  This is certainly possible depending on your network topology, and waiting longer could allow it to be delivered.

B.  The two applications have gotten out of sync and the other end doesn't think it should be sending something.  This is usually an application level bug.

C.  The connection has terminated ungracefully but the network stack has not realized it.  Depending on the OS and some network configuration settings, it's possible that given sufficient time, the stack may realize that the connection is gone and throw a different error (most likely forcing you into TIME_WAIT anyhow). 

However, like smithd said, closing on timeout is fine to do at an application level if you are comfortable with the socket behavior (for example, if you are closing from the client side or not using a static server port), but it would be a bad idea to modify the general library in that way.  One thing to watch out for - if you are using dynamic ports (for example connecting to a service name instead of a port number), leaving sockets in TIME_WAIT can still be dangerous.  Most operating systems have a limited number of sockets they will allocate and therefore your application might fail in stress testing if you rapidly cycle through sockets by closing and re-opening them.  That's mostly a corner case unless you are using really short timeout values though.

[rolfk]

I agree that a timeout error is not generally an error indication other than that the message may be delayed. On application level this can be different for heart beat messages you know should arrive at a certain interval but a timeout error is not generally indicating an error. Of course treating it as such will make the connection more reliable but also a lot slower as you will have regular reconnects that take time.

I'm not sure what is meant with a static server port however. Generally a TCP/IP connection is characterized by the IP address and port on both sides. TCP/IP itself does allow for multiple connections if at least one of these 4 elements (local address and port and remote address and port) is different. Generally the client will use whatever port the OS finds available for use so it should be no problem to try to reconnect to the server even if the previous connection is still in TIME_WAIT state. Of course the server has to support multiple concurrent connections for this to work, otherwise the time until the server recognizes that the previous connection has been closed by the peer, will limit the reconnection interval.

Of course if there are many reconnects from a client the client may eventually run out of available random port numbers if the TIME_WAIT state is configured very long and the reconnect is done very frequently.

[Scott_Campbell]

what I suggest you try is what we went through, setup two connections, pull the network connector on one.  you will see a timeout error before anything else.  this is the issue  the connection ref number does not get closed  client keeps attempting to read ---bogs down the communications.  re connect the network does not cause the connection to be re established.  you have to restart the  client to recover. 

closeing the reference on timeout error allows the connection to be restored and you have recoverd.

If there is some other way to handle this better I am all ears.

[Scott_Campbell]

we are using STM 1.0.32 and have run into an issue with Multiple client implimentation in LV2013.  server works well with one client which only sends data to server.  but when a second client connects (only reading )  the loop on the server seems to slows down.  watching timestamps on probe, it looks like 25 seconds per received message.  when second client is stopped the loop slowly recovers as all the messages get received. data being written on server seems to continue as normal.

Implimentation is as close to stock STM multi Client example (stm 1.0.32)

I actually deployed the RT Server and get the same results as running it 'interactive or debut' 

another group hear ran into the same issue and solved it byt clustering everthing into one big cluster which to me is not a good solution.

[Christian_L]

I tried the stock Multi-Client Server example included in 1.0.32 and it seems to work fine.

Can you share a copy of your code or screenshot of the code that is exhibitng this behavior? The 25 second delay leads me to look at the timeout (default 25 seconds) of the STM Read Msg VI. In the multi-client example this timeout is set to 0 so that the server cycles through all the connections quickly and does not wait for a message from any one client.