The Turtle Router (referred to as TR) is designed for file multi-hop anonymous file transfer in a friend-to-friend network.
The turtle router basically monitors file hashes. It digs tunnels for this hash. When a tunnel is available, it provides a file source in the file transfer module for this hash. The TR then accepts file requests and data items, as well as file maps, chunk maps, etc. It interacts mainly with the file transfer multiplex (ft/ftdataplex.cc) and the file server (ft/ftdata.cc).
The turtle router is implemented as a service, named p3turtle. The retroshare interface accesses the internals of the turtle router through the rsTurtle interface (retroshare/rsturtle.h).
The p3turtle service does the following threaded activity: tunnel handling,
Turtle tunnels have a definite life time of 300 secs. Tunnel time stamps (updated by downward transfers) maintain live-status info. For hashes with no tunnels, new tries are sent every 10 sec. Tunnel attempts request cached for 30 sec at every peer. A tunnel cleaning campaign occurs every 20 sec, and removes inactive tunnels.
Tunnel digging is performed by broadcasting a tunnel request to all connected peers. A tunnel request contains a file hash, a request depth, and a randomly generated request id, and a half-tunnel id. When a request is received at a given peer, the request is cached to avoid duplicates, and forwarded to all other peers, if the request depth is lower than a built-in maximum depth (6 in the current implementation). The cache contains the request id and the peer from which the request was received. It does not contain the file hash.
At each node, a tunnel request will trigger a local search. If the search is successful, the request will not be forwarded. Instead, a tunnel completion item will be sent in return to the source of the request. The tunnel completion packet contains only the original request id and a tunnel id that is a hash between the destination peer id, the file hash and the tunnel request half-id. Doing so, the tunnel id enterely determined by the triple (file hash, source peer id, destination peer id).
The tunnel id is the result of a non symmetric hashing function, such that tunnels can occur both directions between too peers for the same hash without colliding.
The turtle router deals with the following packets (tabular?):
- search items: RsTurtleSearchRequestItem, RsTurtleSearchResultItem
- tunnel items: RsTurtleTunnelItem, RsTurtleTunnelOkItem
- generic items
Integration with RS file transfer
- only tunnel items and search results contain file hashes. Others don't, especially file transfer items.
- no global addressing
- share flags: RS_FILE_NETWORK_WIDE, RS_FILE_BROWSABLE
- packet priority
- each turtle tunnel is handled as a potential peer for providing file data.
- when the turtle router communicates data or data requests, it replaces the peer id by the tunnel id.
- ftServer sends data requests and data chunks to the turtle router when the peer id indicates so.
- the trafic doesn't need to be monitored, at each tunnel corresponds to exactly one starting peer.
- in these two functions, the request parameters should be examined to determine whather it's a distand peer or a friend. If distant, send the packet to the turtle router.
Transfer Rates Regulation
Transfer rates at intermediate peers could be regulated the following way:
- tunnel destination sends a max rate collection packet with its own max allowed rate back down the tunnel
- each peer in the tunnel min(.,.) sends his own max rate with the tunnel max rate
-> each peer at tunnel start knows the max allowed rate along the tunnel
- To write : how do we compute each peer's per-tunnel max rate
- data encryption
- tunnel info scrambling: ids, length
Extension to other services
- tunnel overlapping issues
private chat with distant --friend-- peers
- encryption issues
- the turtle router dialog (image): shows the cached tunnel/search requests, used tunnels, and monitored file hashes
- extension to other (cited above) services is not recommended