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 in the past. Rodi's functional requirements include file version manager which will support content searchs for previous versions of the file as well as in the current one.\n\nIn the local networks typical enterprise search engine requires to share files and folders. Rodi search engine provides additional option - running daemon on the host. Daemon checks the access rights of the remote search engine and takes care of encryption. Rodi search engine allows to specify IP subnet(s) to scan and does not have to rely on exact IP addresses of the servers.\n\nData 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 un-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 the 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.\n\nSecurity is a huge problem for the existing network. Rodi has two answers for the problem. Publisher can hide behind bidirectional or unidirectional bouncer (aka Proxy) and spoof source IP address of the sent packets. Among additonal tools are DSA based authentication and end-to-end encryption. Using these options publisher can effectively hide IP address of the server and prevent some types of DDoS attacks\n\nRodi supports [[NAT|NAT Traversal]] penetration and works in firewalled environments actively avoiding traffic analyzers. Traffic analysers use some simple rules based on IP address and port number to collect the statistics or even drop the packets if ISP's decide that the traffic is illegal or parasitic. In the more advanced analysers "deep inspection of packets, including the identification of layer-7 patterns and sequences" is supported. Rodi client can use a simple encoding algorithm to encrypt the packet

[[Welcome]]\n[[About]]

Lesson 5.0 (Download+all things together)\n\nCreate temporary directory, for example in Windows, c:\stemp\sRodi, and two subfolders upload and download.\nRun command\n\nconf dld saveTo c:/temp/rodi/download\n\nYou 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:\stemp\sRodi\supload. Let' say that filename is example7.data.\nRun command\n\npublish file C:/temp/rodi/upload/example7.data\n\nYou published the file. It can take some time if the file is large - Rodi calculates file hashes.\nYou get output like this one\n\nFile published: C:/temp/rodi/upload/example7.data ↵\nSize=1,484,217bytes hash=E3BB0ECADF46161324817347B351D6A7\n\nRun command\n\nlook startHash 192.168.18.41 255.255.255.255 87 1 ↵\nE3BB0ECADF46161324817347B351D6A7 3\n\nwere 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)\nRun command\n\nlook res\n\nYou will get something like this\n\nId Size hash \n-------------------------------------------- ↵\n0 1484217 E3BB0ECADF46161324817347B351D6A7 \n\nAvail Name\n---------------------------------------\n100% C:/temp/rodi/upload/example7.data\n\nRun command\n\ndld start E3BB0ECADF46161324817347B351D6A7\n\nWait a moment - Rodi will report that download is completed\n\nDownload completed: c:\stemp\srodi\sdownload\sexample7.data\n\nand you will find exact copy of the file example7.data in the download folder\n\nQ. Does it mean that i can search and transfer files on my LAN?\n\nA. 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.\nIn 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.\n\nQ. Where do I check how much upstream/downstream is used?\n\nA.Try commands\n\n dbg tx\n dbg rx\n dld stat\n uld stat\n\nQ. Where do I configure max upstream to use, max number of upload session?\n\nA.Try commands\n\n conf uld connections?\n conf uld upstream?\n\nGeneral 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.\n\nQ. 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)\n\nA. 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,\n\n/look startFile ?\nHelp:startFile\nArgs: [words to search] [bandwidth Kbyte/s] [retrys]\nExample\nlinux.distro 1 3\nLook for words linux and/or distro, up to 1KByte/s,\nresend 3 times to not responding peers\n\npay attention to the line args (arguments). you can specify how much bandwidth you want to use in your Look.\n\nQ. How do I specify where to save downloaded data?\n\nA.Try commands\n\n conf dld saveTo?\n\nQ. I want to run some initialization script every time i start the applet/application\n\nA. 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\n\njava -jar rodi.jar ConfigurationScript file:///C:/temp/rodi/scripts/startup\n\nNo blanks in the file name are allowed. In case of applet running from HTML page add applet paramete, like this\n\n<param name = "ConfigurationScript"↵\nvalue = "http://larytet.sourceforge.net/scripts/example5">\n\nAmong useful CLI commands are nop (no operation) and pause (delay script by specified in milliseconds timeout)\nCommand script will run arbitrary script file after the application is up. See more examples of scripts.

