Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site oddjob.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!oddjob!matt
From: matt@oddjob.UUCP (Matt Crawford)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd IPC interface
Message-ID: <1009@oddjob.UUCP>
Date: Tue, 22-Oct-85 18:13:39 EDT
Article-I.D.: oddjob.1009
Posted: Tue Oct 22 18:13:39 1985
Date-Received: Thu, 24-Oct-85 00:48:21 EDT
References: <2192@brl-tgr.ARPA>
Reply-To: matt@oddjob.UUCP (Matt Crawford)
Organization: U. Chicago, Astronomy & Astrophysics
Lines: 39

From: lerner@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@anl-mcs.arpa
Crawford	of Chicago	ihnp4!oddjob!matt