Benkas site: Network Protocol, Version 0.1b, 2007-10-04

The REGISTRATION Daemon

The REGISTRATION daemon comes in two flavors, a HOST local and a network local. The HOST local one register all the SERVICE that this HOST serves to be seen localy (on a public accessed HOST this mean ofcource publicly), while the network local one register all that the network serves through the firewall. The network local REGISTRATION daemon talkes to all the local HOSTs REGISTRATION daemons and updates the database accordingly.
We can see some similarity to todays INETd, that handle network requests on behalf of daemons, and it also has a database (/etc/inetd.conf) that describes the various services that it handle.

It's work is twofold:
1. Register (one way or another) the service that can be handled. This should be cooperated with the kernel in one way or another. At the present time, this is a userland process only. Eventually this should also be handled in the kernel even if we still has a userland part of registation. We can look at it the same way as Linux iptables handles the firewall today. It is a mainly kernel space work, but configured from userland. This is the way I see the REGISTRATION process in the future.

2. Route traffic to those services when a client process somewhere would like to use it. This work is needed only as long as we have not implemented the protocols nativly in the HOSTs. When it is implemented, the routing is taken care of by the normal routing handlers within the TCP/IP stack itself.

The daemon uses the AREG protocol to accept and deregister daemons. Note that the HOST where the registration of a daemon came, must be the same when the request for deregistration arrives.

It uses the AUDP and ATCP protocol to route traffic between processes.

The current state of this papper says that the transport used between hosts are UDP port 52118. This means that each host communicate on that port only when we use these new protocols.