TCP/IP Device Socket State CANTRECVMORE

[Mario Abruzzi]

In TCP/IP Service for OpenVMS V5.6 - ECO 4, what is the significance of the BG device socket State CANTRECVMORE?

[Hoff · Accepted solution]

Usually indicates a socket that's canceling or disconnecting and that's flushing its read buffers and is very nearly ready to be closed, or (rarely) a protocol attack. CANTSNDMORE is the write analog. A classic OpenVMS sys$cancel call is close to CANTRCVMORE and CANTSNDMORE; canceling both the read and write activity. Can also potentially indicate an application bug, though there are some software widgets that can and occasionally do seem to keep devices in this state. And what might initially be confusing, it's quite possible for sockets to exist without BG devices around; without a host channel.

[Mario Abruzzi]

And where might one find this information documented?

[Richard Whalen]

The socket flag CANTRECVMORE is set after receiving a packet with the FIN flag set from the remote side and the local side has not yet sent a FIN. Since the remote side has indicated that it is done sending data, no more data is expected on the local side.

[Hoff]

>And where might one find this information documented?

Check the Internet Protocol books and documents, and check the various open-source implementations s. HP mentions it once or twice in their manuals, but (as you've likely already found) with few details. The underlying knob involved here is part of the typical IP state machine, and not specific to an OS platform.

[Richard W Hunt]

I recently filed a ticket that danced all around this status bit. Here's some extra thoughts from a different perspective.

The CANTRECVMOR and CANTSNDMORE flags can also tell you, not that the session is closing a connection, but that the socket on the other end of the connection has ALREADY vanished. E.g. when some user with a dumb-terminal emulator on his PC shuts down his machine without logging out of VMS first.

See, for example, the release notes associated with patch VMS83A_DCL-V0300, which describes a problem and fix for the case where a TELNET connection leads to a runaway problem of some type based on an attempt to send a "disconnect" command down the pipe only to have the I/O fail with an error that the connection handler wasn't expecting. So it tries again and fails again. Tries again and fails again. Silly machine, "thinking" that if you do something often enough it will eventually work...

For me, the problem was manifested in the TCPIP$SSH intermediary process that sat between the NET driver and the user process coming in through an FTA (pseudo-) device. The process in question was the one that performs encryption and decryption as is associated with SSH traffic.

In my case, when something happened to "whack" the end-user job abruptly, the intermediate job went into a compute-bound loop for which for buffered I/O counts sky-rocketed. I have already forwarded these details to HP associated with my previously opened ticket.

I wonder if this problem would also occur on virtual terminals that use BG as an intermediate to keep the channel open for the case when someone improperly closes the channel one-sidedly.