libcs : Connect Streams

The internet service addressing scheme for remote service names and in- terprocess communication is complicated to program. Service naming in the at IP address and port number name space is like naming les and commands by device and inode numbers instead of hierarchical path- names. This is not a pleasant process. An additional complication is the interface dierence between BSD sockets and System V TLI. As a result, most applications either resort to a super-server, like inetd, for estab- lishing communications or copy boilerplate initialization code from other programs.

libcs solves the problem by placing service names in the le system namespace and providing a common interface based on either BSD sockets or System V TLI. A connect stream is a pathname that names a service. Connect stream les allow unrelated processes to rendezvous. A server rst creates a connect stream; then, each client open of the connect stream received by the server presents a unique bidirectional pipe connection between the client and server.

Connect streams may be local or remote. Local connections support le descriptor exchange viacssend() and csrecv() that allows one process

to open a le and an unrelated process to operate on it. Remote streams support pipe or datagram semantics.

Connect stream names match /dev/proto/host/service[/options],

Libraries and File System Architecture 45

host is either a host name (localnames the local host) or an IP n.n.n.n

address. The special host name share names one service that serves

all hosts on the local network; otherwise, the service may run one per host. service is either a service name (for new services), inet.service

(for standard services in /etc/services), or an integer port number

(for old internet services). The options are slash-separated and further qualify the connect stream: user [=uid] restricts the service to the cur-

rent user [or uid]; group [=gid] restricts the service to the current group

[or gid];

other

(default) species no user or group service restrictions. Other options are service-dependent and are used to name dierent in- stantiations of the same service; dierent connect streams name dier- ent services. For example, two dierent process instances of the coshell

daemon program are named by /dev/fdp/local/coshell/user and

/dev/fdp/local/coshell/group=ship.

Most servers reside in the directory libcs/proto/server. server is the

name of the server executable in this directory. For remote connect streams, the le hosts lists the hosts on which the service can be au-

tomatically started. If not specied, then the le lib/cs/share is used.

Ifhosts is empty, then the service must be manually started. Otherwise

the service is started by the rst user open of the service. Service mainte- nance is trivial, as no modications to the kernel init sequence or rc les are necessary.

A server announces its connect stream with csserve(), which also

handles the bookkeeping for new connects, read and write requests, and timeouts. Clients connect to the server by fd=csopen(\connect-

stream",0). Normal read() and write() calls are then used on fd to

communicate with the server.

libcs provides routines for host status monitoring (such as, load av- erage, user idle time), host attributes (such as, mips rating, cpu type), and service monitoring. For example, the cs command lists the active connect streams visible from the local host:

$ cs -lp

# connect stream process

/dev/fdp/local/coshell/user /proc/17692 /dev/fdp/local/dev/user /proc/20112

/dev/tcp/share/dbm/group=ship /n/toucan/proc/6486 /dev/tcp/share/yeast/local /proc/20463

46 Fowler, Korn, and Vo

libcs also supports msgsend() andmsgrecv(), which are used to pack

and unpack system call messages that may be sent over stream (socket) pipes. System call messages are used to monitor processes, as well as to provide alternate system services. The message format is byte-order and word-size independent.

A glaring omission in the UNIX IP address-port IPC interface is client authentication. In a modern computing environment, services must be able to identify clients or service integrity may be compromised. Tradi- tionally, authentication requires some form of encrypted key exchange between client and server, but such an intrusive mechanism would break the le-based illusion of libcs connect streams.

A libcs server can choose to enable client authentication when it creates the connect stream withcscreate(). Each clientcsopen() then initiates

the authentication protocol and handshakes with csserve().

Rather than inventing a new authentication scheme, and in the interest of doing as much work in user space as possible, libcs relies on standard UNIX le access mechanisms for client authentication. Authentication is based on challenge-response. A client csopen() requests a challenge

sequence from the server. The challenge is a le pathname and two 32- bit numbers in ASCII format. The client must create the le with the access and modify times set to the two given numbers (using theutime()

system call). In addition, the set-uid, set-gid, user-read, and user-write permission bits are set and all other permission bits are cleared. On UNIX systems, only the le owner could create such a le. The client sends a null message back to the server and the server authenticates the client by callinglstat() on the le, verifying the challenge numbers, and then

using the le owner and group as the client user identity. If the le does not verify, then the connection is dropped. Otherwise, the server sends back a positive acknowledgement and accepts the connection. The client then deletes the authentication le and continues.

Client authentication between server and client hosts that do not share a le system is slightly more complicated. In this case, the client uses the remote shell rsh to run an authentication agent command on the server host. The client and server handshake just as above, but the agent does

Libraries and File System Architecture 47

the le create and delete. In this case, remote client authentication is as strong as, or as weak as, rsh authentication.

The main advantage of libcs authentication is that no new privileged service is required; it is based on mechanisms already present on UNIX systems.

In document prus-1995 (Page 71-74)