Rodi Help

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 \temp\rodi If you run Windows and Java2 Environment is installed simply click rodiTimple.jar file and then follow instructions in lesson 6 of the User Manual
If you use Linux command

java -jar rodiTimple.jar

should help and the same command can be executed from DOS command shell in Windows you can also try

javaw -jar rodiTimple.jar  
start javaw -jar rodiTimple.jar

If you are behind NAT/Firewall you should forward the port Rodi binds (screenshot)

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.

There are two ways to run Rodi. The first is click 'Try it', the second 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

Most likely the problem you have because you use

java rodi.jar
try

java -jar rodi.jar
instead, or

javaw -jar rodi.jar

See also screenshots taken using Fedora 1, 2, 3

Try to change local port by using command line argument LocalPort followed by port number

java -jar rodi.jar LocalPort 31100

(screenshots: 1, 2)

LocalPort followed by number of IP port to specify port to bind.
AWTConsole followed by flag true or false to use Rodi from SSH/Telnet/command shell
ConfigurationScript followed by path (URL/URI) to the initialization script
Example: java -jar rodi.jar LocalPort 4500 AWTConsole false ConfigurationScript file:///home/rodi/rodiCore.script (screenshot)

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

java -jar rodi.jar LocalPort 31100

to bind diffent (in this example 31100) port on your system.

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 open source you are free to fork the source code any time and make customization like background color, fonts, no log window, etc. (screenshot)

In progress

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.

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.

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.

JRun 'look start' command using your IP address,
for example 127.0.0.1 and mask 255.255.255.255
Current version supports only search by file name, in the future search by content will be provided

Using command

ipconfig

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,

<param name = "LocalIP" value = "192.168.18.1">

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

<param name = "LocalPort" value = "31211">

to the HTML file starting the applet.
Another workaround is to write small applicaton running on the same machine with NAT 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. See also help for CLI command conf ip
Click print IP to find out your external IP address.

80% of connections have filtering. Some things to try are

• use IP address belong to your subnet.
• use multicast range of IPs.
• use IP address belong to the subnet of your modem IP address

If nothing works you are not among lucky 20%. If you are a publisher you can ask your ISP to permit you to send IP packets with spoofed IP address, for example, some dummy IP address - garbage collector.
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

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.

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.

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

Yes. publish url is exactly for such applications. Rodi client can bridge between FTP server and Rodi network. Rodi network will hide FTP IP address and only IP address of the Rodi client (or Rodi bouncers) will be visible to the downloaders.
For example,

publish url↵
http://www.digitaldistribution.com/samples/openofficeintro11en.swf

will create bridge between HTTP server and Rodi network.

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

nat open

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.

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.

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/)

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

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.

Check your nickname and public key from time to time.

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.

Specify small IP mask, like 255.255.254.255 and port number 0. For example, if your real IP address 63.158.100.211 you can post IP address 63.158.101.211, 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.

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.

The steps to do are:

• Generate a pair of keys for every user of your network
• Send private keys to the owners
• Make all public keys available from some website
• Add public keys to the Rodi database of the public keys
• Ask user to add all public keys
• Configure Rodi to drop not signed packets (Not implemented, In progress)

See open source project Portecle (sourceforge.net)

Command cc followed by arbitrary string will send the string to the peer you talked to last (nickname). Command cv will send the message to the last used IP address/port

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.

Try commands

	dbg tx
	dbg rx
	dld stat
	uld stat

Try commands

	conf uld connections?
	conf uld upstream?

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.

