>> 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.
> Since you usually get clientfds in an accept() loop, close()ing the
> connection would be the natural way of doing things.

Except that that means the connection comes up, in the TCP sense, which
as I read it is what Matt was trying to avoid.

That is, as I see it the desire is for

	client				server
		---->   SYN   ---->
					userland code looks at the
					client address (and possibly
					other things, like a local
					database) and provokes either
					(a)
		<----   RST   <----
					or (b)
		<---- SYN/ACK <----

In case (b), the client presumably responds with an ACK to complete the
connection handshake, though of course that is beyond the server's
control.

> If you want to NAK the connection from the beginning, you should do
> it in the firewall.

Firewall?  What firewall?

Why should I have to set up a firewall to get this behaviour?

This is especially awkward when the server's accept/reject decision
depends on things which change dynamically; arranging to poke firewall
rules whenever such things change is messy, fragile, and ought to be
totally unnecessary.

> However, this is unnatural behavior, normally you just RST a
> connection, which can be done by close().

It can?  When I do that, I see a FIN segment, not an RST.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B