4.2bsd IPC interface

[Matt Crawford]

From: lerner at isi-vaxa.ARPA (Mitchell Lerner) 
> being able to examine the address of the client so that a server might
> be able to refuse a connection apriori, without the client receiving a
> "connection accepted" ack before the "connection refused" is recieved
> ...
> Am I wrong in that TCP does'nt lend itself to this kind of handshake
> between client and server?
>
> If it does then what could UlTRIX and/or 4.2bsd do to implement that
> and other support without makeing the user interface even more
> cumbersome or would their whole IPC system interface have to be
> rewritten?
>
> I would like to open this up for brainstorming ...

This capability seems to be worth having.  How about this scheme?

After creating a socket s, but before listening on it, do a setsockopt()
to set an option at the TCP level which says that you want the ability
to do a getpeername() on s when select() indicates that a connection is
available and you don't want the TCP module to send its SYN,ACK packet
until you do an accept.  This requires a new internal state for the TCP
FSM, and that your process had better not dally too long before acting
or the other side will time out.  To reject a connection attempt what
should the user process do?  Maybe an ioctl is the only way to avoid a
new system call.  Then TCP should send a RST packet with an acceptable
ACK(*), as in the case of a security mismatch.

Comments?

---------------------------
(*) It looks to me like there should be no ACK when RST'ing in response
to a SYN with bad security, according to RFC793, but then it also seems
that such a RST with no ACK will be ignored by the active opener.  (I am
looking at the "Functional Specification" under SEGMENT ARRIVES.)  What
am I misunderstanding or overlooking?
_____________________________________________________
Matt		University	crawford at anl-mcs.arpa
Crawford	of Chicago	ihnp4!oddjob!matt