[net.unix-wizards] 4.2bsd IPC interface

lerner@isi-vaxa.ARPA (Mitchell Lerner) (10/16/85)

I've been using 4.2's IPC and It seems that I agree with Jack.  Their system
call's (socket, bind, connect, listen, accept) args are pretty tightly coupled 
with the their IPC's internals. 

The other day I was reading an article by someone (I cant remember who...)
talking about a feature that they would like to see implemented in 4.2's IPC
(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, thus one can
write more powerful and "intellegent" networking systems).  

I wondered at the proposed soulution (using the new ioctl calls); boy that would
be some hairy looking code, with all those funky ioctls in the middle to the
connection establishing sequence.  Then I mused, how could they fit those 
options into the allready existing primatives?  I then sumized that "they" 
would have to write some new system calls that would effect the socket type and
boy that would be non-tcpish.

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 because I've often found myself
limited with the current functionality and I believe that more networking 
support is needed for many systems.

							Sincerely,

							Mitchell

matt@oddjob.UUCP (Matt Crawford) (10/23/85)

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

chris@umcp-cs.UUCP (Chris Torek) (10/25/85)

Note that setsockopt()s are preferable to ioctl()s on sockets, if the
operation is socket-specific; and all the more so if the operation is
protocol specific as well.  E.g., I might write something like this:

	int on = 1;
	...
	/*
	 * Get a socket and bind it to our address, so that we may
	 * begin accepting connections.  Turn on delayed accepts so
	 * that new connections are not acknowledged by the kernel
	 * until a TCP_ACCEPT operation is done.  (Connections may
	 * be silently ignored by simply closing the new socket,
	 * or actively rejected by doing a TCP_ACCEPT with a value
	 * of zero.  Or perhaps you may wish to do this another way.)
	 */
	if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0)
		error(1, errno, "socket");
	if (setsockopt(s, IPPROTO_TCP, TCP_DELAYEDACCEPT,
		       (caddr_t)&on, sizeof on))
		error(1, errno, "setsockopt (TCP_DELAYEDACCEPT)");
	if (bind(s, (caddr_t)&myaddr, sizeof myaddr))
		error(1, errno, "bind");
	if (listen(s, 5))
		error(1, errno, "listen");
	for (;;) {
		client = accept(s, (caddr_t)&sin, sizeof sin);
		if (client < 0) {
			if (errno == EINTR)	/* ick */
				continue;
			error(0, errno, "accept");
			continue;
		}
		/*
		 * Fiddle with `sin' to decide whether we are willing
		 * to accept the connection.  If not, actively reject it.
		 */
		if (badclient(&sin)) {
			int off = 0;

			if (setsockopt(client, IPPROTO_TCP, TCP_ACCEPT,
				       (caddr_t)&off, sizeof off))
				error(0, errno, "setsockopt (!TCP_ACCEPT)");
			(void) close(client);
			continue;
		}
		/*
		 * Accept it.
		 */
		if (setsockopt(client, IPPROTO_TCP, TCP_ACCEPT,
			       (caddr_t)&on, sizeof on)) {
			error(0, errno, "setsockopt (TCP_ACCEPT)");
			(void) close(client);
			continue;
		}
		/*
		 * Connection has now been accepted and communication is
		 * possible.
		 */
		...
	}

This code is quite feasible and would not take much work on the kernel,
now that 4.3BSD allows socket operations at the protocol levels.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

chris@umcp-cs.UUCP (Chris Torek) (10/25/85)

Now that I have proposed a mechanism for doing delayed accepts, I would
like to state that I personally see no need for them.  I think that all
protocols should have some `rejection' messages, more detailed than a
simple `connection refused'.  If you are unwilling to talk to a host,
you should at least be willing to tell it why not.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu