#3 Experimental UDP code, tested, working

[Anonymous]

(patch file attached for V19.24)

The new experimental UDP code is working and tested on Linux. For windows, let me know how it goes.

Why UDP? It may solve some problems for people who have different network setups. Like getting around some NAT routing situations, ISP blocking, Wifi Mesh networks or LAN sharing.

To patch V19.24, make a new directory called "test1", download OFFSystem-0.19.24-src.tar.gz and the patch file into it, then...

cd test1
tar -xzvf OFFSystem-0.19.24-src.tar.gz
patch -p1 < version_diffs.patch
cd off_network/build_gtk
make
(then do whatever you normally do with a new compiled version)

The OFF client will operate normally via TCP unless you change one configuration option.

When the program is not running, in the "config/offsystem.conf" file, near the end, edit the use_udp option to enable UDP.

use_udp: 1

You should also rename the "config/known_nodes.txt" file, it contains the IPs of other nodes on the normal OFF network. Renaming it lets you put it back when you want to go back to normal.

Start the OFF client from a terminal and you will see a lot of debug messages about UDP, showing socket open, read and write bytes and a few other messages. UDP is working if you see those messages.

Go to the "Known Nodes" screen and right click then select "Add Node". Type in the other node's IP (and port if different) and a connection should start in about 5 seconds. Both nodes need to be in UDP mode of course.

The first node to start a communication will become what looks like a firewalled node connecting to a open node (for now).

If the other node has no blocks then you will see messages and network activity as it pushes randomly selected blocks to the other node.

Some things that aren't working yet in the new test code:

RSA key exchange is disabled, not sure why it fails since everything else works.

No combo TCP and UDP, just one or the other.

Loopback/web server doesn't work since it opens as a UDP socket.

UDP packets are not error checked at all, or checked for proper order of arrival. It's fun to see it still working OK on a local LAN.

Only one other node is allowed to connect. Code is needed to support
more than one node.

WARNING, privacy risk. Don't post URLs that you don't want others to know you have since it's easy to know who has what URL when there's only two nodes.

Technical notes:

The largest packet I've seen sent is 1024 Bytes so no worries about exceeding the normal MTU so far. However, the IP layer is suppose to break up any packets and handle it if necessary and on Wifi there's more code I'm sure.

TCP and UDP are both a little slow with no throttling set on a local LAN. I'm not sure if it's something I am doing wrong but the CPU usage is low so it isn't processing much.

It may be possible to get around some NAT routing problems by initiating a UDP port scan to some destination from a fixed local port. Wait for one response packet. Keep the UDP hole open by sending UDP packets at a low rate to the remote port that responded. You may now have a open UDP port to the world.

Other clients can do the same (possibly port scan you until they find your open OFF UDP port) and then the connect may go through.

You may be able to forge the sending IP so the other end thinks it's coming from the local or other network. That may take two "connections" to work and both ends would probably have to know what is going on.

You could have "fake" packets that look like they are from other nodes or IP addresses but actually do nothing. With encryption on this would be hard to sort out for anyone "listening in".

You could easily add FEC to each packet so that single bit errors are corrected on the fly.

Discussion going on at board.planetpeer.de

[Nobody/Anonymous]

UDP test code patch file