Slashdot wrote:From ZDNet Blogs: 'Rodi is a small-client P2P application, written in Java, that improves on BitTorrent by allowing both content searches and full anonymity. It's released under the General Public License (GNU). Even your IP address can be hidden using Rodi through a process called "bouncing." That is, if A wants a file from B, they get C to agree to stand-in on the exchange. B gets C's IP address, not A's. Through IP Spoofing A can even hide their identity from C. Rodi can also be used from behind corporate firewalls and LANs using Network Address Translation (NATs), something most home gateways have.' "
Hmmm, interesting. More info here.Rodi or Rodia (Ρόδι or Ροδιά) means pomegranate in Greek. The Rodi program is a tiny P2P client/host (under 300K of binary code) implemented in pure Java. It's network use is similar to the bitTorrent concept. The program will serve the filesharing community with fast data delivery and serve the Open Source community by facilitating faster software deployment.
Data distribution networks today provide only search in the file names (if any) and no content search. They were originally created for delivery of binary or not searchable content. Rodi network functional requirements include context sensitive content search. Because Rodi is distributed network keyword rating and consequently search results can differ from publisher to publisher. One can view Rodi network as a group of loosely related or completely unrelated search engines. Publishers belonging to the same Rodi House can use the same function when calculating keywords rate.
Existing search engines do not provide search in the previous versions of the index files like HTML, but only in the cached and supposedly recent version of the file. We argue that content of the WEB is getting more and more dynamic and updated much more frequently than before. Rodi client functional requirements include file version manager. Rodi will support content search in the previous versions of the file as well as in the current one.
Security is a huge problem for the existing bitTorrent network. In most cases bitTorrent trackers accept any client, in some cases client must go through a registration procedure, ran by a regular WEB server, before the client gains access to the tracker. Part of the registration procedure is saving client IP address which is assumed to be unique. Many questions immmediately arise. It is not clear how the system can work if the client is protected by a PROXY server and real IP address is invisible for any 3rd party. Also what happens with dynamic IP addresses? How can the tracker assure that the current request is arrived from the client registered on the server and not from one with the same (faked?) IP address. How can the host make sure that request arrived from the authorized client? How can the client make sure that the host answering data request is authorized?
Traffic analyzers use some simple rules based on IP address and port number to collect the statistics or even drop the packets if ISP decides that the traffic is illegal or parasitic. In the more advanced analyzers "deep inspection of packets, including the identification of layer-7 patterns and sequences" is supported. P2P network can use some simple encoding algorithm, for example, XOR with long key. The strength of the scheme is regulated by the length of the key, frequent renewing and total number of keys. Let's assume that length of the key is 1M characters, there are 1M different keys - hosts generate different keys for the published files. At this point a reliable analyzer is expected to store and actively use about 1T characters of keys. Let's also suggest that keys are made accessible for registered clients using different protocols, like e-mail, FTP, HTTP, etc. Because normal high speed analyzer's are real-time embedded devices they can't reach the goal of collecting 1Tbytes of keys.
In case of DDOS the solution is to use a network of friendly bouncers behind different ISPs using different types of equipment. This way DDOS will require more resources from the adversary than when attacking a single host and the adversary can not attack the publisher directly because the source IP of the arriving packets can not be relied upon. It comes with relatively low bandwidth costs on part of the bouncers, because Rodi streams data directly between paricipating nodes and only Rodi control messages routed by the bouncres. Publishers are expected to spoof IP source or use dynamic and ever changing IP addresses and ports known only to the bouncers
Publisher can get authorised signature. Downloaders are expected to learn which publishers are reliable. Downloaders recognize the publishers by nicknames. Publisher generates a pair of SSH2 DSA keys. One key or private key, publisher stores locally and the second key or public key publisher has to post on the key server. Key server prompts publisher to enter unique nickname and public key. Key server checks that the nickname is unique on this server and makes the key and fingerprint of the key accessible for the public via regular WEB interface. Key server will not log IP address of the publisher or any other information besides nickname and public key. Optionally publisher can receive from the key server signature encrypted with private key of the key server. Key server signature contains nickname of the publisher, public key of the publisher and credentials of the server, for example URL. Publisher then can attach signature information element to every sent packet. Signature information element contains following parts
binary part with key server signature and MD5 of the packet
nickname of the publisher
URL of the key server (optional)
public key of the publisher (optional)
Binary payload is encrypted using private key of the publisher. Downloader is expected to decrypt the binary payload using public key found on the trusted key server and then decrypt key server signature using public key of the key server. Downloader makes sure that that the binary payload is indeed encrypted with publisher's private key and MD5 of the packet is correct.
Key server provides XML based interface to the database containing nicknames and public keys of the publishers. Rodi client can load the database and periodically check for updates.
Rodi Houses can run own key servers and provide to the publishers belonging to the house House Signature.
It can be argued that modern networks are reliable and require only a minimal set of flow control and retransmission features above the data link (UDP). There is no reason to send data over TCP if client is not going to use flow control of TCP. The TCP layer provides flow control, which ensures packet delivery but we contend that packet delivery is not an issue for the modern network. The real issue is delay and jitter, but not packet loss. Yet another reason for avoiding of TCP in file sharing application is limited window size in TCP layer when application can actually retransmit any block - the data is stored on the media supporting random access, like hard disk. TCP can not assume that sent by application block can be easily reproduced by the application. TCP keeps copy of every packet sent in so called retransmission window, attempt which is impossible even in theory for fat links with large round trip delays (RTT). Some flavor of streaming protocol is more suitable for file sharing application.
In the simplest scenario the host can use a best effort scheme when sending packets to the client with no timeout for acknowledgement. If client fails to receive a packet a new request can be issued at any time, assuming that said packet can be found on the host. Client can optionally specify in it's request to the host optimal burst size (window size), packet size, inter burst and inter packet delay. In the best scenario client will not issue any requests to the host beside initial request. Because UDP connection is stateless no time will be spent for establishing peer to peer connections.