Lesson 1.0\n\nDownload Rodi package (file Rodi.zip) from SourceForge\nUnzip file rodi.jar from the archive and copy it any place on your disk\nClick the file\nType ? and press [Enter]\nType debug and press [Enter]\nType dbg and press [Enter]\n\nQ. I downloaded the source code, all I got is a heap of classes ... can anyone explain how\nto use rodi to a layman ...\n\nA. If you do not want to compile Rodi you can download binary files from http://sourceforge.net/projects/rodi/.\n\nUnzip the archive and copy two JAR files in some directory, let's say \stemp\srodi 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\nIf you use Linux command\n\njava -jar rodiTimple.jar\n\nshould help and the same command can be executed from DOS command shell in Windows you can also try\n\njavaw -jar rodiTimple.jar \nstart javaw -jar rodiTimple.jar\n\nIf you are behind NAT/Firewall you should forward the port Rodi binds (screenshot)\n\nQ. I can't run this thing. When i click 'Try it' link nothing happens\n\nA. 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.\nTo 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.\n\nThere 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\n\nQ. I am running it under Linux and I get\n\n[justin@bream rodi]$ java -classpath . rodi.jar \nException in thread "main" java.lang.NoClassDefFoundError: rodi/jar\n\nIt might be my java setup, but other stuff works as far as\n\nA. Most likely the problem you have because you use\n\njava rodi.jar\ntry\n\njava -jar rodi.jar\ninstead, or\n\njavaw -jar rodi.jar\n\nSee also screenshots taken using Fedora 1, 2, 3\n\nQ. I am running on Linux and I get\n\nFailed to bind socket port 53\njava.net.BindException: Permission denied\n\nA. Try to change local port by using command line argument LocalPort followed by port number\n\njava -jar rodi.jar LocalPort 31100\n\n(screenshots: 1, 2)\n\nQ. What command line options are supported by rodi.jar ?\n\nA. LocalPort followed by number of IP port to specify port to bind.\nAWTConsole followed by flag true or false to use Rodi from SSH/Telnet/command shell\nConfigurationScript followed by path (URL/URI) to the initialization script\nExample: java -jar rodi.jar LocalPort 4500 AWTConsole false ConfigurationScript file:///home/rodi/rodiCore.script (screenshot)\n\nQ. Rodi fails with following error\n\njava.net.BindException: Address already in use: Cannot bind\n at java.net.PlainDatagramSocketImpl.bind(Native Method)\n at java.net.DatagramSocket.bind(Unknown Source)\nFailed to bind socket port 81\n\nA. 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\n\njava -jar rodi.jar LocalPort 31100\n\nto bind diffent (in this example 31100) port on your system.\nLesson 1.1\n\nInstall FireFox from http://www.getfirefox.com/ Read help for command script\nTry command script http://larytet.sourceforge.net/scripts/script_CLI\nOpen file http://larytet.sourceforge.net/scripts/script_CLI in your browser and read it.\n\nQ. May I use Rodi on my website to save upstream?\n\nA. 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)\n\nQ. I run Linux. I do not see any packets going out from the application. Command 'dbg tx' reports that all send attempts failed\n\nA. In progress\nLesson 1.2\n\nTry command help all.This command supported from version 0.0.2D. Try to download previous version of Rodi and execute the same command

