Date: Fri, 21 Feb 1997 07:46:13 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: gurney_j@resnet.uoregon.edu Cc: davidn@labs.usn.blaze.net.au, avalon@coombs.anu.edu.au, freebsd-hackers@freebsd.org Subject: Re: "connection refused" Message-ID: <199702202046.MAA07140@freefall.freebsd.org> In-Reply-To: <Pine.BSF.3.95q.970220114101.348E-100000@hydrogen.nike.efn.org> from "John-Mark Gurney" at Feb 20, 97 12:02:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from John-Mark Gurney, sie said: > > On Fri, 21 Feb 1997, David Nugent wrote: > > > Hmm. Then I'll need multiple sockets, since there may be more > > than one remote host. I guess that is feasible given that it > > only moves the placement of fork(). But it also means leaving > > around more processes just for enquiry. > > > > > What does it say before that ? A connection is ESTABLISHED before it > > > comes back via accept(). > > > > Ok. Then recvmsg() should be used without (instead of) accept()? > > it seems that accept() does do what you want..... directly from the > accept() man page: > For certain protocols which require an explicit confirmation, such as ISO > or DATAKIT, accept() can be thought of as merely dequeueing the next con- > nection request and not implying confirmation. Confirmation can be im- > plied by a normal read or write on the new file descriptor, and rejection > can be implied by closing the new socket. > > it seems you can accept() a conntection... verify were it is coming from > and then close and it will be rejected... as it turns out this isn't > true... (I just wrote a test program to test it)... What about if the socket accept() is using is non-blocking ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702202046.MAA07140>