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