4.2bsd IPC interface

Mitchell Lerner lerner at isi-vaxa.ARPA
Thu Oct 17 03:54:59 AEST 1985


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



More information about the Comp.unix.wizards mailing list