|
|
- Special attention is devoted to the search functionality. Search by file name and by file content is supported.
- Only one IP port is used by the system - to support working with NAT and reduce overhead related to open/close IP sockets,
sending keep alive for every one of them, etc. IP port can be changed on the fly to fight traffic analyzers like one from Lancope.
Publisher can specify range of IP Addresses and IP Ports to access the data. IP port can be, for example,
109-110 (POP), 137-139 (NETBIOS), 22 (SSH), 220 (IMAP), 443 (HTTPS), 706 (SILC), etc.
- Different encryption schemes are supported from trivial (long key and XOR) to strong encryption of the traffic. Search request, data
and message headers can be encrypted separately.
- URL based "get data" request is supported (optionally) to help friendly ISP to cache the data
- All connections are UDP (TCP session can be established to fake HTTP/Telnet/FTP packets)
- The system can work using dynamic IP addresses. No trackers - no single point of failure. Publisher, seeds, clients can have dynamic
IP addresses and even change them in time of data transaction. The only requirement is reasonably limited size of the IP address space
for the publisher(s).
- Torrent file (table of MD5s) is available "on demand" from publisher
- Code for client/tracker is designed for easy integration with existing applications. Two implementations will be
provided - in Java and C.
- The code will be small (less than 200K of binary) with special attention to the performance. Code can be used in
the future in the embedded devices and should not make any assumptions about services provided by the underlying OS besides
very basic - multitasking environment, signal or semaphore. Another possible application is plugins for Internet browsers
like Firefox. Client executable can be sent together with torrent file in some cases to avoid installation and avoid
using Java applets. It is very important to keep the code small and the code structure simple and easily portable to
different languages/platforms.
- Simple GUI will be provided as an example of using the library.
- The code will be platform independent (little endian/big endian issue)
- Used algorithms especially the ones related to message parsing and verifying should be HW friendly.
- Any node can be publisher, seed, client, crawler depending on the configuration
- Rare block first algorithm is used similar to BitTorrent
- System provides built in versioning support (change manager) - system stores deltas when a file changed for known file
types like DOC, PDF. Search engine looks in all stored versions of the file. Every word/document rating is calculated accordingly.
- Reasonable protection of anonymity for the participating nodes. Rodi will make use of bouncing of control messages
and conectionless underlying protocol - UDP.
- Native bridge HTTP/FTP and Rodi networks
- Chat rooms - one chat room assotiated with every torrent and one chat room associated with every node. TBD.
- The system provides easy to use API for plugin developers TBD
- Protocol is developed for reliable (low packet loss rates) and fat (1/4M) links with significant round trip
delays (300ms and more).
- How the application handles port scanning attacks TBD
- Prepareness for servicing so called Lambda-Grids. Lambda-Grid is and end-to-end network bandwidth that matches or exceeds
the data processing capabilities of attached systems.
|
|
