With STUN we can detect what kind of NAT we are behind. This information
may be useful to distribute:
physical.udp=<ip 1>;<ip 2>;<ip 3>;<ip 4>
- Provide a global list for backwards compatibility, at least for now.
physical.udp.open=<ip 1>
- IP addresses that packets can be sent to from anywhere. This is either
because they are directly connected, port forwarded, or full cone NAT
(assuming packets are being sent out on the full cone NAT). Even on
full cone NAT, the port number can be changed.
physical.udp.restricted=<ip 2>
- IP addresses that are behind restricted cone NATs. Packets can be sent
to these IPs if the node has already sent packets to the sender's IP.
physical.udp.port-restricted=<ip 3>
- IP addresses that are behind port-restricted cone NATs. Packets can be
sent to these IPs if the node has already sent packets to the sender's
IP:port pair.
physical.udp.symmetric=<ip 4>
- IP addresses behind symmetric NATs. Symmetric NATs produce a new port
number for each {IP,port} to {IP,port}. However, they can connect to
open or restricted. (NOT port restricted, unless you are very lucky,
and definitely not symmetric unless you are absurdly lucky).
What can we do with this?
- We can tell the user when he has connections which can't carry UDP at
all.
- We can determine whether we are likely to be able to connect to a
node.
- We can not send handshake packets continually if we know that we are
"open". (This can be reliably detected by the STUN plugin, I haven't
discovered any other way to reliably detect it).
- If we are "open", we can use invites without knowing the other side's
IP address in advance.
- We can handle port numbers being changed by the NAT in a far less
confusing manner: If we get a reported port number from a node for a
NATed IP which is not the same as our listenPort, that is probably
correct.
- If the NAT does not preserve port numbers, then the user will require
at least one open or restricted node to connect to during bootstrapping.
Unfortunately we cannot detect this until we have a connection!
However, if we have no connections, but on last startup the NAT did
not preserve numbers, we can suggest to the user that they get some
open or restricted connections.
- We can display the NAT mode on the darknet page.
As you can see, there are some major possibilities. I will however just
grab the addresses for now and ignore the rest. Others are welcome to
integrate it more fully. The plugin implementing STUN based on Thomas
King's JSTUN implementation is in trunk/plugins/JSTUN. The code which
drives this will very soon be in freenet/pluginmanager/FredPluginIPDetector,
freenet/node/IPDetectorPluginManager and some methods in Node. If you
want to hack on it, please keep me up to date, and if you need any
information, tell me.
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060706/a8a96db9/attachment.pgp>
