#5 Experimental reliable UDP code, tested, working

[Anonymous]

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

windows and mac should be supported, see the UDT code and change the makefiles for flags like WIN32, things like that. See the patch file for info on how I mod'ed the makefile for linux.

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

Before you do "make", download "udt.sdk.4.2.tar.gz" from:
http://downloads.sourceforge.net/udt/udt.sdk.4.2.tar.gz

tar -xzvf udt.sdk.4.2.tar.gz
cp -r udt4 off_network/src/
cd off_network/build_gtk
make
(then do whatever you normally do with a new compiled version)

The UDT folder will be included in the OFF tar.gz file so you won't have to download it again (if this mod is accepted).

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

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

Have fun and please post on how your test went.

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

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

Loopback/web server doesn't work since it would be a UDP socket.

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

Technical notes:

The largest packet I've seen sent is 1040 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.

Wild ideas:

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.

see board.planetpeer.de for comments

[Nobody/Anonymous]

UDT version of UDP code patch file