[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The networking sub-system



Juho =?iso-8859-1?Q?=D6stman?= <jostman@myrealbox.com> writes:

> Are there any documentation about the design and implementation of the
> networking
> system of the Hurd?

It's really pretty simple.

For each supported PF_* protocol family, there is a file
/servers/socket/NNN where NNN is the numberic value fo the PF_*
symbol.  Right now PF_LOCAL (a/k/a PF_UNIX) and PF_INET are supported.

User programs open those files, and use the socket_create RPC to make
a new socket.  With that socket, they can use the other socket_* RPCs
and also the io_* RPCs.  The socket_* RPCs are essentially clones of
the Unix syscalls in question.

The only exception is sockaddrs, which are implemented as ports
instead of the opaque data arrays they are in the syscalls.  You
manipulate sockaddr ports with the socket_create_address,
socket_fabricate_address, and socket_whatis_address calls.  The
sockaddr port is then used in socket calls like socket_connect and
socket_accept.  

PF_INET sockaddr ports are manipulated with socket_create_address from
the usual struct sockaddr_in.  PF_LOCAL sockaddr ports are stored by
S_IFSOCK filesystem nodes; you find the address associated with a node
with ifsock_getsockaddr.  The filesystem server will get a sockaddr to
return with socket_fabricate_address.

The implementation of the pflocal server is in the pflocal directory,
and uses libpipe (shared code with the named pipe implementation).
It's pretty straightforward.

The pfinet server is a hacked Linux internet implementation with a
glue layer translating between the Hurd RPCs and the middle layer of
the Linux implementation.

Thomas


Reply to: