Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!pumpkin.pangea.ca!eru.mt.luth.se!www.nntp.primenet.com!nntp.primenet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.nacamar.de!news-xfer.cybernet.dk!news.onramp.net!newshost.cyberramp.net!news-in.iadfw.net!news.gymnet.com!LSNT1!lsbsdi6.lightspeed.net!news-ana-7.sprintlink.net!news-west.sprintlink.net!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news.maxwell.syr.edu!news.he.net!scanner.worldgate. com!not-for-mail From: Marc Slemko <marcs@znep.com> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Accept()-ing a connection from a specific IP address... Date: 28 May 1997 15:22:27 GMT Organization: WorldGate Inc. http://www.worldgate.com/ Lines: 31 Message-ID: <40189D40575A806A.5B2EA0FF2B113C3A.9AB59915BF5B80DA@library-proxy.airnews.net> X-Orig-Message-ID: <5mhijj$gmj$1@scanner.worldgate.com> References: <864144757.18711@dejanews.com> <EAHuuM.129@sphynx.fdn.fr> <5lvqjg$7rq$1@goof.germany.eu.net> <5m7np9$ain@uriah.heep.sax.de> <EAq6E3.EG@sphynx.fdn.fr> <5mbbbj$ngq@uriah.heep.sax.de> NNTP-Proxy-Relay: library.airnews.net NNTP-Posting-Host: biceps.gymnet.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:42124 In <5mbbbj$ngq@uriah.heep.sax.de> j@uriah.heep.sax.de (J Wunsch) writes: >causse@sphynx.fdn.fr (Philippe Causse) wrote: >> recvfrom() cannot be applied to an unbound TCP socket, therefore you need >> to accept() before... (see pgm example in previous posting). >Right, but confirmation of the connection is actually only achieved by >reading the first data portion. You can still reject the connection No. From userland perspective, the three-way handshake is atomic. There is no stage where userland code can sneak in and check anything after the SYN is received from the client, but before the ACK is sent to the client. To give a connection refused instead of just closing the connection once it was established, the check would have to be inserted at that place. ISTR that bit in the man page actually referring to some other prococol(s), which may or may not actually be implemented. >at this step. Except of the delay in the handling, this should be >indistingiushible from a server not running at all. > One can obtain user connection request data without confirming the con- > nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non- > zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, > one can provide user connection rejection information by issuing a > sendmsg(2) call with providing only the control information, or by call- > ing setsockopt(2).