Date: Wed, 7 Mar 2001 14:13:50 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: Arjan.deVet@adv.iae.nl, net@freebsd.org, wietse@porcupine.org, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <200103072013.f27KDoS39501@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-net/20010307195557.A22189@adv.devet.org> References: <local.mail.freebsd-net/200102080524.VAA54629@curve.dellroad.org> <local.mail.freebsd-net/Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/20010307195557.A22189@adv.devet.org> you write: >In article ><Pine.NEB.3.96L.1010208114105.30518A-100000@fledge.watson.org> 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 certainly appears that BIND9 expects that. > >FYI, Postfix seems to have problems with the ECONNABORTED part of the >change, see the mail below from postfix-users. > >Arjan > >-- >Arjan de Vet, Eindhoven, The Netherlands <Arjan.deVet@adv.iae.nl> >URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl > >Subject: Re: errors from flush [again] >In-Reply-To: <20010306234957.EE524BC06D@spike.porcupine.org> "from >Wietse Venema at Mar 6, 2001 06:49:57 pm" >To: Wietse Venema <wietse@porcupine.org> >Date: Wed, 7 Mar 2001 10:26:22 -0500 (EST) >Cc: Arjan de Vet <list.postfix.users@adv.iae.nl>, postfix-users@postfix.org >Message-ID: <20010307152622.01B61BC070@spike.porcupine.org> >From: wietse@porcupine.org (Wietse Venema) > >Postfix 20010228 is OK on FreeBSD 4.2-RELEASE. > >I just checked that the system behaves sanely when Postfix does > > connect() > write() > close() > >before the server has accept()ed the connection. > >Reportedly, some later FreeBSD versions introduce a race condition >here. If the server accept()s the connection before the client >close()s it, then the server may receive the data. If the server >accept()s the connection after the client close()s it, the data is >lost. In both cases, the client is told that the data was transmitted >without error. Actually, this is incorrect. The server in both cases will correctly receive the data from the client; it does not matter if the client has (correctly) closed the socket before the server gets around to accepting it. This case only applies to when connection is reset after the initial handshake, but before the connection is accepted. All we are doing is returning an error immediately via accept(), instead of waiting for a subsequent operation on the socket to fail. There is no change to the read/write semantics here; the local TCP endpoint (and any buffers) have already been destroyed. I probably poorly worded the commit message; it should read "return ECONNABORTED if connection receives a RST while on the listen queue". Under normal operation, the client's connection isn't really closed until it receives a FIN/ACK from the server. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103072013.f27KDoS39501>