Rodi
From Wikipedia, the free encyclopedia
- For the language Rodi, see Rodi language.
| Rodi | |
|---|---|
 |
|
| Developed by | larytet |
| Latest release | 0.3.60 / May, 2006 |
| OS | Cross-platform |
| Genre | File sharing, Anonymous peer to peer |
| License | GPL |
| Website | rodi.sourceforge.net/ |
Contents |
[edit] Overview
The Rodi Network is a peer-to-peer file sharing network. The Rodi client is open source software released under the GNU General Public License and supports all platforms where Java is available.
There are three ways to surf anonymously in the Rodi network. All methods can be used together or separately.
- hiding behind bouncer
- spoofing IP source address
- network of trust (hub)
Rodi network supports context sensitive content search. Because Rodi is a distributed network, keyword rating and search results can differ from publisher to publisher. Rodi network can be viewed as a group of loosely related or completely unrelated search engines.
Rodi is built on UDP and promises to perform better than TCP over congested links, links with significant delay and packet loss and on networks where multicast services are supported.
Rodi provides a solution for nodes hidden behind NATs, firewalls, protocol analyzers and packet filtering equipment.
Rodi implements a connectionless handshake between peers.
[edit] Typical Protocol Scenarios
[edit] File Search
- Peer A sends "Look Request" to peer B. Look request is a UDP packet and contains XML formed pattern.
- Peer B optionally checks signature and tries to find the specified pattern in the filenames/text of the files or on the list of the hashes.
- Peer B compiles list of search results sorted according to "relevance". Search results include hashes of the files.
- Peer B sends the compiled list to A or (optionally) sends "Not found" or "Busy" messages. B can send list of peers where the requested file can be found or just a random subset of known peers.
Peer A can run IP scan looking for active Rodi peers. Peer B can publish IP range to scan. Example of such IP range can be a group of IPs belonging to the peer B ISP or just a subnet, like 0.172.12.131 - 255 IP addresses. If peer B drops unsigned packets, peer B can be completely invisible for unauthorized peers. Assuming proper firewall configuration, regular port scan will not discover that B has open Rodi port.
[edit] Download
- Peer A knows that peer B has a file with specified hash.
- Peer A sends "Get data" to B.
- B can drop the request, send "Busy", send "No such block" and map of available locally blocks, list of peers who probably have the requested block.
- If the block presents on B and upstream of B is available, B sends to A "Get Data OK" and starts to stream the requested block to A.
- When A receives the "Get Data OK", it opens a session and stores all incoming chunks on the disk (via small cache in the RAM).
- B streams the data (a single block) at the rate specified by A (or slower). B does not expect any ACKs.
- A collects incoming chunks and reports to B only missing chunks. A is free to report missing chunks at any point, but typically reports a chunk missing after there has been no data for some time. A can report more than one missing chunk in a single request.
- B collects "missing chunks requests" arriving from A and serves the requests according to FIFO.
- After A has collected all chunks in the block, the hash for the block is calculated and compared with either the hash provided by B at the start of the data transfer session, or with a hash from an external source (such as a Rodi file). A Rodi file is an XML file containing block hashes, a data hash, a file name and description, etc.. See *example
[edit] IP Address Spoofing
- B is able to spoof IP address - B is to build and send out packets with IP address which is not IP address of B
- B posts IP range, for example 0.172.12.131, where one of the IP addresses (3.172.12.131) belongs to B
- A sends Look request to all IP addresses in the range specified by B
- When Look arrives at B, B checks (optionally) the signature and sends "ACK" with IP address 5.172.12.131
- A knows (remembers) that in order to access B A should send a packet to 3.172.12.131
A can not be sure that IP address 3.172.12.131 indeed belongs to B, because Rodi supports unidirectional proxying (aka bouncers). B can hide behind a bouncer with IP address 3.172.12.131. IP address of B is irrelevant in this situation. All packets from A go to B via bouncer, but B sends packets to A directly. That is, bouncer appears only in one direction - for control messages from A to B and upstream/downstream of the bouncer is rather low. B can require that packets from A arrive at at least two destinations in the range specified by B. For example, owner of B controls some other server and makes sure that A runs IP scan. In this situation A can not know which one of two IP addresses belongs to B. In a different situation, B can require DSA-512 signature and drop all packets arriving without a valid signature, or from unauthorized peers. B remains completely invisible to the whole world, even though B posted range IP address as part of range of IP addresses in public domain.
Rodi bouncer is a unique approach to the problem of performance of proxy servers. In the typical setup publisher controls (aka owns) the bouncer(s). Rodi bouncer can be bidirectional and unidirectional (see examples above). Bouncer willingly proxies the stream for the publisher.
