feda/doc/peer_types.txt

                                 PEER TYPES


In the fedaserv configuration file, typically ~/.fedanet/serv.conf, each
peer description section has the field named ``type''.  Its value is
supposed to be a space-separated list of tokens identifying particular
property of the peer; typically there's only one such token, but it is
still useful to keep in mind multiple tokens may be used.


******
TYPE: default

Actually, means nothing.  Should perhaps only be used in case you want to
give the peer a name, but don't need anything special.



******
TYPE: mynode  

We're working as a point (that is, point id != 254), and the peer is
expected to be our belowed node -- generally, a fedaserv instance with the
same node id and the number 254 as the point id.

As of present, this just means the server must try connecting that peer and
keeping it associated, permanently -- just like the ``persist'' flag does.
The type is ignored if the ip address and the port are not specified for
the peer.  No checks are performed, that is, even if the peer doesn't
appear to really be our node, nothing speciall will happen.



******
TYPE: natcheck

We're working as a part of a NAT type checking group of servers, and this
peer generally belongs to the same group -- in the sense that we can use it
to serve NAT checking requests.  Implies that a persistent association
should be managed.

The type is ignored if the ip address and the port are not specified for
the peer.



******
TYPE: persist 

The server must try connecting that peer and keeping it associated,
permanently -- typically to have a direct IPv6 connection with the peer's
FEDA subnet.

The type is ignored if the ip address and the port are not specified for
the peer.



******
TYPE: nodenets

The idea is to delegate serving node-wide IPv6 subnets (those ``points'' 0,
255 and may be 254) to another instance of fedaserv.  For the node
instance, it means the networks FEDA:(node_id):00xx:xxxx and
FEDA:(node_id):FFxx:xxxx are served by the given instance and the
respective packets must be routed there; if the current instance does not
have its own tunnel network interface (feda0 or whatever), the network
FEDA:(node_id):FExx:xxxx is also routed there, otherwise it is kept
locally.  For a non-node instance, this flag should mean the destination of
the 00 and FF networks, but not the FE one, which is always sent to the
node instance (and may be sent further by that instance).

This may be useful for a node running on a low-end VPS (or another kind of
a machine not well-suitable for running a lot of services) while the
servers being run by the node are desired to run at, e.g., a nodemaster's
home computer.



******
TYPE: trustncc      ! NOT IMPLEMENTED YET !

Basically, we trust this peer (its node+point's key) in the sense of
accepting foreign nodes' keys _without_ _computing_ _their_ _hashes_;
furthermore, in case an unknown node tries to connect us, we can ask all
(or some of) known&active trustncc peers whether they know the node, and
they might send us the node's master cert (signed by them) so we can accept
that node without computing the hash.

For a point, it may be useful (although not necessary) to declare the
point's own node as trustncc, specially if the point has good conectivity
conditions and plans to establish direct connections with others.  Besides,
it may be useful for a node to declare some friendly peers as trustncc,
just to save time and the CPU power.  It is not strictly necessary to get
their permission to do so; presently all fedanet instances respond to the
respective type of requests properly.  However, it might be a good idea to
ask if they really don't mind.



******
TYPE: certhub       ! NOT IMPLEMENTED YET !

This peer (which possibly belongs to another node, although this is not
necessary) works as a ``hub'' for distributing node certs.  This means it
generally accepts introductions from new nodes, checks their hashes, saves
checked keys in its local database and responds on requests for the stored
certs.  Technically, specifying this flag means our daemon will suggest
newcomers with unknown node IDs to introduce themselves to this peer; in
case the peer's configuration doesn't specify the ip:port, it is only used
as a certhub when an established association exists.  You might want to
always use the ``trustncc'' flag for peers of this type.



******
TYPE: introducer    ! NOT IMPLEMENTED YET !

This peer, typically a more powerful machine working within the same node
(e.g., a home machine of the node master), agrees to act as an introducer,
which means that we can ask it to introduce our node to the given instance
of fedaserv, so that we don't have to do this on our own.  This is intended
primarily for the nodes running on low-end machines, so that they can
delegate introducing work to something powerful.

This peer type may (and should, although is not obliged to) be specified by
the node.point pair, not by the ip:port, so that the introcuder machine may
run behind a NAT of any type, and once it establishes the cryptographic
association with the node, the node becomes able to use its service.



******
TYPE: proxy

This peer is to be connected before anything else, and then used as the
datagram relay (that is, fedaproxy).  Must be specified by ip:port.  In
case we have a peer of this type in the configuration, we won't be able to
perform any communication when it is not available or is not willing to
serve us (with the exception for peers that marked as ``direct'').

Only one peer of this type may be specified.  If two or more peers are
labelled with this flag, the result is not defined (which means newer
versions may demonstrate completely different behaviour for the situation). 



******
TYPE: proxyuser

This peer is authorized to use us as its proxy server.

Must perhaps be specified with node.point pair.  The proxyport parameter
is mandatory for this type of peers in the present version.



******
TYPE: direct

In case we have a proxy, this peer is still to be connected directly.  This
flag is implied for the proxy itself (for obvious reasons).