There are bandwidth limitevs (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,

/look startFile ?
Help:startFile
Args: [words to search] [bandwidth Kbyte/s] [retrys]
Example
linux.distro 1 3
Look for words linux and/or distro, up to 1KByte/s,
resend 3 times to not responding peers

pay attention to the line args (arguments). you can specify how much bandwidth you want to use in your Look.

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

java -jar rodi.jar ConfigurationScript file:///C:/temp/rodi/scripts/startup

No blanks in the file name are allowed. In case of applet running from HTML page add applet paramete, like this

<param name = "ConfigurationScript"↵
value = "http://larytet.sourceforge.net/scripts/example5">

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.

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

conf key addPub rodiMng mng yourPublicKey

This command will register public key yourPublicKey and give the owner of the correspondent private key management (mng) access rights.

Open file peers.trustees.script in any text editor. You will find line like this

conf key addPub rodiMng mng 3081f03081a806072a8648ce380...

Long hexadecimal string is your public key.

Run Timple from command line using commands like

java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel↵
-jar rodiTimple.jar

(screenshot).

java -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel↵
-jar rodiTimple.jar

(screenshot).
For example, on Windows you can create runTimple.bat containing line

start C:\j2sdk1.4.2_05\bin\javaw↵
-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel↵
-jar rodiTimple.jar

It works for all Java applications.

Close Rodi Core, delete rodiMng.keystore and rodiCore.script files, run Setup Wizard again.

This bug is in progress.

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.

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.

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

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.

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.

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

• HTML, PS, DOC, PDF and other text information
• Meta data in audio and video files
• Subtitles in video files
• XML files (will require additional plugins)

Again crawler and for that matter any peer node can find all published files, not only linked files.
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 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.

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.
In one all peers regularly send updates to some server what blocks they have. Downloader asks server what peers have required block, get list of peers and send GET DATA request attempting to download data from the peers. This approach is most efficient, because all the data is collected in a single place and reasonably up to date. There are two major drawbacks in this scheme. Server is a single point of failure and if removed from the network peers can not finish file download. The other problem that this server knows IP addresses of all participants.
In the second approach peers send each other lists of blocks they have. This way peers learn availability of the blocks. Peer maintains it's own blocks map - blocks the peer downloaded already and collects maps received from other peers. Downloader constantly looks for the peers whose maps contain required 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.
Size of the block is (S/K)
Size of the hash table is (KH) and to be delivered to all peers once will require [KHN] bytes
Size of the full blocks map is (K/8) assuming one bit for block
Let's say that a peer wants to inform all participating peers about available blocks at least T times. Total number of blocks maps sent by the peers is (T*N*N) and total traffic is [(TNN)(K/8)]
Total overhead of the protocol is [KHN] + [TNNK/8] or [NK(H+TN/8)] (summ of all hashes and maps)
Expected best case scenario traffic is (NS) - size of the file times of number of peers. Real traffic is {(NS) + [(NK)(H+TN/8)]}. Overhead constitutes [(NK)(H+TN/8)]/{(NS) + [(NK)(H+TN/8)]}

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.
Reasonable choise for the number of blocks is when S/(KB) >> T1 - time required to upload a block is much longer than finding peer and establishing connection. In my tests i found that typical time to find peer with required block and establish connection is tens to hundreds of seconds. Let's choose S/(KB) equal 10T1. In case of T1=10s S/(KB) = 100s and K=S/(B*100), where B is average bandwidth. As expected lower B gives us larger K - dialup connections prefer larger number of blocks and broadband subscribers prefer smaller number of blocks.

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.

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.

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.

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.

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.

• hiding behind bouncer
• spoofing IP source address
• network of trust (l33t hubs)

You can find usefull hints on Wikipedia pages

Bouncers

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.

IP spoofing

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 estimation that about 25% (see State of IP Spoofing http://spoofer.csail.mit.edu/summary.php) 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.
Let's say that large ISP has 100K subscribers behind 1MBit/s upstream connections. Assuming packet size 1400 bytes and 70% loading of the network we get 5M packets/s. Log keeps IP header (8 bytes), timestamp (8 bytes), part of the payload (8 bytes) or 24 bytes for every packet. Total amount of data is 120Mbytes/s or 10T/day.
If we assume 2K subscribers behind every gateway (DSLAM/CMTS) we will get ~200G/day of logs. While it's possible technically i am not aware of any existing system which is able to do this for all existing connections simultaneously.

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.

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

• use bouncers for upstream too (you can do it using regular Proxy)
• broadcast/multicast/unicast data directly to the subscribers (and expose IP address and port)
• spoof IP source address
• spoof IP source port

The last one is the most interesting because it is available in almost any network setup. call your ISP and ask them to let in only packets with destination port 31211 and to drop all other packets. Now only bouncer(s) and the ISP know what port is a "server". when you send response you use some other port. Blunt attack against you should target simultaneously all 64K ports at rate of your T1.