On Fri, Mar 09, 2001 at 02:56:21PM +0900, [EMAIL PROTECTED] wrote:
>
> >From the server's point of view:
> >
> >+ TCP/IP handshake from client, allocate protocol control blocks
> >+ receive data from client
> >+ client resets connection, pcb is destroyed
> >
> >Exactly why the client
>From the server's point of view:
>
>+ TCP/IP handshake from client, allocate protocol control blocks
>+ receive data from client
>+ client resets connection, pcb is destroyed
>
>Exactly why the client resets the connection isn't my concern at
>the moment. Some stacks may place a t
On Thu, Mar 08, 2001 at 02:30:23PM -0800, Alfred Perlstein wrote:
> * Jonathan Lemon <[EMAIL PROTECTED]> [010308 14:19] wrote:
> > On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> > > Jonathan Lemon:
> > > > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> > > > > I
The graceful-close debate is a very old one, going back more than
twenty years. X.25 and ISO-TP have non-graceful close - the close
can pass data in the network and cause it to be lost. TCP is
defined as graceful-close. In SVR4 TLI there are two types of
stream "sockets" with graceful or ugly c
* Jonathan Lemon <[EMAIL PROTECTED]> [010308 14:19] wrote:
> On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> > 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(
On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> 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.
I would like to preempt corrections to the effect that it is currently
impossible for accept to return both an error code and a socket to read the data
from. It sounds like there may be a bug in the behavior of accept w.r.t Unix
Domain sockets. For TCP, if the client sends data, then closes with
> > 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
> connection termination involv
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(). The system is not suppos
On Thu, Mar 08, 2001 at 12:52:31PM +0900, [EMAIL PROTECTED] wrote:
>
> >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 cl
>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
In article [EMAIL PROTECTED]> you write:
>In article
><[EMAIL PROTECTED]> Robert
>Watson wrote:
>
>>It seems that the ECONNABORTED is the "standard" way to address this
>>scenario; it might be an interesting exercise for someone to look at the
>>common application suites and see how they respond t
In article
<[EMAIL PROTECTED]> Robert
Watson wrote:
>It seems that the ECONNABORTED is the "standard" way to address this
>scenario; it might be an interesting exercise for someone to look at the
>common application suites and see how they respond to various failure
>modes in accept(). It certai
>> 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 has this been the "current behavior" ?
>ISTR at one time you would instead get the actual sockaddr of th
On Mon, Feb 12, 2001 at 06:34:29PM -0800, Archie Cobbs wrote:
> 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
> struct sockaddr_in sin;
>
> len = sizeof(sin);
> fd = accept(s, (struct sockaddr *)&sin, &len);
> if (fd == -1)
> err(1, "accept");
> printf("peer address: %s\n", inet_ntoa(sin.sin_addr));
>
>The bug with this code is that it blindly uses ``sin'' after
On Mon, Feb 12, 2001 at 04:51:48PM -0800, Archie Cobbs wrote:
> 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
> >
>> No, as this is the current behavior. The change will be for accept
>> to return an error, on the basis that 1) most apps already do the
>> wrong thing now anyway, and 2) it brings us closer to a 'standard',
>> e.g.: what other systems are doing as well.
>
>I don't understand then.
>
>What is
On Mon, Feb 12, 2001 at 09:56:26AM -0800, Archie Cobbs wrote:
> 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
On Thu, Feb 08, 2001 at 10:12:43AM -0800, Archie Cobbs wrote:
> 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.
> >
In article
[EMAIL PROTECTED]>
you write:
>
>On Wed, 7 Feb 2001, Archie Cobbs wrote:
>
>> 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
On Wed, 7 Feb 2001, Archie Cobbs wrote:
> 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 t
>> 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 before I get it, why
> i believe you will want to merge this.
> scenario:
> - you are listening to tcp port
> - someone comes in, handshake (SYN, SYNACK, ACK)
> - someone sends RST
> - your server issues accept(2)
> previous behavior: accept(2) returns successful result with
>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 there are any objections.
it is because of cvs issue. the important portion is below.
itojun
@@ -320,11 +359,8 @@ soaccept(so, nam)
so->so_s
>>>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 there are any objections.
>> it is because of cvs issue. the important portion is below.
> oops, need some change in uipc_syscalls.c side... hol
Current updated patch for comments is below.
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.
--
Jonathan
Index: 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 there are any objections.
> it is because of cvs issue. the important portion is below.
oops, need some change in uipc_syscalls.c side... hold
>>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 there are any objections.
>
> it is because of cvs issue. the important portion is below.
Looks good to me as well.
-DG
David Greenman
Co-founder,
Won't comment on the implementation as I have't had a chance to review it
yet, but the description sounds right, and compatible with
http://www.opengroup.org/orc/DOCS/XNS/text/accept.htm
http://www.fifi.org/cgi-bin/man2html/usr/share/man/man2/accept.2.gz
There are some interesting comments
30 matches
Mail list logo