Lesson 10.0 (General discussion of the technology)\n\nThis is mostly Q&A from message boards Slyck, P2P Forums, Omidyar Net, Methlab and others.\n\nQ. ... that (Rodi bouncing) would work, but wouldn't it be pretty slow?\n\nA. 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.\nExisting 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.\nThe 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.\nTCP layer is viewed by the application as totaly independent device and TCP is good in this - being independent device for reliable data transfer.\nThe trick in Rodi that data transfer is sent directly. It is only control packets go through proxy.\nRodi 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\n\nQ. ... how it could be used to get around censorship measures, especially those at the government ISP firewall?\n\nA. 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.\nRodi 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.\n\nQ. How Rodi key servers/crawlers/etc are different from servers in other networks?\n\nA. 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).\nIn 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.\nThere 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.\n\nQ. Would you make the crawler act like Distributed Hash table if so you will have a winner (AussieMatt)\n\nA. 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\n\n * HTML, PS, DOC, PDF and other text information\n * Meta data in audio and video files\n * Subtitles in video files\n * XML files (will require additional plugins) \n\nAgain crawler and for that matter any peer node can find all published files, not only linked files.\nThe 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.\nThe 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'.\nFrom 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).\n\nQ. Rodi - anonymous P2P (from P2PForums)\n\nA. 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.\nI 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.\nI truly believe that I have right answer to all this.\n\nQ. Size of block vs size of file\nI 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.\n\nA. 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.\n\nDownloader 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.\nIn 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.\nIn 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.\n\nLet'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.\n\nIn 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.\n\nIf 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.\n\nIt 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.\n\nLet'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.\nSize of the block is (S/K)\nSize of the hash table is (KH) and to be delivered to all peers once will require [KHN] bytes\nSize of the full blocks map is (K/8) assuming one bit for block\nLet'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)]\nTotal overhead of the protocol is [KHN] + [TNNK/8] or [NK(H+TN/8)] (summ of all hashes and maps)\nExpected 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)]}\n\nNow let's return back to the case where block size is equal file size.\n\nIf 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.\n\nIf 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.\n\nOur 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.\n\nInitial 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).\n\nPay 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.\n\nIn 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.\n\nChoise 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.\n\nWhat 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.\nReasonable 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.\n\nBottom 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.\n\nQ. Why not Mute?\n\nA. 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.\n\ni 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.\n\ndo 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.\n\nRodi 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.\n\nlet'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.\n\nThe same is in Rodi. Number of key pairs can be equal or even larger than number of peers.\n\nWhere 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.\n\nThe 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.\n\nMute 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.\n\nPrivacy 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.\n\nRodi 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.\n\nQ. ... my ... question is how different is Rodi from bittorrent ? .. I mean at the protocol concept level .. how it works etc.\n\nA. BT network is not searchable and relys on index servers. Rodi is a searchable network.\nBT is TCP based. Rodi is UDP based.\nBT 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.\nBT is not easily cacheable. ISP can not use existing HTTP cache proxys for caching BT traffic. Rodi functional requirements include URL based data requests.\nBT can not utilise multicast. UDP based Rodi can use multicast.\nBT uses bencoding to encode packets and "torrent" files. Rodi use XML for the files containing data hash and binary opcodes for the packets.\nBT 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.\nBT 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.\nExisting BT clients are heavy feature rich applications. Rodi has a separate light engine and GUI front end.\nBT has a single point of failure - BT tracker. Rodi is truly decentralized P2P network.\nBT 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.\nBT 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.\nBT 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.\nOn 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.\n\nQ. IP spoofing is the only reason behind Rodi?\n\nA. 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.\nI 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.\nNo P2P network today is truly searchable. You can search by filename, not by content. I want MSN or Google like search.\nI want to find MP3 by metadata INSIDE of the file. Filename is not interesting, i do not care about filenames.\nWhen 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.\nYou 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.\nNow 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.\n\nQ. 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?\n\nA. Default mode - IP address is visible\n\nDifferent 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.\n\nIn 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.\n\nThere are three ways to hide IP address in the Rodi network. All methods can be used together and separately.\n\n * hiding behind bouncer\n * spoofing IP source address\n * network of trust (l33t hubs) \n\nYou can find usefull hints on Wikipedia pages\n\nBouncers\n\nOn 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.\n\nBandwidth 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.\n\nPublisher 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.\n\nTo 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.\n\nRodi 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.\n\nBouncers 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.\n\nIP spoofing\n\nLet'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\n\nNow 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\n\nPerformance of the network is the same as in regular not protected P2P network.\n\nLet'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.\n\nBouncers and IP spoofing\n\nIn 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)\n\nPerformance 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.\n\nAdversary 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.\n\nPublisher 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.\n\nNetwork of trust or l33t hubs\n\nIf 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.\n\nAfter 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.\n\nAfter 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.\n\nWhen 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.\n\nPublisher 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.\n\nRodi uses one of the strongest signatures available today - DSA-1024\n\nAbility to spoof\n\nI'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.\n\nWhy Rodi ?\n\nRodi 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.\n\nRodi 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.\n\nLet'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.\n\nSmart 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.\nLet'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.\nIf 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.\n\nQ. I can't use IP address spoofing. Is there any other uses?\n\nA. 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.\n\nLet'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.\n\nQ. Please remove this feature [IP Spoofing] from your code.\n\nA. ...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.\n\nthink 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.\n\nLet's assume that you utilize Rodi bouncers to verify the packets from your subscribers before forwarding the packets to your server. Among your options:\n\n * use bouncers for upstream too (you can do it using regular Proxy)\n * broadcast/multicast/unicast data directly to the subscribers (and expose IP address and port)\n * spoof IP source address\n * spoof IP source port \n\nThe 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.

