The sockets API on a TCP socket simply won't let you do what you want  
(I read the rest of the thread, but I'm responding to the first  
message).

STREAMS and he XTI interface did have a concept of this -- you could  
get called back when the TCP SYN arrive.  You had the option of  
"accepting" the connection (which would reply with another TCP SYN)  
or rejecting it (sending a TCP RST).

With sockets, the only option in userland is "accept", which replies  
with the TCP SYN before you even get a chance, and the only thing you  
can do is look at the client's address and shutdown/close the socket  
(both basically do the same thing -- shutdown can let you send a TCP  
FIN while reading any outstanding data, while close will also send a  
TCP FIN and if there's any data, it will also RST the connection).

If you can find certain editions of the Stevens book "UNIX Network  
Programming", it will talk about this key difference.  The  
OpenTransport APIs on old Mac OS (which were STREAMS-based) had  
support for it.  I've long been surprised that the "accept" didn't  
evolve to solve this problem.

Rob



On Jul 12, 2005, at 3:16 PM, Matthew Mondor wrote:

> It would be most useful for some of my applications to be able to know
> the IP address of a client before calling accept(2), and to be able to
> cancel that connection event without needing to accept(2) and close(2)
> it.
>
> I noticed that this feature is usually implemented differently on
> various unix operating systems.  I verified if getsockopt(2) supported
> an SO_GETADDR but it doesn't.  I am wondering if MSG_PEEK, or  
> SCM_CREDS,
> could provide a way to do this through ancillary data with recvmsg 
> (2)?  I
> haven't looked at the code yet, thought I would ask first if anyone
> knows...
>
> Also, if MSG_PEEK worked, how would I unqueue the event instead of
> calling accept(2) if needed?
>
> Thanks,
> Matt
>
> -- 
> Note: Please only reply on the list since other mail is blocked by  
> default.
> Private messages from your address can be allowed by first asking,  
> however.
>