This page has moved. For new location, click
Rodi User Manual
I downloaded the source code, all I got is a heap of classes ... can anyone explain how to use rodi to a layman ...
If you do not want to compile Rodi you can download binary files from http://sourceforge.net/projects/rodi.
Unzip the archive and copy two JAR files in some directory, let's say
should help and the same command can be executed from DOS command shell in Windows you can also try
If you are behind NAT/Firewall you should forward the port Rodi binds (screenshot)
I can't run this thing. When i click BAT file nothing happens
Rodi is written in Java and requires Java Run Time environment on your desktop (yes, i know that Java is not open source and as such is evil, but there is going to be port for C++/GCC in the future). If Azureus runs on your desktop Rodi should run too.
To download Java Runtime Environment (JRE) click http://java.sun.com/j2se/index.jsp choose any platform from available (currently J2SE 1.4.2 or J2SE 5.0), click 'Downloads' (left side of the screen at the top), click 'Download J2SE JRE', accept Licanse Agreement, click Windows Offline Installation. You probably will need to click more than once. Someitmes the server does not respond immediately. Download and run binary installation.
You have to downoad Rodi package (not Rodi WWW, but just Rodi) from SourceForge.net , unzip all files from rodi_??.zip and click runRodiWin32.bat. If everything is Ok you will get something like this Screen Click button SetupWizard, see more in lesson 6.0
I am running it under Linux and I get
It might be my java setup, but other stuff works as far as
Most likely the problem you have because you use
instead See also screenshots taken using Fedora 1, 2, 3
I am running on Linux and I get
Try to change local port by using command line argument LocalPort followed by port number
(screenshots: 1, 2)
Rodi fails with following error
Probably port 81 is not free on your desktop. Check in your firewall is there any application listening on this port. Check in your firewall that Java can access port 81. Try to run Rodi from your disk - download rodi.zip from SourceForge. Use command
to bind diffent (in this example 31100) port on your system.
May I use Rodi on my website to save upstream ?
Absolutely. Rodi core can run scripts. URL to the initialization script can be specified in the parameters for the applet. Size of the applet window can easily be changed. Because Rodi is an open source project you are free to fork the source code any time and make customization like background color, fonts, no log window, etc. (screenshot)
I am using SSH to control my Linux box. Is there a way to run console only Rodi client
Add to the command line option 'AWTConsole false', for example
Performance of LOOK is low. When i specify 200Kbyte/s the applet uses only 20-30K and CPU utilization is 100%. When i make the mask smaller (small IP range) the problem disappears.
Try to configure your firewall to drop ICMP Destination Unreachable packets. This is a good idea for both directions - incoming and outgoing. Use firewall in the modem instead of PC. Fake (spoof) IP source address to avoid recieving of ICMP responses. If LOOK request contains IP source in the payload remote host will ignore IP header and LOOK ACK will be sent correctly.
I see many entries in the ARP table, CPU utilization is 100% and packet rate is less than 30K/s
Check IP settings. If you send LOOK to the peers connected to the same LAN with you (in the same with you subnet) reconfigure your IP interface to the smallest mask possible. This way any IP address will belong to different network and your PC will not attempt to do ARP resolution - this is going to be the gateway working hard and in reality the gateway knows MAC addresses all or signifcant part of existing peers anyway.
The applet works but i am not able to fill my upstream
Java applets run in secured environment which checks every call to the API. It envolves significant overhead especially for UDP operations. To maximize the performance download Rodi.jar file from SourceForge.net and run it from local disk instead of internet.
May I run search on my own disk ?
Run 'look start' command using your IP address, for example 127.0.0.1 and mask 255.255.255.255
Current version supports search by file name and by content in case of text files.
The applet works but i do not see any outgoing packets - i work with Windows XP SP2
find out what your IP address is. Set parameter LocalIP in the HTML file or provide command line argument LocalIP followed by the IP address when run JAR file. For example,
or add command line argument LocalIP followed by IP address if you run Rodi as standalone application. This will make Rodi to bind datagram socket to the specified IP address. In Windows you will have to add IP address to one of exsting IP interfaces - use command netsh
If DHSP is enabled on the interface "Local Area Connection", it will be disabled.
Run Rodi applet.
I am behind NAT. What can I do ?
Generally you can not spoof IP address if you are behind NAT.
If you have access to the box running NAT and can change software/install software on this box there is a solution. Try to open one application port in the NAT, for example 31211. Make sure that NAT does not attempt to change source IP of the ougoing packets for this port - not all NATs support this, but probably some do. Configure Rodi to use this port by adding line
to the HTML file starting the applet.
Another workaround is to write small applicaton running on the same machine with NAT software which simply stamps IP header of outgoing UDP packets with randomly generated/predefined IP address. Such application can stamp, for example, only packets wih source IP port 31211. I am not aware of existence of such application.
Important ! If you spoof IP source address you have to tell to Rodi what is your real visible to ouside world IP address if you want to download data or if you want to inform bouncers where packets should be forwarded to. See also help for CLI command
Click print IP to find out your external IP address.
My ISP drops packets with faked IP sources
80% of connections have filtering (see statistcis at http://spoofer.csail.mit.edu/summary.php). Some things to try are
Also you can ask your ISP to drop all packets arriving to any IP port but 31211 and number 31211 only you, ISP and bouncers you chose know. This way you have protection against some types of DDoS attacks.
This lesson is for peers behind corporate or universitie's firewalls, NATs and traffic shapers.
Rodi provides NAT and firewall penetration support. Basic goal behind NAT penetration is to try to make NAT to create bidirectional tunnel for the outgoing and incoming packets. It can be accomplished in different ways and in some cases can utilize bugs in the NAT software.
Rodi implements different schemes to penetrate firewalls and NATs from inside including fake some of the popular UDP based protocols like RTP and DNS. Rodi packets can easily change "skin" to avoid filtering.
The exact method to use to get through any specific firewall depends on the firewall software.
starts NAT penetration procedure. To use NAT penetration you need one IP address in the outside world. In the simplest case it can be any IP address, like IP address of well known and fast WEB server or, better, IP address of Rodi peer. For example, command
initiates full port scan for the destination IP address 18.104.22.168.
Port scan will use up to 10KBytes/s of upstream.
There are two different cases
In the second case when IP address is an arbitrary address there is a fair chance that the server you are scaning will reply to one or more packets. You need IP sniffer running on your PC ro find out what packets arrive (if any) and from what port and address. The moment you know "responding" address and port stop NAT penetration using command
and restart NAT penetration again with exact port range. For example, assuming that response from the remote server comes from port 2233 execute command
From now on NAT penetration will constantly send packets to 22.214.171.124:2233 keeping tunnel in NAT alive.
Size of the packets NAT penetration uses is under 32 bytes and overhead NAT creates is insignificant even for dialup connections.
(I) haven't close rodi-core since i got nat stat ... this guy (remote peer) is offline now but nat stat still shows me that (the same) port and ip.
NAT penetration attempts to keep hole in the NAT open by sending packets from time to time. If remote post is not available it does not mean that hole in the NAT does not exist. It just means that reported by NAT penetration results are not reliable. For example, if ISP resets the device where NAT runs you will get new port number and NAT penetration will not discover it.
There are two modes publisher can use when delivering data. In one mode publisher delivers data directly to the downloaders (mode A). In the second mode publisher uses Rodi bouncer(s) to proxy data stream (mode B). In both modes downloaders send requests and all required by data transfer protocol acks and retransmission requests using bouncer. Publisher never advertise own IP address, but bouncer(s) IP address and port.
In the mode A bouncer simply forwards all incoming packet to the IP address(s) publisher specified.
In the mode B bouncer operates similar to NAT. When request
from downloader arrives bouncer fetches request ID - 64 bits number, and stores it in the database of pending requests together with IP address and port where the
packet arrived from. Bouncer then forwards the packet to the IP address(s) specified by the publisher. Publisher sends requested by the downloader data back to the
bouncer. Bouncer fetches request ID from the packet and searches for this request ID in the database of pending requests. If request with specified request ID is found
bouncer forwards the packet to the downloader.
Let's configure bouncer. Command
binds bouncer to the port 31100 on the local machine. Bouncer forwards all packets arriving to the port 31100 to the remote peer 126.96.36.199:12011. Bouncer uses up to 10KByte/s upstream.
displays all running bouncers and traffic statistics
I wonder what safeguards will be in place to guard against bottlenecks caused by slow nodes, such as dialup users. I remember that in Freenet's early days, the network suffered from very slow speed because all it took was a single slow node in the chain
Freenet employs local data caches. it means that if you want to get something larger than X Kbytes you will have to download it from two or more sources, and you have to find the sources first and all serach requests are routed too. Freenet is outstanding in terms of routing everything. If Rodi bouncer is compromised adn publisher can not spoof IP source it's over. In Freenet one node can be compromised and even significant number (not majority) of the nodes can be compromised and still the network will provide reasonable level of protection for the participating peers.
One problem remains - packet filtering. Really mighty adversary (think government) can decide to drop all Freenet packets.
Rodi bouncer mode B (both control and data go through the bouncer) is going to operate much better than Freenet/Mute/Ants because number of bouncers in the ring is predictable and this is publisher who chooses (and even probably runs/owns/installs) them.
Think about mode B as a your regular Proxy with one important twist. Proxy server requires additional TCP header in the packet. It means that everybody knows that you use proxy server. In case of Rodi bouncer does not require any special packets. It looks&feels as ordinary Rodi peer. Leacher can not know is it bouncer or actual publisher. Round trip delay is the only thing leacher can use to figure it out, but it is not reliable and i am going to close this loophole too.
The other problem with proxy is that it works hard to terminate TCP sessions with the client and with the remote server client accesses. If Proxy provides SSL tunnel for the client proxy server's CPU works even harder. Imagine that client trys to access web site utilizing SSL. Proxy has to run two SSL sessions (encryption/decryption) one with the client and the other with the WEB site. Rodi bouncer forwards all packets to the destination specified by the rule. Bouncer application consumes zero CPU.
Could dialup users ever be acting as mode B proxy nodes, or would they be excluded from performing this function, and only possibly serve as ACK proxy nodes, or only leaves?
Publisher can run many bouncers on many dialup nodes simultaneously. All bouncers are to be configured in a way to forward packets to the same IP(s) - addresses specified by the publisher.
For example, dialup subscribers willing to help can register on Post IP page and create pool of bouncers for some specific publisher who distributes important and sensitive content
Open file http://larytet.sourceforge.net/scripts/example5 and read it.
May I publish files from FTP server running in my LAN ?
will create bridge between HTTP server and Rodi network.
May I publish files if I am behind NAT ?
Generally the answer is yes. You will need to discover what your IP address and IP port are. You can send LOOK request and check YOU ARE information element in the arriving acknowledges (CLI command TBD). These are the IP address and port you are going to advertise. You have to send dummy LOOK requests every second or so to keep the tunnel (or hole) in the NAT open.
You can also try to use command
You will need to find out what is IP address of the 'NATed' IP interface - the address external world sees (use Print IP or similar services). Command 'nat open' spawns NAT penetration thread. The thread sends UDP packet with the specified destination IP (supposedly IP address of your router) and IP ports from 0-65535. Router returns all packets back to the NAT - echo all packets. When destination port is equal to one chosen by the NAT the echo will go through the tunnel in the NAT back to your desktop. Payload of the packet contains port number.
Open file http://larytet.sourceforge.net/scripts/example7 and read it. Previous command creates file conatining something like this
Rodi Hash XML
I am a publisher. How may I use rodi files ?
Publisher can create Rodi file (similar to torrent file in the BitTorrent protocol) and distribute the file using non-Rodi network, for example, Usenet or regular E-mail. Rodi file contains hash for the whole data and hash of every block of the data and optionally IP range(s) of the publisher/bouncers. Downloader can initiate download using this file. This file will garantee data integrity in case when publisher can not use other authentication tools like nickname and RSA/DSA keys.
How can I publish my public key anonymously ?
Public key is just an ASCII string which you can write down on paper, go to the nearest Internet cafe and publish the key from there. Postig on this WEB site is anonymous - you can find PHP script serving Post IP page in the project CVS. No information besides what you provide in the form is stored on the server (see files at http://larytet.sourceforge.net/posts/)
What are these keys about in layman's terms ?
Imagine that you cut one dollar bill by two halves. You published one half of the dollar bill - everybody has a replica or exact copy of this half. Let's call the half you published - public key. You cut the bill in a way that it is very hard (close to impossible) to reproduce the second half of the bill - the half you keep on your PC, even if one posseses the public key.
Now imagine that you send a written message to somebody and use your private key as a base for encryption - you put relevant letters only in the cuts (and there are lot of these cuts - you made very intricate cut) and mask them by putting many other irrelevant symbols around them. Only with public key one can read such message. And because it is not easy to reproduce private key it can be assumed that the message was writtent by owner of the private key. You can find more info in PuTTY manual: Using public keys for SSH authentication or in PGP Introduction
What if the key server is compromised ?
You will have to find another key server, generate new pair of keys and choose new nickname. You can inform your existing subscribers that you changed your nickname/public key. Signed Rodi packets can carry URL of the key server in the Signature iformation element.
How I know that the key server is not compromised ?
Check your nickname and public key from time to time.
I see that I have to post IP address. Isnt't it dangerous ?
You never post IP address, but range of IP addresses specified by mask. If you are a publisher you usually post IP range of friendly bouncers, not your own IP. You provide to the bouncers a group of IP addresses where one of them is yours. Bouncer sends (replicates) the subcribers requests to all IP addresses including yours. You never publish or compromise your real IP address assuming that you can spoof your IP when sending packets to the subscribers.
I am behind NAT. I know my IP address, but i do not know number of the port NAT opens for me. What port will I post ?
Specify small IP mask, like 255.255.254.255 and port number 0. For example, if your real IP address 188.8.131.52 you can post IP address 184.108.40.206, mask 255.255.254.255, port 0.
Port scan is not supported in the current implementation of LOOK, but NAT penetration can be used to find your port. Most likely you have to run NAT penetration to keep hole in the NAT open. Some NATs will not accept packets arriving from peers you did not send packet to before.
Why subscribers should beleive that behind nickname hides trusted publisher ?
It takes time to create network of trust, but evntually Rodi users will learn what nicknames belong to reliable content providers. Public message boards and forums and authorized signatures of Rodi Houses will facilitate the process of discovering of reliable publishers.
I am a publisher and want to create close group of trusted users. How can i accomplish that ?
The steps to do are:
To send a message to peer, use CLI (Command Line Interface) command "chat send". For example
sends message "hello, world" to peer with IP address 220.127.116.11, port 12011.
If you got a message from peer 18.104.22.168 it will look like
Notice that neither you nor the peer you are talking with (22.214.171.124) acknowldege any message. The only way you can let 126.96.36.199 know that you got a message is to reply with, for example
There are two ways to make acknowledge automatic. You can add public key of the peer found at PostIP page behind 188.8.131.52, like
, where 308201b73082012c060... should be replaced by public key of the peer. Another less secure but more convenient way to do it is to use command 'chat session' to name your chat room. For example,
, where SessionName is arbitrary nickname or alias (you name them whatever). Now your Rodi automatically sends acknowledge messages to 184.108.40.206. This way you know if the message was received or not.
Let's configure your side to sign the packets with your private key. When you used the wizard in setup, a pair of keys was created for you, a public key and a private key. File rodiMng.keystore stores your private key. The file is encrypted with password. Default password is rodiMng.
tells Rodi to load private keys from file rodiMng.keystore Command
tells Rodi to sign outgoing packets using your private key - key with alias rodiMng.
When you send signed packet, 220.127.116.11 recognizes that the message is signed and attempts to verify the signature. If 18.104.22.168 knows your public key the signature is going to be verified and 22.214.171.124 will acknowledge the message. This means that no matter what the ip you are using is, if you have rodi sign your messages with your key, the recipient will know it is from you.
If you have alias or name ('killjoy' for example) for the session you can use shortcut command 'c SessionName message' For example
Is there a GUI tool to manage keystore file ?
See open source project Portecle (sourceforge.net)
Any shortcuts to send chat messages ?
You configured where Rodi is to save files - in the future you will make this a part of your automatic configuration startup script. Copy any file into upload directory c:\temp\Rodi\upload. Let' say that filename is example7.data.
You published the file. It can take some time if the file is large - Rodi calculates file hashes.
You get output like this one
were 192.168.18.41 is you IP address (use ipconfig to find out your IP address). This command looks for the files with the specified hash using address range you provided - actually only one IP address 192.168.18.41. You could specify wider mask, for example, address 192.168.0.0 and mask 255.255.0.0 to look for the file on all computers belonging to the local network (192.168.x.x range is reserved for LANs) Run command
You will get something like this
Wait a moment - Rodi will report that download is completed
and you will find exact copy of the file example7.data in the download folder
Does it mean that i can search and transfer files on my LAN ?
File search and data transfer in the corporate LAN is one of possible applications of Rodi. UDP based transport promising you much better transfer rates than FTP.
In the same time you do not have to install anything - Rodi applet is only 250K byte and can be run from company's intranet, and you do not share folders and you do not need Microsoft NET-BIOS. You have explicit control over every single file you publish and when Rodi is not running nothing is published. In the future Rodi will provide encryption of the packets and authorization to stengthen security of the file search and data transfer.
Where do I check how much upstream/downstream is used ?
Where do I configure max upstream to use, max number of upload session ?
General rule of thumb that every additonal upload slot will add about 25KBytes/s to the upstream and up to the number specified by upstream command
Some confusing configuration commands (for me, at least): conf dld upstream vs. conf dld downstream -- vs. -- conf uld upstream vs. conf uld downstream. Why 4 different commands instead of 2? The "download upstream" might refer to sending ACK packets, but if so, then the "upload downstream" would be non-negotiable (from tm, P2PForums)
There are bandwidth limiters (or rate limiters) for all subsystems and system level rate limiters. Every subsystem or already has or will have both up and downstream limiters. Among subsystems are Upload, Download, Look, Chat, NAT, CLI, Management. For example,
pay attention to the line args (arguments). you can specify how much bandwidth you want to use in your Look.
How do I specify where to save downloaded data ?
I want to run some initialization script every time i start the applet/application
If you run application (JAR) file add to the commad line argument ConfigurationScript followed by the path and filename of the initialization script. For example
No blanks in the file name are allowed. In case of applet running from HTML page add applet paramete, like this
Among useful CLI commands are nop (no operation) and pause (delay script by specified in milliseconds timeout)
Command script will run arbitrary script file after the application is up. See more examples of scripts.
Download binary files from http://sourceforge.net/projects/rodi.
Unzip the archive and copy two JAR files in some directory, let's say
Timple is a GUI management for the Rodi Core. Rodi provides only remote management similar to HTTP interfaces provided by some applications (Azureus, eMule). To use Timple you have first of all to connect to the Rodi Core.
If this is first time (screenshot) you run Rodi click Wizard Setup button (screenshot). Wizard will generate a pair of keys private and public, create keystore file and initialization script for the Rodi Core. Timple expects that files rodiTimple.jar and rodi.jar are found in the same directory.
Run Rodi Core
(screenshot) - you can click rodi.jar if you use Windows. Rodi Core is ready for work.
Set port number of Rodi Core (in our case 53 screenshot) in the related field on the Connect panel of Rodi Timple, set IP address of the machine where Rodi Core runs - 127.0.0.1 for local machine and choose keystore file, for example, rodiMng.keystore. If everything is alright you will see word Connected on the status panel at the bottom of the screen (screenshot)
Click button Log on the left - you will find combined log of Rodi Core and internal log of Timple (screenshot).
I couldn't get Timple to connect to Rodi core on local machine...it gets stuck on Attempting to connect
You have to create keystore file first, then restart Rodi Core. Private key in the keystore file is the only thing protecting your client. If you don't want to restart Rodi Core, you can use command
This command will register public key yourPublicKey and give the owner of the correspondent private key management (mng) access rights.
Where do i find my public key ?
Open file peers.trustees.script in any text editor. You will find line like this
Long hexadecimal string is your public key.
I don't like Java default look&feel and would prefer to see my system look&feel (Windows)
Run Timple from command line using commands like
For example, on Windows you can create runTimple.bat containing line
It works for all Java applications.
I managed to get it going, sort of. The only thing the rodi core outputs to me is this:
Close Rodi Core, delete rodiMng.keystore and rodiCore.script files, run Setup Wizard again.
This bug is in progress.
how do i reach the web-core (RodiCore applet) working together with the web-GUI (RodiTimple applet) ?
Run RodiTimple applet (GUI frontend) from Try Rodi page. Click button SetupWizard on the Connect panel. After setup is completed start both RodiTimple and RodiCore from Try Rodi page. You need two instances of internet browser or two tabs if you use multitab browser. You will have to change port number on the Connect panel in RodiTimple to the port which RodiCore binds. In the release 0.3.1D you have to replace port 53 by port 31211.
Lesson 6.1 (Timple - publishing)
Click button Add at the bottom of the screen to publish new file. Rodi Core calculates hash for the files and it can take time depending on the file size and performance of the PC.
Advertise your IP range, IP port and public key on some forum or here
Lesson 6.2 (Timple - IP hosts)
Add public key of the trutees - peers you will accept data hashes from (screenshot). Flag defines access rights of the peer. Currently there are only two levels - management and publisher. Normally you will need only one public key for the management (screenshot). Management key is used by Timple to access internal data of the Rodi Core.
From this part, I had no idea what you were talking about. Add hosts as what? I tried 2 of them, and couldn't connect to any! Here's an example of the error I get: 'Failed to add host 126.96.36.199 255.255.255.192 31213'
Most likely, GUI front-end (Timple) is not connected to the RodiCore. Make sure that there is word 'Connected' at the bottom of the Connect panel (screenshot). Restart both Timple and CLI based Rodi Core if needed. Run SetupWizard using button on the Timple Connect panel.
After Timple connected to Rodi Core click label Peers on the left side of Timple window to open Peers panle and add entry to the table Hosts.
Lesson 6.3 (Timple - Look)
Lesson 6.4 (Timple - Download)
Lesson 6.4 (Timple - Download)
Lesson 7.0 (NAT traversal advanced)
will start NAT discovery procedure using two NAT traversal servers. NAT discovery procedure will send PING (not a regular ICMP ping, but UDP based Rodi ping) to the specified servers. Rodi NAT traversal servers respond with PING ACK which carrys in the payload external IP address and external IP port of the client.
When the procedure completed CLI will report type of the NAT and external IP address and external IP port of the client. In about 2/3 of the cases NAT discovery procedure reports different external ports - some types of NATs choose different external port for connections to different servers, and in rare cases even different external IP addresses - some networks have more than one external IP address and run load balancing equipment choosing different IP interfaces for the outgoing connections.
After NAT discovery is completed your client learns type of the NAT in your network.
The second step is required only for the clients behind symmetric and restricted NATs. Client sends PING periodically to one of the reliable NAT traversal servers
Client sends PING requests frequently enough to keep the tunnel in the NAT opened.
This way Rodi NAT traversal server can proxy packets from other clients to your client. These packets are of two types - open NAT and close NAT. When client A wants to connect you (assuming you are behind restricted NAT) A asks from you to send a PING to the IP address of A. A can not contact you directly because your NAT drops the packets. A sends the request to the Rodi NAT traversal server. Rodi NAT traversal server being connected to you forwards the packet to you. When you send PING to A you punch a hole in your NAT allowing A to contact you directly. After that data transfer is done directly between you and A without participation of the Rodi NAT traversal server.
Clients behind restricted NATs advertise their NAT type and IP address of the server they are connected to.
A client wishing to contact another client will check the type of the NAT. If type of the NAT is not specified client assumes that there is no NAT and attempts to establish direct connection. If restricted NAT presents client will use broker - specified Rodi NAT traversal server, to contact the remote peer.
... that (Rodi bouncing) would work, but wouldn't it be pretty slow?
The major problems of today's anonymous networks that they attempt to answer 100% anonymity problem or at least try to get close there. They route data traffic using network nodes sitting behind last mile connection as routers. Such network will at least double the traffic and in some cases like Mute the exact ratio remains unknown, because number of proxies is random, unpredicatble and is not limited by the protocol.
Existing P2P networks mainly are TCP based and define protocols which are hard to handle in the firmware. It means that there is no chance that in the future CISCOs of the world will produce Mute routers.
The other problem is TCP related. Larger delays make TCP less efficient. Originally TCP window size was limited by 64K and in reality never exceeded 32K. This problem was corrected some time ago, but it does not mean that TCP is the most effectient protocol for fat connections with significant delays. One can argue that IP stream is going to be more effecient in some cases. One of the problems with TCP that it stores copy of all sent and not acked blocks in the retransmission window. in case of file sharing application (and for this matter in case of any data server) it means wasting of RAM and CPU power. The data is usualluy already in the RAM based cache or in the hard disk cache and can be accessed randomly. TCP makes no assumptions about availability of the data, because such assumption makes the application to keep the data unitl acked, which is not always convenient. For example, signed and encrypted web pages can not be generated easily and such srever would like to see TCP keeping the blocks instead of generating teh same block every time TCP ACK fails to arrive. Application in some cases or in vast majority of cases does not want to know what happens on the Layer 3. If at some point instead of TCP Layer 3 implements somethig else application does not have to do any changes as far as new Layer 3 supports BSD socket interface, copys the data, etc.
TCP layer is viewed by the application as totaly independent device and TCP is good in this - being independent device for reliable data transfer.
The trick in Rodi that data transfer is sent directly. It is only control packets go through proxy.
Rodi makes a promise that protocol is firmware oriented and Rodi packets can be easily processed by network processor or simple ASIC or even FPGA. state machine of the bouncer, for example, is trivial and can be implemented by reasonably experienced Verilog developer in less than a month. Imagine that you install $10 Rodi enabled PCI card on your server and suddenly you are Rodi network PROXY, or crawler or security server or all things together or whatever you want. Rodi from the beginning incorporates notion of bridge connecting (or tunneling if you wish) your existing HTTP/FTP server to the Rodi network with all benefits of the anonymous and distributed search and data transfer read also Privacy in Rodi
... how it could be used to get around censorship measures, especially those at the government ISP firewall ?
If content provider is able to spoof IP address ISP will have no choise but to attempt to block all bouncers (all destination IP addresses). Because peers in the Rodi network never publish their IP addresses, but IP ranges ISP will have to block the whole ranges of IP addresses (like the IPs of Comcast, etc.) or run Rodi client on their firewall. Imagine that you knock a door and from window of house across the street you get a glass of milk. You never know who stands behind the door and you never know how many phone calls are made to serve you the milk. This is more or less how Rodi network operates. You send IP packet to the range of IP addresses (you knock many doors on the street using correct knock pattern - Rodi protocol) until you find out the IP destination (the right door). You send IP packet like GET DATA request to this IP address and you recieve IP packet containing requested data from some other IP. you do not need to know what IP address the data arrives from (and it's useless actually) as far as it contains request ID you initially sent (right knocking pattern), authentication of the publisher (see Post IP page) and data with correct MD5.
Rodi does not provide ulitmate answer to the government driven (mighty adversary) packet filtering. But the good news are that actual data transfer is direct between the peers what means better transfer rates than in case of networks like Mute or Ant which route both data and control streams. Another initeresting side of the story that content providers (or publishers) in Rodi network can change IP addresses dynamically at any moment including ongoing data transfer and the same is correct for the bouncers. The only way to discover in real time new IP address/port is IP scan of the range or active participation in the Rodi network. Because publishers and bouncers implement different traffic policy such massive centralized IP scan from single IP address will be considered as attack and requests will be ignored by the Rodi peers. Rodi network makes promise to be as effecient in data transfer as bittorrent and in the same time it provides reasonable workaround in case of intelligent NAT's/firewalls. This is going to be a dream application for the students sitting behind university NATs.
How Rodi key servers/crawlers/etc are different from servers in other networks ?
Today most of the WEB sites run closed source. Nobody knows what kind of logs they collect because nobody has access to the PHP/PHY scrpts running behind the scene (no pun intended).
In Rodi project we do our best to open everything and make scripts available for the public and it includes also scripts which are intended to run on the servers. We think that this is bad practice to keep WEB server source out of public domain exactly for the same long list of reasons as any other kind of software.
There is not going to be separate registration for every crawler/message board. Any Rodi user can publish his/her public key and nickname. One registration works everywhere. And registration procedure does NOT include any IP addresses, name, number of credit card.
Would you make the crawler act like Distributed Hash table if so you will have a winner (AussieMatt)
Design specs mention that crawlers do many separate things. The most basic functionality is collecting and listing of IP ranges of publishers. Among other interesting things crawler can periodically check availability of the data by sending LOOK request and in some cases even attempt to download and index the data creating searchable index table. In that case crawler behaves similar to regular Internet search engine, but instead of looking only in the indexed (or linked) files like HTML it will look in all published files. Some examples are
The issue is not clear from the legal point of view. Crawler keeping anything else besides ranges of IP addresses of Rodi peers can be found liable in 'contributory copyright infringement' (see Erlich, Klemesrud v. Netcom) in cases when the collected information is found infringing copyright or facilitating such infringement. proffessional advice is required here.
The outcome of MGM v. Grokster case is very important for the network, because Rodi in many respects is a 'true' peer-to-peer network. The responsibilites of the crawler running the software '... totally depends on how the decision reads -- it might just be an obligation to police users in the future, for instance'.
From MGM v. Grokster, Stephen V. Willson United States District Judge - 'In the case of StreamCast, the network is Gnutella , the open-source nature of which apparently places it outside the control of any single entity...The doctrine of vicarious infringement does not contemplate liability baaed upon the fact that a product could be made such that it is less susceptible to unlawful use, where no control over the user of the product exists' (emphasis added).
Rodi - anonymous P2P (from P2PForums)
Rodi does not provide 100% anonymity, but it can be used to protect publishers of sensitive material. Yet anonymity is not main goal of the project. Rodi is open source decentralized alternative to the existing commercial Internet search engines.
I want to find text by content and I want to download it immediately without going somewhere else. I want to be able to find anything stored in Internet and not only linked HTML files. I want to protect publishers of sensitive content. I want to build a network of trust (see public/private keys and identification server in the User Manual) which does not need any index servers like SuprNova. I am trying to open Internet search for anybody by providing immediate access to the content and ability to run own WEB page index engine with own criteria of word rank.
I truly believe that I have right answer to all this.
Size of block vs size of file
I think that for download to work effectively, the file should be sub-hashed using the smallest possible unit (perhaps even measured in bytes, not KB). That way a file could be virtually "streamed" anonymously and an ACK would only need to be sent back for the file segments which failed to complete.
Terminology requires some clarification. Let's give definition to the block. Block is a single smallest unit of the file that we can check for integrity. For example, if you have 4GB file divided into 4MB parts and you get hashes of every one of 1,000 parts than each and every part constitutes a block.
Downloader meets two problems - finding peers who have missing blocks and downloading the blocks in the most effective way. There are two approaches to the
problem of finding missing blocks.
Let's consider two extremes. In one extreme block size is equal to the file size. In this case peer starts to upload data only when the whole file is downloaded. If file size is small and time of download is of the same order as time required to establish connection between peers (0.3-1s) we will get reasonable performance. There is no point to divide the file by smaller blocks simply because time required to find a peer keeping the block and establishing connection with the peer is larger than download the whole file. If the file is large first lucky downloader who connected to the initial seed or publisher has to finish download before it starts to participate in the data transfer as uploader. Because downloader does not have any incentives to share upstream we can expect that downloader will disconect immediately after the file is downloaded.
In the other extereme we choose very small block size. Peer downloads first block, check data integrity and starts to upload. The moment first block is uploaded by the seed or publisher there is a fair chance that this block will be distributed by the participating peers without direct involvement of the publisher. There is a couple of drawbacks we have to consider. First problem is size of the blocks map, the second problem is size of the table of hashes. If, for example, size of the block is equal to MD5 hash or 32 bytes, than we get situation where table of hashes has the same size as original file and can not be downloaded in reliable and fast way.
If blocks map is presented by bits, where 1 means that block is downloaded and 0 that blocks is missing and size of the block is 32 bytes size of the message(s) containing full blocks map is going to be 1/256 of the file size. Assuming 64K packet size we can send map for 500K blocks or for the 16M file. For larger files peers will have to build and send multiple 64K packets. Overall performance of the network improves when peer learn who has what quick. It is essential for the good peformance to have reasonbaly up to date collection of blocks maps. In the best scenario peer broadcasts updated map to every other peer every time there is a new block downloaded. While it's possible to send partial maps it will create problems for the peers who just connected and do not have full map. Then we start to send full map from time to time anyway and so on.
It seems that the only really important criteria that block size should be signficantly smaller than file size. And for faster links we can choose larger blocks.
Let's put some math. Assume that number of peers is N, size of the file - S and number of blocks - K. Assume also that size of the block
hash is H and average bandwidth is B.
Now let's return back to the case where block size is equal file size. If S/K -> S (block size is of the same order of file size) our overhead ratio is 1/[S/(H+TN/8)+1]. If H is small relative to S, for example 32 bytes hash for the 4G file our overhead is going to be NT/(8S + NT). If NT is significantly larger than S (peers broadcasts blocks maps frequently) overhead will tend to be 1 - peers send two times of the file size. If NT is relatively small comparing to S (peers broadcasts blocks maps not to all other peers and do it infrequently) our ratio is going to be close to zero.
If S/K -> 0 (block size tends to be infinitely close to zero) our ratio is going to be 1 - all peers send two times of the file size.
Our next question is time of file distribution. Delivery of the block requires time (S/K)/B. Let's assume perfect scenario, where initial seed delivers every block only once uniformly distributing blocks among peers and overhead is zero. Let's assume also that all peers are cooperating and there is no bottlenecks in the network besides average bandwith B.
Initial seed uploads file in time S/B. Meantime first block is being delivered by peers. Time of delivery of the first block to all peers is (Sln(N)/(KB). Time of delivery of all blocks is (S/B)ln(N).
Pay attention that distribution time is not a function of K - number of blocks. The only thing remains to find out is when last peer gets last block in this perfect netwrok. This time is S/B + (Sln(N)/(KB) or (S + SlnN/K)/B. If S/K is small relative to S last peer gets the last block in time close to S/B or in time required for the initial seed to upload the whole file.
In the perfect network the only reason to make K small is to improve time of delivery of the last block to the last seed. If K is 1 - block size is equal to the file size we will get S[1 + ln(N)]/B and if number of peers N is significant last peer will receive the whole file significantly later than the first peer, specifically Sln(N)/B later.
Choise of K of the same order as ln(N) will promise maximum time 2S/B for any connected peer. For example, we can suggest K ~ N - number of blocks is equal of close to number of peers in the swarm.
What is the maximum reasonable number for K ? Let's assume that time required to find peer who has missing blocks and establish data transfer session is T1.
Time required to send a block from one peer to another is (S/K)/B, where S/K is size of the block. Overall time required to complete downloading of one block is
T1 + S/(KB) and time of delivery of the block to all peers is (T1 + S/(KB))ln(N). Time of delivery of all blocks to all peers is (T1 + S/(KB))Kln(N). As expected,
if T1 = 0 (or very small comparing to time required to upload the block) we get Sln(N)/B - similar to the results above.
Bottom line. Reasonable number of blocks depends on the file size and average bandwidth. Assuming average upstream 10Kbyte/s and file size 1G we get size of the block ~1M or 1000 blocks. For swarms with number of peers significantly larger than K we can increase K (choose smaller blocks) to improve time when last peer finishes download at cost of increasing overhead. Or we can just choose the opposite for large swarms - smaller K (larger blocks) to reduce overhead and improve overall performance of the network.
Why not Mute ?
In Rodi i use innovative approach to the problem of trusted networks. i do not trust Certificate server, but i trust to the publisher with nickname TM and 48 bytes public key, because once in the past i downloaded data from this publisher server. i do not care where pair nickname/public key comes from - there is no doubt or let's say there is fair amount of doubt that identification server is compromised.
i do not care. i am an oiptimist (life is full of reasons to be optimistic, right ?). i feel lucky today - i give a shot. i send LOOK request and get table of hashes. I start download and get the file. Let's put aside for a moment executable files. Let's say that this is HTML file - last letter of dying in R---'s prison leacher. I read the file and it looks alright. From now on i know this guy - TM, that is, this guy is alright. next time i see his nickname in the end of the properly signed packet i trust him.
do you trust SourceForge when you download binary files from their servers ? i guess the answer is generally yes. Even though they use multiple mirror servers and each and every one of them can be compromised. why do you trust them when you download Ants application ? and Ants application writes/reads to/from disk, sends packets to the Internet and does many things which are typical for the spyware/virus. Then why do we trust this s**t ? Because we tried it once and it worked. i downloaded Firefox first time and i have seen that this is good. I decided that their upgrade is going to be even better.
Rodi is different from Amazon. Rodi does not make an attempt to establish authorized certifcate server. not even close. everybody can run Rodi key server - everybody and everywhere. If you tried key server of the Rodi Hunters (there is no such server in reality, but i hope there will be in the future) and found that it's good you will probably try it once again and you will probably even trust all publishers who belong to this house.
let's simplify how Mute works. peer connects to small number of peers (3-5) and exchange encryption keys with them. from now on all transactions between peers are going to be encrypted. Mute client "knows" what key should be used to decrypt the packet looking on IP source. There are so many distinct pairs of keys as there are different peers in the Mute network.
The same is in Rodi. Number of key pairs can be equal or even larger than number of peers.
Where is the difference ? I declare that encryption of the payload is optional. For vast majority of the applications signature is enough and only for the most sensitive data publisher can decide to encrypt the whole payload.
The other deifference is that in Mute you can exchange data only with the hosts you connected to - immediate neighbors. Not the most reliable, not the closest, not the fastest, but just the first 4 or 5 peers you were lucky to connect to.
Mute is good. Probably this is one of the best anonymous networks created so far. If you share really sensitive content and i don't talk here about popular video title - Mute is the way to go.
Privacy comes at performance cost. Search is slow and not reliable. Data is routed through mulitple last mile connections. Packets are encrypted and can not be cached by the ISP. Connections are random in geographical sense (and this is the goal to make them as random as possible), but ISPs prefer to use their own network as much as possible and we want to work together and help each other, right ? this is part of democracy. ISP wants to help us, let's help to ISP. encrypted payload and intercontinental peer 2 peer data transfers are not very ISP friendly.
Rodi can be ISP friendly, but it has it's own ugly face and strong teeth if the situation requires - paylod encryption, faked RTP and DNS packets, etc.
... my ... question is how different is Rodi from bittorrent ? .. I mean at the protocol concept level .. how it works etc
BT network is not searchable and relys on index servers. Rodi is a searchable network.
BT is TCP based. Rodi is UDP based.
BT is not created to work in hostile environments. Part of the functional requirements of Rodi is working from behind traffic analyzers, statefull firewalls and NATs.
BT is not easily cacheable. ISP can not use existing HTTP cache proxys for caching BT traffic. Rodi functional requirements include URL based data requests.
BT can not utilise multicast. UDP based Rodi can use multicast.
BT uses bencoding to encode packets and "torrent" files. Rodi use XML for the files containing data hash and binary opcodes for the packets.
BT tracker is a relatively simple device keeping IP addresses of the peers participating in the data exchange. Rodi crawler can do much more than that, for example, run search engine.
BT does not include any data protection, peer authentication features assuming that underlying layers like HTTPS or IPSec will do the work if required. Rodi functional requirements contain packet encryption and user authentication.
Existing BT clients are heavy feature rich applications. Rodi has a separate light engine and GUI front end.
BT has a single point of failure - BT tracker. Rodi is truly decentralized P2P network.
BT is TCP based and does not provide any protection for the seeds - adversary can easily and reliably find IP addresses of all peers participating in the data transfer. Rodi is UDP based. Seed in the Rodi network can proxy packest using bouncer and can spoof IP source address. Log of Rodi packets collected on the edge of the network is not reliable.
BT protocol assumes availability of streaming sockets in the system. Rodi does not make such assumption. Data transfer subsystem in Rodi is completely separated from the engine.
BT relys on the reliability of TCP - ability of TCP to make all required retransmissions and to deliver the data to the remote peer. Rodi upload in the current implementation streams data from the storage, like hard disk, to the datagramm socket. All retransmission requests are pushed forward to the end of the data transfer session and served by the uploader after first attempt to deliver block to the remote peer.
On the protocol level many things work different. For example, typical size of block in BT is 16K, in Rodi default block size is 4M. BT client sends 'I have block' message to every peer it wants to download from. In Rodi client sends 'I need block'. Because of large block size Rodi can send map of blocks - bitmap of all presenting blocks in single UDP packet even for large files.
IP spoofing is the only reason behind Rodi?
Ability to use packets with spoofed IP address is part of the functional requirements. Rodi is being developed to replace existing centralized search engines. I want to use free open source application to search the network.
I do not want to see Yahoo any more than i want to see Google's ads. I am tired of ads. I want to create an alternative - searchable decentralized network. I want to find data by any text this data contains and then start to download it without going to amazon.
No P2P network today is truly searchable. You can search by filename, not by content. I want MSN or Google like search.
I want to find MP3 by metadata INSIDE of the file. Filename is not interesting, i do not care about filenames.
When you publish a book in Rodi client publishing engine will scan the text and find all words and create index. When look request arrives LOOK engine goes to the index table and finds best match.
You do not have to run HTTP server and put links everywhere over the Net - you just publish the file and wait. Sooner or later i will run Look for all IP addresses and add your IP address.
Now imagine dedicated PC (crawler). Rodi crawler never downloads any data - it just collects IP addresses and index files. When you want to find something in the network you ask crawler(s). You do not have to scan every possible IP.
as i can see in ethereal i know the source of incoming udp packages. and i know this is the real ip of this one. i start a look, i find a file, then i look into peer-list and there is the ip of this one. and then i could try an ip-scan with a tool. next i could see, if activated, the snmp-infos of this ip. if there is a name, then i know the ip, the published files and the name of this on. how does it be secure?
Default mode - IP address is visible
Different from I2P, Mute, Ants and other anonymous networks Rodi does not provide immediate IP masking. By default Rodi does not route packets. Rodi works exactly as any other P2P network like Bittorrent. Peer A sends request to peer B. Peer B sends response to peer A.
In this mode assuming normal conditions of the network performance is expected to be comparable to the performance of the Bittorrent network. Because Rodi is UDP based multicast can be supported in some networks (LAN) improving performance dramatically. For example, multicast in LAN can be used to stream HDTV to 100s or even 1000s IP nodes from only one regular PC. Another point is that data transfer protocols using UDP can be extremely aggressive in utilization of available bandwidth. Over "fat" connection with signifcant delay and jitter and high packet loss ratio UDP based protocols will tend to perform better than TCP.
There are three ways to hide IP address in the Rodi network. All methods can be used together and separately.
On the diagram Bouncing mode B you see simplest way of using of Rodi bouncer. In this case Rodi bouncer behaves exactly as, for example, regular HTTP Proxy. Seed (or publisher) is completely hidden behind Rodi bouncer (or ring of Rodi bouncers). Publisher asks Bouncer(s) to help to distribute some content. Bouncer agrees. Publisher advertises the content and IP address and IP port of the bouncer. Publisher can post hash of the file, file name, Rodi Hash file in any combination. Downloader sends packets to the Bouncer. Bouncer forwards all packets to the Publisher. Publisher sends all packets to the Bouncer. Bouncer knows to route the packets correctly if there is more than one Downloader.
Bandwidth available for the publisher is limited by the upstream of the bouncer. If bouncer is 56K dialup publisher's upstream is limited by 56KBit/s upstream. Downstream of the dialup modem is not going to be relevant in most cases because Rodi control packets are small and control packets are rare.
Publisher can also use more than one Bouncer in parallel. Publisher advertise IP address and IP port of all bouncers. Available to the publisher upstream is a summ of upstreams of all bouncers.
To improve security Publisher can create a ring of bouncers - connect bouncers one after another. This way log on the ISP where first bouncer is connected will deliver IP address of the second bouncer and so on.
Rodi Bouncer provides relatively good protection for the publisher assuming that publisher chooses Bouncers among trusted parties or chooses random Bouncers from large pool of Bouncers. The setup can be attacked by mighty adversary using exactly the same mehtods as in Tor or FreeNet networks. For example, adversary can compromise all or majority of the bouncers in the network. Adversary can also log all traffic from all nodes in the network. Currently Rodi does not encrypt payload. Adversary can also consider the network as a block box and hold liable every node sending sensitive data, both Bouncer and Publisher.
Bouncers are willing to provide bouncing services because their score on the seed'c client is growing (implemented partially). Seed will tend to serve bouncers first, because bouncers have better score.
Let's say that Publisher can spoof IP address. Publisher is able to send packets with arbitrary IP address or with IP address which is different from one Publisher gets from the ISP
Now Publisher has more choises. In one of the possible setups Publisher advertises real IP address and IP port. Downloader sends packets to the Publisher. Publisher sends response to the Downloader but places different IP in the IP packet
Performance of the network is the same as in regular not protected P2P network.
Let's say that adversary compromised Downloader. Adversary sends a packet to the Publisher (destination IP). Adversary sees response arriving from different IP address. Adversary should suspect that destination IP address belongs to the bouncer and that real IP address is the one where packets arriving from. Adversary has no meanings to prove that destination IP is a real IP address of the Publisher. Adversary has to log all the traffic on the Publisher node to find out that Publisher spoofs IP. This requires long investigation and can not be done in the real-time. Adversary snifing packets on the edge of the network can not find out in reliable way IP address of the Publisher.
Bouncers and IP spoofing
In another scenario Publisher uses Bouncer, but only for the downstream. Publisher advertises IP address and IP port of the Bouncer. Downloader sends packets to the Bouncer. Bouncer forwards packets to the Publisher. Publisher sends response to the Downloader with different IP address in the IP packet header (Bouncing mode A) To improve security even more Publisher can ask Bouncer to forward packets to more than one IP address (see Bouncing Figure)
Performance of the network is only slightly lower than in the regular not protected P2P network, because of higher packet loss over longer path. Most of the data - actual upload, is sent directly from the Publisher to the Downloader.
Adversary is in about the same situation as before. Log of the traffic on the node where Bouncer is connected will not deliver reliable result, because there is possibility that Publisher uses more than one Bouncer. Adversary can also discover that Bouncer forwards packets not to one but to many IP addresses. Log collected by the compromised Downloader shows only IP address of the Bouncer and IP address which Publisher decided to use for the responses.
Publisher can spoof IP address and use bidirectional Bouncer - both upstream and downstream. This way even compromised Bouncer can not be sure that IP address(es) it sends packets to belong to the Publisher.
Network of trust or l33t hubs
If you installed Rodi already and had a chance to use GUI front-end (RodiTimple) you ran your own small network of trust. This network contained two peers - RodiCore and RodiTimple.
After you start RodiTimple it opens file rodiMng.jks. rodiMng.jks is an encrypted (default password rodiMng) storage of private keys. RodiTimple reads private key from the file rodiMng.jks. RodiTimple signs every packet it sends to the RodiCore using this private key.
After you start RodiCore it attempts to read and execute initialization script. Part of the initialization script is adding of public key(s). To use GUI front-end you have to add at least one public key - twin brother of the private key which RodiTimple found in the keystore file rodiMng.jks.
When RodiCore sees a request from the GUI management it checks the signature and makes sure that the packet is signed using correct private key. If everything is fine RodiCore serves the request, if the packet is not signed or signature can not be verified RodiCore drops the packet without any acknowledge.
Publisher asks friends to send (advertise) their public keys. Publisher adds these public keys to the list of the trusted peers (trustees). Publisher configures RodiCore to drop unsigned or signed with unknown signatures packets.
Rodi uses one of the strongest signatures available today - DSA-1024
Ability to spoof
I've met (see State of IP Spoofing http://spoofer.csail.mit.edu/summary.php) estimation that about 25% of existing connections can spoof IP address. In some cases node can not use arbitrary IP address, but address from some subnet. If node is behind NAT IP spoofing is NOT possible. IP address of the packets will be set by NAT. For example, if node's IP address 192.168.x.x this node is NATed - this node is behind NAT. Inside of the LAN node usually can spoof IP address. It can be the case in corporate networks, campuses, WiFi networks, etc.
Why Rodi ?
Rodi does not provide strong protection for the particpating peers. The same attacks which are possible in other networks are possible in the Rodi network too. Current code of the Rodi client does not provide encryption of the payload. If adversary can collect ALL outgoing and incoming from the publisher packets adversary will prove that publisher participates in the distribution.
Rodi promises high performance and efficient bandwidth utilisation when compare with existing anonymous P2P networks. In the Rodi network Publisher chooses (and probably runs) bouncer. Publisher can choose good bouncer or bad bouncer or Publisher can decide to work without bouncer at all. In all cases adversary will find that it is hard to prove that some specific IP address belongs to the Publisher.
Let's say that adversary sends packet to some IP address and gets response from the same IP address. Naturally adversary assumes that Publisher can not spoof and that Publisher does not use Bouncer. Adversary goes ahead and checks the PC. Adversary can find out that in reality PC is just a bouncer and apparently Publisher spoofed IP address - set IP address of the Bouncer in the response.
Smart Publisher can prepare a perfect legal trap for the adversary which jumps to conclusion too fast. Simple sniffing the packets on the
edge of the network is not going to be enough anymore. Adversary will need access to the logs of multiple ISPs. Log collected by ISP should be
rather large - it should contain IP header of the packet, exact timestamp and part of the payload.
I can't use IP address spoofing. Is there any other uses ?
IP Port spoofing is possible in most of the network setups. Rodi client can listen for requests arrivng to one port and send responses using another port.
Let's assume that publisher listens on port 31211 and sends packets out using port 31212. Publisher asks the ISP to drop all arriving packets besides the packets with destination port 31211. IP Port filtering is a relatively simple thing to do for ISP - most of IP routers support this. Publisher accepts only signed packets from trusted hosts and drops packets which can not be verified as trusted. Adversary running DDoS against publisher will have to attack all ports (64K) simultaneously or figure out the port number where publisher waits for the requests.
Please remove this feature [IP Spoofing] from your code.
...side note first. Rodi is not the only project which incorporates IP spoofing as part of the functional requirements. I know about two other open source and a couple of commercial products. Sometimes it is not being called IP spoofing bit it does not make it less (or more) efficient.
think about all possible applications for IP spoofing. Let's say that you are a publisher behind a narrow link, like T1 or some type of DSL. In the TCP network you are exposed to all kinds of attacks from trivial SYN floods from a single bot to well organized distributed attacks exploiting holes in your firewall.
Let's assume that you utilize Rodi bouncers to verify the packets from your subscribers before forwarding the packets to your server. Among your options: