TCP channel, is it alive?

[bteixeira]

At one of our clients, we're trying to communicate with a device via TCP but the connection isn't great.  We're having difficulty telling if the device is still working on the command and hasn't replied yet or if the connection has dropped.  The basic code looks like:

write record(tcp_chan)"command goes here"
while 1
read record(tcp_chan,tim=5)resp_segment$
let response$+=resp_segment$
if pos(end_of_message$=response$) then goto *break
wend

If the connection has dropped we want to know as soon as possible and then we can try re-opening the channel, request the last command, prompt the user to reset the device etc.  Without a tim= branch we can sit there way too long.  However the device may legitimately take a long time to process the command, especially if human interaction is involved it could take well over a minute.

Is there a way to determine if the connection has dropped or if the device is just taking a long time to process?

[Mike King]

The only way you can know if a TCP connection has dropped is basically by sending something to it and waiting for the packet acknowledgement.  This is effectively what KEEP-ALIVE does however the KEEP-ALIVE timeout is generally over 1 minute, so likely not suitable for this situation.

Using a TIM= is about the best I can suggest.  Perhaps with a longer timeout on the first character.

[bteixeira]

Mike,
     I tried opening the channel and then forcing a disconnect and doing a write record.  PxPlus neither threw an error nor waited, I think it just went into some sort of system buffer.  I re-established the connection and the device picked up the command.  Is there anything on the write I could do to not buffer but instead throw an error if the connection is down?  That could work for us in this scenario.

The only way you can know if a TCP connection has dropped is basically by sending something to it and waiting for the packet acknowledgement.  This is effectively what KEEP-ALIVE does however the KEEP-ALIVE timeout is generally over 1 minute, so likely not suitable for this situation.

Using a TIM= is about the best I can suggest.  Perhaps with a longer timeout on the first character.

[Mike King]

By definition, TCP does not have any way to immediately determine if the connection is active other than sending a message and awaiting a response.

Unlike old-style communication IO, there is no hardware status regarding the presence of a device.
The following is a basic description of how TCP works

When you issue a WRITE (or TCP send) request, the data is placed in one or more packets which identifies the targeted system by its address.  The packets include a sessions identifier and sequence number.

The TCP software itself then takes the packet and forwards it throughout the network through various servers and routers until it reaches the destination.  When received at the designated end-point, the end point sends back an acknowledgement that it has received the packet. 

In order to improve performance on TCP, the protocol allows multiple packets to be sent prior getting an acknowledgement of receipt.  These packets, due to the nature of the network, may be received out or order by the end-point.  The end-point is responsible to re-order the packets into the proper sequence and passing the data, in proper sequence, to the application. 

The endpoint acknowledgement actually can indicate the highest successful receipt thereby eliminating the need for each packet to be acknowledged.

The sender keeps track of what packets have been sent/acknowledged and will retry the transmission of any packets for a while, but should a packet hang around without acknowledgement too long the system will then report a transmission error. 

Now from an application perspective, that error will generally occur at some point after the initial WRITE (send) has been done, in effect an error actually indicates that the connection has failed sometime earlier and not on the actual READ/WRITE (recv/send) that reports the error.

A CLOSE of the connection will forward a close packet and will normally wait for the all pending acknowledgements to be received.  Applications can ask to wait until the closure process  fully completes with all acknowledgements or, more commonly, the wait is done in the background by the network software.

To help make sure connections are alive when there is no traffic between the systems, TCP does offer a KEEP-ALIVE option whereby the server sends dummy messages to the client which allows for verification of the connection, so the next WRITE/READ can be advised immediately that the connection has failed, but the keep allive messages are only sent every minute of so.

So to answer your question, there is no way to assure that a TCP connected device is present other than to wait for it to respond.

[bteixeira]

We'll try the keep alive option.  A one minute response is better than what we're currently seeing without a tim= branch of 10+ minutes (possible indefinite) while waiting on a read