Actually, we had a long discussion earlier (last May/June) about non-socket
based implementations (e.g., fork and shared memory). The collective nature
of both the spawn and client/server calls was originally designed to allow
efficient networks to update routes and tables, and to avoid the usual race
conditions. Various proposals explaining how spawn and client/server might be
done were discussed then. As one concrete approach, an application on a
shared memory system could use a SYSV named segment as the named "port"; all
of the "socket" functions (listen, connect, etc) can be built on top of this.