Thanks for the detailed explanation, it clearly helped my
understanding of the whole thing.
I obviously already have a SIGPIPE handler, but the difficulty
comes from trying to figure out which call generated the signal.
As the code is meant to work on Linux and windows, and my understanding
is that the windows pthreads implementation doesn't do per thread
signals it becomes even more difficult to pinpoint the culprit.
Proper checking of all the return codes helps (and that's what I've
been doing anyway). I was trying to use a SIGPIPE as an indication of a
problem with the system tools interaction, but it is clear now that
it was a simplistic approach.
Thanks,
Alberto
On Mon, 2006-02-13 at 06:42 -0700, Kyle Hamilton wrote:
> SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named
> pipe) semantics onto TCP/IP connections. If the socket that you are
> writing to is a socket (or pipe), AND the pipe is closed, then you
> receive a SIGPIPE.
>
> In this case, the 'good reason' for it is that what you think is
> supposed to be listening isn't listening anymore, so you may need to
> update your internal state. However, since the other effect of
> writing to a socket that is remote-closed is the descriptor itself
> being closed, there's no reason to worry about it.
>
> I help maintain a MUD software (that uses OpenSSL); often players will
> disconnect by closing their clients instead of using the QUIT command,
> and this leads to attempts to send information to them. When the
> software receives the TCP RST ('connection reset by peer'), it also
> receives a SIGPIPE. However, we have no need to deal with it, since
> we check the return status of the write operation; if it fails, we
> close the socket and clean up the memory allocated to that connection.
>
> On 2/12/06, Alberto Alonso <[EMAIL PROTECTED]> wrote:
> > I personally don't know why pipes are even in use in the openssl
> > internals (though I bet there is a good reason for it :-)
>
> It's there because the underlying operating system forces them to be
> there. It's certainly not at the behest of the OpenSSL team.
>
> > Ignoring SIGPIPE (or most signals for that matter) is not really
> > that good. They get generated for good reasons.
>
> ...explained above...
>
> > In my case, depending on what came down the wire, I have to interact
> > with other utilities in the system, therefore opening pipes. I need
> > to make sure I get the signals when a system tool exits unexpectedly.
>
> Alright, then just check to see what descriptor actually caused the
> SIGPIPE (instead of setting it to SIG_IGN, you always have the ability
> to write your own handler). If it's a descriptor that connects to
> another utility, handle that special case (preferably by setting a
> global variable and exiting the signal handler quickly, before
> handling the exceptional circumstance in your main program loop --
> this is akin to a 'deferred procedure call' in Windows 2000+ device
> driver programming). If it's not, then it probably belongs to a
> TLS/SSL connection, and can be safely ignored (since you're supposed
> to be checking the return statuses of all of your OpenSSL calls
> anyway, and since you're trying to shut down the SSL socket, you might
> as well just call SSL_free() immediately after the SSL_shutdown
> [taking into account the possibility of an SSL_WANTS_WRITE return
> status].
>
> -Kyle H
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
--
Alberto Alonso Global Gate Systems LLC.
(512) 351-7233 http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
