Jonathan Graehl:
> > > Data CAN be lost if the TCP connection is RST. It has nothing to
> > > do with the ordering of accept() with respect to close().
> >
> > Please educate me: how would RST come into this discussion at all?
> > The client does connect() write() close(), there is no forced
> >
Jonathan Lemon:
> On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> > If the result of connect() write() close() depends on whether
> > accept() happens after or before close(), then the behavior is
> > broken. The client has received a successful return from write()
> > and close()
If the result of connect() write() close() depends on whether
accept() happens after or before close(), then the behavior is
broken. The client has received a successful return from write()
and close(). The system is not supposed to lose the data, period.
This race condition did not exist with UN
Several parts of Postfix do: connect() write() close(), where the
close() may happen before the server has accept()ed the connection.
Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
accept() after close() to fail. The already written data is lost.
This is a bad incompatible chan
Garrett Wollman writes:
> > ISTR at one time you would instead get the actual sockaddr of the
> > just-closed socket, rather than a bogus sockaddr... and that is the
> > behavior one would expect.
>
> As itojun pointed out, accept() used to just block if the socket it
> thought it was going to gi
< said:
> ISTR at one time you would instead get the actual sockaddr of the
> just-closed socket, rather than a bogus sockaddr... and that is the
> behavior one would expect.
As itojun pointed out, accept() used to just block if the socket it
thought it was going to give you turned out not to be
Jonathan Lemon writes:
> It seems to me that the odds of an application being able to correctly
> handle an error return from accept() are far greater than the odds that
> the code correctly checks 'len' upon return from accept. This, combined
> with the standard, seems to be rationale enough to
[EMAIL PROTECTED] writes:
> >And what do you mean by ``most apps already do the wrong thing now''?
>
> for background (like when this happens) see previous articles
> on this thread.
>
> current behavior: return 0-length sockaddr.
Yeah, that is totally broken.
Hmm.. how long
Jonathan Lemon writes:
> > > Did you guys agree on a commit-worthy fix yet?
> >
> > I wasn't party to the issue that generated this thread in the first
> > place, but.. I think the concensus is that if accept(2) returns
> > an error then this will break some applications, so instead it
> > shoul
Kris Kennaway writes:
> Did you guys agree on a commit-worthy fix yet?
I wasn't party to the issue that generated this thread in the first
place, but.. I think the concensus is that if accept(2) returns
an error then this will break some applications, so instead it
should return a socket which w
Did you guys agree on a commit-worthy fix yet?
Kris
PGP signature
Jonathan Lemon writes:
> >> Jayanth did make one point that an application could assume that
> >> the error return from accept was in regards to the listening socket
> >> instead of the new socket, so that may be a concern.
> >
> >Yes I have always assumed this to be true. If the connection is
>
Robert Watson writes:
> > Jonathan Lemon writes:
> > > Jayanth did make one point that an application could assume that
> > > the error return from accept was in regards to the listening socket
> > > instead of the new socket, so that may be a concern.
> >
> > Yes I have always assumed this to b
In article [EMAIL PROTECTED]> you write:
>Jonathan Lemon writes:
>> Jayanth did make one point that an application could assume that
>> the error return from accept was in regards to the listening socket
>> instead of the new socket, so that may be a concern.
>
>Yes I have always assumed this to
Jonathan Lemon writes:
> Jayanth did make one point that an application could assume that
> the error return from accept was in regards to the listening socket
> instead of the new socket, so that may be a concern.
Yes I have always assumed this to be true. If the connection is
already broken be
In article [EMAIL PROTECTED]> you write:
>-=-=-=-=-=-
>
>Can anyone comment on this patch?
>
>http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
Looks good to me (although the patch is mixed in with a bunch
of other crud). I've tested it out locally and will commit it
unless
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
< said:
> Can anyone comment on this patch?
> http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
I don't necessarily agree that the previous behavior was wrong, but
I'm willing to bet that a lot of programs don't bother to chec
Can anyone comment on this patch?
http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
Kris
- Forwarded message from [EMAIL PROTECTED] -
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: accept(2) behavior with tcp RST rig
18 matches
Mail list logo
