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.educhris@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