Lesson 3.0 (IP source spoofing)\n\nIn the HTML file starting the Rodi applet add something like this\n\n<param name = "LocalIP" value = "69.94.230.38">\n\nor 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\n\nnetsh interface ip add address\n"Local Area Connection" 69.94.230.38 255.255.255.0\n\nOn Linux\n\nifconfig eth0 69.94.230.38 netmask 255.255.255.0 broadcast 69.94.230.255\n\nIf DHSP is enabled on the interface "Local Area Connection", it will be disabled.\nRun Rodi applet.\n\nQ. I am behind NAT. What can I do?\n\nA. 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\n\n<param name = "LocalPort" value = "31211">\n\nto the HTML file starting the applet.\nAnother 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.\nI am not aware of existence of such application.\nImportant! 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\nClick print IP to find out your external IP address.\n\nQ. My ISP drops packets with faked IP sources\n\nA. 80% of connections have filtering. Some things to try are\n\n * use IP address belong to your subnet.\n * use multicast range of IPs.\n * use IP address belong to the subnet of your modem IP address \n\nIf 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.\nAlso 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\nLesson 3.1 (Firewall and NAT)\n\nThis lesson is for peers behind corporate or universitie's firewalls, NATs and traffic shapers.\n\nRodi 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.\n\nRodi 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.\n\nThe exact method to use to get through any specific firewall depends on the firewall software.\n\nCommand\n\nnat open\n\nstarts 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\n\nnat open 152.163.142.185 0 65535 10\n\ninitiates full port scan for the destination IP address 152.163.142.185.\nPort scan will use up to 10KBytes/s of upstream.\nThere are two different cases\n\n * 152.163.142.185 belongs to Rodi peer\n * 152.163.142.185 belongs to existing server \n\nIn the first case remote peer answers with packet containing your IP address and IP port how they look like from outside. NAT penetration reports that "penetration done" and displays IP address and IP port of the remote peer and your outside IP address and IP port. After that NAT penetration starts to "ping" remote peer to keep tunnel in the NAT alive.\n\nIn 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\n\nnat stop\n\nand restart NAT penetration again with exact port range. For example, assuming that response from the remote server comes from port 2233 execute command\n\nnat open 152.163.142.185 2233 2233 1\n\nFrom now on NAT penetration will constantly send packets to 152.163.142.185:2233 keeping tunnel in NAT alive.\n\nSize of the packets NAT penetration uses is under 32 bytes and overhead NAT creates is insignificant even for dialup connections.\n\nQ. (I) haven't close rodi-core since i got nat stat ...\nthis guy (remote peer) is offline now but nat stat still shows me that (the same) port and ip.\n\nA. 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.\nLesson 3.2 (Bouncer or how Rodi PROXY works)\n\nThere 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.\n\nIn the mode A bouncer simply forwards all incoming packet to the IP address(s) publisher specified.\n\nIn 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.\nPeer can run more than one bouncer. Every bouncer is assotiated with only one publisher.\n\nLet's configure bouncer. Command\n\nbouncer add 0.0.0.0 31100 61.1.12.1 12011 10\n\nbinds bouncer to the port 31100 on the local machine. Bouncer forwards all packets arriving to the port 31100 to the remote peer 61.1.12.1:12011. Bouncer uses up to 10KByte/s upstream.\nCommand\n\nbouncer list\n\ndisplays all running bouncers and traffic statistics\n\nQ. 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\n\nA. Freenet employs local data caches. it means that if you want to get something larger than\nX 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.\nOne problem remains - packet filtering. Really mighty adversary (think government) can decide to drop all Freenet packets.\n\nRodi 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.\n\nThink 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.\n\nThe 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.\n\nQ. 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?\n\nA. 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.\nFor 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

