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 t
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
Girish Venkatachalam wrote:
SIGPIPE is fatal if not handled or ignored and it can
come at any time during the TCP session. Which means
that none of the solutions suggested by others in the
list will work.
And it is wrong to rely on OpenSSL for solving a TCP
closure at the remote end which is e
SIGPIPE is fatal if not handled or ignored and it can
come at any time during the TCP session. Which means
that none of the solutions suggested by others in the
list will work.
And it is wrong to rely on OpenSSL for solving a TCP
closure at the remote end which is essentially a TCP
issue.
write
--- Kyle Hamilton <[EMAIL PROTECTED]> 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
None of the solutions suggested by others in the list
will protect you against a SIGPIPE for the simple
reason that it is a fatal signal if not handled or
ignored and it can come at any time during the TCP
session...
Ignoring SIGPIPE is one of the steps in writing a
server daemon and it is standar
None of the solutions suggested by others in the list
will protect you against a SIGPIPE for the simple
reason that it is a fatal signal if not handled or
ignored and it can come at any time during the TCP
session...
Ignoring SIGPIPE is one of the steps in writing a
server daemon and it is standar
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
:[EMAIL PROTECTED] Behalf Of Kyle Hamilton
Sent: Monday, February 13, 2006 11:15 AM
To: openssl-users@openssl.org
Subject: Re: SSL_shutdown and SIGPIPE
Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and
a global state would make it possible to determine what socket you
were wr
Hallo Alberto,
Alberto Alonso schrieb:
> 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 :-)
OpenSSL doesn't use pipes.
You get a SIGPIPE if you write to a socket for that
the other end is closed.
I prefer using send() with
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 :-)
Ignoring SIGPIPE (or most signals for that matter) is not really
that good. They get generated for good reasons.
In my case, depending on what came down the wire, I have to i
Excellent, I'll give this a try.
Thanks,
Alberto
On Mon, 2006-02-13 at 10:51 +0530, 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 a
Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and
a global state would make it possible to determine what socket you
were writing on (if you needed that).
-Kyle H
On 2/12/06, Gayathri Sundar <[EMAIL PROTECTED]> wrote:
> Probably you can call the following
>
> iRet = SSL_get_s
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..
Tha
The standard practice is that of ignoring SIGPIPE in
all TCP servers.
signal(SIGPIPE,SIG_IGN);
OpenSSL cannot help you here because the problem
occurs at a lower level(TCP).
I remember seeing this line in the ssh server source
code as well.
regards,
Girish
--- Alberto Alonso <[EMAIL PROTECT
15 matches
Mail list logo
