                                 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

Trusted node certificate center.

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

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;
hence, peers of this type must be specified as ip:port.  You might want to
always use the ``trustncc'' flag for peers of this type.

At that peer, the fedaserv daemon must be configured accordinly, which
means it must have the lines 'allow_nodehash yes' and 'intro_accept yes' in
its configuration file, AND the properly generated challenge-response table
file.



******
TYPE: introducer

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.  Besides, this
peer checks foreign node certs forwarded by its siblings (that is, points
of the same node), primarily the node itself.  This is intended primarily
for nodes that run 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.

You might want to use the ``trustncc'' flag for peers of this type.  If
this flag is not specified, an introducer peer is still able to introduce
its node to others, but its cert-checking job is fruitless.

Please note the introducer peer MUST run as a point of the same node,
otherwise it won't accept our requests.



******
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 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).

