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