zero-length message, sockets, and close()

[a...@kaiwan009.kaiwan.com]

Hi,
This is a real problem. I have to exchange data with a mainframe. That
mainframe has a nasty habit of sending zero-length messages which by UNIX
(socket) standards (customs) means - the peer closed connection.
How can I detect FIN packet using sockets. In other words, how can one tell the
difference between zero-length message and close() call. The only thing I can
think of is getsockopt, but I havn't tried it yet. The last resort (a nasty one)
is to send zero-length message back to the mainframe and check for erros,
but this would probably kill the mainframe.
I guess that TLI or XTI would be helpfull here, however that would be to much
work for me.

Thanks for reading,
Adam Skowronski

[sha...@dss1.austin.ibm.com]

Unfortunately, Send-Zero-Bytes is not supported in the socket interface and
you are right about XTI supporting it. You will need to make an additional
call if you expect to receive 0 bytes of data. The call could be
GetPeerName. But, I am not sure ( din't check the code!) if TCP queues
the zero length data and wakes up the receive thread/process.

Mohan Sharma

[Dan Lanciani]

There seems to be some confusion here. First of all, the socket interface
most certainly does support a send of zero bytes *assuming the underlying
protocol makes this meaningful*. An example of such a protocol is UDP.
UDP preserves message lengths and allows a length of zero. A send of
zero bytes will result in a receive of zero bytes at a peer.

TCP, on the other hand, is a byte stream protocol. It does not preserve
message lengths at all, let alone zero-length messages. A zero-length
send on a TCP stream is in theory a no-op. (In practice, it may cause
a particular implementation to run its output processing code and perhaps
retransmit a packet or the like.)

If the original poster is dealing with meaningful zero-length messages,
he is not using tcp/ip (though the mention of FIN suggests that he is).
Now, the socket interface does run into troubles when supporting a protocol
which includes both zero-length messages and an end-of-connection mechanism.
Although no such protocol is part of the standard internet set on most unix
machines, some vendor protocols do indeed present this problem. In these
cases, vendors usually provide a mechanism outside of the socket interface
to deal with the situation. One example is the sequenced packet protocol
of DEC's DECNET/Ultrix product. In the implementation I'm familiar with,
DEC chose to use a return of zero on receive to indicate a zero-length
message and to offer a separate function (dnet_eof()) to check for a
closed connection. You might want to check for a similar function in
whatever protocol is being used.

Dan Lanciani
ddl@harvard.*