Gayathri Sundar wrote:
Probably you can call the following
iRet = SSL_get_shutdown(pSSL);
if(iRet >= 0) SSL_shutdown(pSSL);
This is because, SSL_shutdown writes data on the wire,
i.e the closure alerts..and if a FIN was received meanwhile,
you will catch a SIGPIPE..this piece of code, actually
saves me from this..
Strictly speaking, it isn't that a FIN was received. Receipt of the FIN in and
of itself does not mean that the remote TCP endpoint is gone, nor that it is
unwilling to accept more data. All a FIN means in and of itself is that the
remote TCP and application will be sending no more data our way on the
connection. For example, when the remote simply calls shutdown(SHUT_WR).
Now, we also receive a FIN when the remote calls close(). In this sitation,
while it was unable to communicate that via TCP, the remote is not willing to
recieve any more data. The close() has implicitly stated such to the remote
TCP, so when the remote TCP recieves our data, it becomes
upset/worried/concernec/confused tosses its hands in the air and sends us a RST
segment. Receipt of that RST segment puts our end of the TCP connection into an
aborted state, and an attempt to write to the socket generates the SIGPIPE.
Generally, this will not be seen by us until our _second_ access of the socket -
first the write to trigger the RST from the remote, and then some other socket
call - typically another write IIRC, but I think it could be a recv.
SIGPIPE/EPIPE is our local TCP's way of telling us that we screwed-up in the
application-level handshaking between the ends.
A variation of the close() scenario is if the remote application is (bogusly
IMO) using an "abortive close" a la SO_LINGER. In that case they emit a RST and
go away. Either we receive that RST and go SIGPIPE/EPIPE on the next socket
call, or we don't see that RST (it is lost) and we follow a path much like the FIN.
The only way to be more or less sure we won't get an EPIPE/SIGPIPE is to preface
all our socket calls with something like select() or poll(), and even then there
is still a small window of a race condition, and of course the slight matter of
the select/poll overhead...
rick jones
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