Lesson 6.0 (Timple - setup, initial connection)\n\nDownload binary files from http://sourceforge.net/projects/rodi/.\n\nUnzip the archive and copy two JAR files in some directory, let's say \stemp\srodi Run Timple (screenshot) - you can click rodiTimple.jar or runRodiWin32.bat if you use Windows. Or from command line\n\n\sj2sdk1.4.2_05\sbin\sjavaw -jar rodiTimple.jar\n\nTimple 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.\n\nIf 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.\n\nRun Rodi Core\n\n\sj2sdk1.4.2_05\sbin\sjavaw -jar rodi.jar\n\n(screenshot) - you can click rodi.jar if you use Windows. Rodi Core is ready for work.\n\nSet 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)\n\nClick button Log on the left - you will find combined log of Rodi Core and internal log of Timple (screenshot).\n\nQ. I couldn't get Timple to connect to Rodi core on local machine...\nit gets stuck on Attempting to connect\n\nA. 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\n\nconf key addPub rodiMng mng yourPublicKey\n\nThis command will register public key yourPublicKey and give the owner of the correspondent private key management (mng) access rights.\n\nQ. Where do i find my public key?\n\nA. Open file peers.trustees.script in any text editor. You will find line like this\n\nconf key addPub rodiMng mng 3081f03081a806072a8648ce380...\n\nLong hexadecimal string is your public key.\n\nQ. I don't like Java default look&feel and would prefer to see my system look&feel (Windows)\n\nA. Run Timple from command line using commands like\n\njava -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel↵\n-jar rodiTimple.jar\n\n(screenshot).\n\njava -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel↵\n-jar rodiTimple.jar\n\n(screenshot).\nFor example, on Windows you can create runTimple.bat containing line\n\nstart C:\sj2sdk1.4.2_05\sbin\sjavaw↵\n-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel↵\n-jar rodiTimple.jar\n\nIt works for all Java applications.\n\nQ. I managed to get it going, sort of. The only thing the rodi core outputs to me is this:\n\n java.security.SignatureException: invalid signature: out of range values\n at sun.security.provider.DSA.engineVerify(Unknown Source)\n at sun.security.provider.DSA.engineVerify(Unknown Source)\n ........................................................\n\nA. Close Rodi Core, delete rodiMng.keystore and rodiCore.script files, run Setup Wizard again.\n\nThis bug is in progress.\n\nQ. How do i reach the web-core (RodiCore applet) working together with the web-GUI (RodiTimple applet)?\n\nA. 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.\nLesson 6.1 (Timple - publishing)\n\nClick button Publish on the left panel (screenshot). In the table you see list of published files includig files you are uploading.\n\nClick 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.\n\nAdvertise your IP range, IP port and public key on some forum or here\nLesson 6.2 (Timple - IP hosts)\n\nBefore you can start your first search add at least one host to the table of Hosts (screenshot). Fill the fields at the bottom of the screen and click Add.\nYou can find hosts IP ranges on the Rodi related forums or on the Post IP page\n\nAdd 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.\n\nQ. 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 24.86.73.48 255.255.255.192 31213'\n\nA. 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.\nAfter 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.\nLesson 6.3 (Timple - Look)\n\nLet's search the network. Click Look on the left (screenshot). Fill in file name or file hash you are going to search, set bandwidth to be used by the client for search (Kbytes/s) and number of retrys to send to non-responding peers. Search results will appear in the table and in the log window (screenshot).\nLesson 6.4 (Timple - Download)\n\nAfter you found a file choose the file you want to download (screenshot) and click button Download under the table. Click Download label on the left (screenshot) to see the status of running download sessions.

[[Rodi Website|RODI]]\n[[About]]\n[[First Step]]\n[[Search]]\n[[IP Source Spoof]]\n[[Publish File]]\n[[Download]]\n[[Introduction/GUI]]\n[[NAT Traversal]]\n[[General Q&A]]

Lesson 7.0\n\nYou will need some network background here. NAT traversal in Rodi contains two parts or steps - NAT type discovery and keeping hole in the NAT.\nThe goal of the NAT discovery is to figure out type of the NAT in the network. NAT discovery procedure requires two or more Rodi NAT traversal servers with known IP addresses and IP ports. To get reliable results you need at least three distinct servers with different IP addresses and IP ports. Preferably servers serviced by different ISPs (TBD link to list of the NAT traversal servers here)\n\nnat discovery start 53.41.12.192 31212 81.19.240.171 31222 localhost 31212\n\nwill 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.\nWhen 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.\nAfter NAT discovery is completed your client learns type of the NAT in your network.\nThe second step is required only for the clients behind symmetric and restricted NATs. In the latest versions of the software this step is done automatically by the NAT discovery state machine. Client sends PING periodically to one of the reliable NAT traversal servers\n\nnat open 53.41.12.192 31212 31212 1\n\nClient sends PING requests frequently enough to keep the tunnel in the NAT opened.\nThis 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.\nClients behind restricted NATs advertise their NAT type and IP address of the server they are connected to.\nA 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.

Lesson 4.0 (Publishing)\n\nTry commands\n\npublish file?\npublish url?\nscript http://larytet.sourceforge.net/scripts/example5\n\nOpen file http://larytet.sourceforge.net/scripts/example5 and read it.\n\nQ. May I publish files from FTP server running in my LAN?\n\nA. 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.\nFor example,\n\npublish url↵\nhttp://www.digitaldistribution.com/samples/openofficeintro11en.swf\n\nwill create bridge between HTTP server and Rodi network.\n\nQ. May I publish files if I am behind NAT?\n\nA. 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.\nYou can also try to use command\n\nnat open\n\nYou 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.\nLesson 4.1\n\nWarning! Following example will attempt to create file example7.rodi in the local file system.\nRun command\n\nscript http://larytet.sourceforge.net/scripts/example7\n\nOpen file http://larytet.sourceforge.net/scripts/example7 and read it. Previous command creates file conatining something like this\n\n<?xml version='1.0' encoding='utf-8'?>\n<!DOCTYPE rodiFile [\n <!ELEMENT rodiHash (file, blocks)>\n <!ATTLIST file name CDATA #REQUIRED>\n <!ATTLIST file size CDATA #REQUIRED>\n <!ATTLIST file blockSize CDATA #REQUIRED>\n <!ATTLIST file blocksNumber CDATA #REQUIRED>\n <!ATTLIST file md5 CDATA #REQUIRED>\n <!ELEMENT blocks (md5+)>\n <!ELEMENT MD5 (#CDATA)>\n]>\n\n<rodiHash>\n <file name="C:\srodi\suld\srodi_0.3.04.zip"\n size="566944" blockSize="4194304" blocksNumber="1" \n md5="56675f2303d5087e80f3aea757a37d45">\n <blocks>\n <md5>56675f2303d5087e80f3aea757a37d45</md5>\n </blocks>\n </file>\n</rodiHash>\n\nRodi Hash XML\n\nQ. I am a publisher. How may I use rodi files?\n\nA. 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.\nLesson 4.2 (public/private key, IP range posting)\n\nCommand conf key genPair generates a pair of keys - public and private. The command adds private key to the virtual data base of the private keys and displays encoded public key.\n\nCommand conf key save saves virtual data base containing private keys into the specified file. Keystore is encrypted.\n\nCommand conf key load loads data base of private keys from the specified file.\n\nCommand conf key signBy tells packet builder to sign outgoing packets with specifed by key alias private key. All outgoing packets are signed besides data transfer packets. In case of data transfer data integrity is checked using per block data hash.\n\nCommand conf key addPub adds new public key to the database of public keys. Public key can be trusted or not trusted. Currently supported are\n\n * pub - trusted publisher\n * mng - trusted manager (for example, Graphic User Interface) \n\nQ. How can I publish my public key anonymously?\n\nA. 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/)\n\nQ. What are these keys about in layman's terms?\n\nA. 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.\nNow 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\n\nQ. What if the key server is compromised?\n\nA. 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.\n\nQ. How I know that the key server is not compromised?\n\nA. Check your nickname and public key from time to time.\n\nQ. I see that I have to post IP address. Isnt't it dangerous?\n\nA. 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.\n\nQ. 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?\n\nA. 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.\nPort 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.\n\nQ. Why subscribers should beleive that behind nickname hides trusted publisher?\n\nA. 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.\n\nQ. I am a publisher and want to create close group of trusted users. How can i accomplish that?\n\nA.The steps to do are:\n\n * Generate a pair of keys for every user of your network\n * Send private keys to the owners\n * Make all public keys available from some website\n * Add public keys to the Rodi database of the public keys\n * Ask user to add all public keys\n * Configure Rodi to drop not signed packets (Not implemented, In progress) \n\nLesson 4.3 (Chat + more security examples)\n\nTo send a message to peer, use CLI (Command Line Interface) command "chat send". For example\n\nchat send 66.12.1.1 12011 hello, world\n\nsends message "hello, world" to peer with IP address 66.12.1.1, port 12011.\nIf you got a message from peer 66.12.1.1 it will look like\n\nApr 6, 2005 6:59:02 PM /66.12.1.1:12011():hello, world\n\nNotice that neither you nor the peer you are talking with (66.12.1.1) acknowldege any message. The only way you can let 66.12.1.1 know that you got a message is to reply with, for example\n\nchat send 66.12.1.1 12011 hello back, 66.12.1.1\n\nThere are two ways to make acknowledge automatic. You can add public key of the peer found at PostIP page behind 66.12.1.1, like\n\nconf key addPub rodiMng pub 308201b73082012c060...\n\nwhere 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,\n\nchat session add 66.12.1.1 12011 SessionName,\n\nwhere SessionName is arbitrary nickname or alias (you name them whatever). Now your Rodi automatically sends acknowledge messages to 66.12.1.1. This way you know if the message was received or not.\n\nLet'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.\n\nCommand\n\nconf key load rodiMng.keystore rodiMng\n\ntells Rodi to load private keys from file rodiMng.keystore\n\nCommand\n\nconf key signby rodiMng rodiMng\n\ntells Rodi to sign outgoing packets using your private key - key with alias rodiMng.\n\nWhen you send signed packet, 66.12.1.1 recognizes that the message is signed and attempts to verify the signature. If 66.12.1.1 knows your public key the signature is going to be verified and 66.12.1.1 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.\n\nIf you have alias or name ('killjoy' for example) for the session you can use shortcut command 'c SessionName message' For example\n\nc killjoy whats up?\n\nQ. Is there a GUI tool to manage keystore file?\n\nA. See open source project Portecle (sourceforge.net)\n\nQ. Any shortcuts to send chat messages?\n\nA. 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

http://rodi.sf.net

Lesson 2.0\n\nTry command look start?\n\nQ. Performance of LOOK is low. When i specify 200Kbyte/s the applet uses only 20-30K\nand CPU utilization is 100%. When i make the mask smaller (small IP range) the problem disappears.\n\nA. 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.\n\nQ. I see many entries in the ARP table, CPU utilization is 100% and packet rate is less\nthan 30K/s\n\nA. 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.\n\nQ. The applet works but i am not able to fill my upstream\n\nA. 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.\n\nQ. May I run search on my own disk?\n\nA. JRun 'look start' command using your IP address,\nfor example 127.0.0.1 and mask 255.255.255.255\nCurrent version supports only search by file name, in the future search by content will be provided\n\nQ. The applet works but i do not see any outgoing packets - i work with Windows XP SP2\n\nA. Using command\n\nipconfig\n\nfind 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,\n\n<param name = "LocalIP" value = "192.168.18.1

Java Based UDP File Swarming

RODI

The Rodi program is a tiny P2P client/host (under 300K of binary code) implemented in pure Java. The program is an open source alternative of commercial search engines targeting enterprise networks.