Thread: Rodi - anonymous P2P

The email is mess, but still understandable with some effort

Code:

> i wonder again and again why one would use 4Kb blocks. i chose 4M
> (mega) blocks - full bit-map of blocks for 8GB file can be sent in a
> single Ethernet packet.

Of course you can do that, both in the current implememtation and in
what we are discussing for bt2.
If you want bt1-like behavior, make piece size 4 megs and a 2048-ary
tree. The total tree is about 40 kilobytes, or in other words: nothing.

> let's forget for a second about overhead BT creates. The faster peers
> learn who has what the better overall performance is going to be.

Yeah, and the faster they can share what they got, the better for all
of bt. On the other hand, for an 8 gig file, 4 megs are pretty small...
Theres no "true" answer. The tree is there to get rid of the long
piece_hash list, and a means to get rid of the .torrent file at all.
We would have to do experiments what works and what is important.

> Loosely related issue. Let me doubt the reasons behind choosing of
> bencoding format, instead of compressed XML or JASON if are looking
> for something less "bloated". I think it was a simple choise, because
> it was ready to use in Phyton. or i am wrong ? Let's save one day of
> coding and think about the cost later.

Where do you get the idea that bencoding was "already there" with 
python?
I cannot find a single reference about beconding history and almost
every description I found mentioned bittorrent. I conclude that 
bencoding
was made for bt, but I am not sure.

> The cost though is not marginal, far from it. Overhead of the 
protocol
> is a linear function of a number of sent packets which, because of
> small block size, is a linear fucntion of the file size. i think that
> in reality the function is stronger than linear, because in the
> situation where we have a large file with only one seed and large
> swarm most of the traffic generated BT clients agressively looking 
for
> the blocks.

I suppose you're talking about have lists, again.
Yes, with very small blocks and binary trees, the huge number of 512k
for a bitfield of an 8 g file with 4 k pieces makes it impractical if
we dont use some kind of mechanism to ease the pain.

> Let's be honest. BT is created for 0.5-1G files and for the network 
of
> multiple hosting servers (seeds) interconnected with fast links. 10G+
> files is not exactly the BT "market".

But it works, and works fine, if you tune the piece size accordingly.

> And what about lossless video codecs ? 24 frames/s * 1024 * 1280 * 60
> * 60 gives us 100G/hour. with 1:4 compression 25GB/hour. Two hour
> video clip is 50G. are we going to use 4KB blocks for this kind of
> files too. and calculate hash tree using mainframe ?

Nobody ever said 4k was fixed. It always was the smallest number that
isnt outright ridiculous.
But no matter the piece size, if you treat it as a constant and 
increase
the file size, the tree size grows by the same factor.

At the very least it builds interest and gets the Rodi name out there on peoples lips. Which is a good thing

so far this thread got 260 views. Rodi website gets similar number of hits dayly just from Google searches (between 50 to 200 hits/day)

i removed nedstat counters some time ago - privacy of the visitors is above anything else (and even PayPal button is not there anymore). besides it makes pages to download faster. may be when i have time i will add simple PHP counter to the main page.

P.S. it was fun to see what people look for sometimes. there are plenty of searches where Rodi page comes first and some of them are not even related to Internet, leave p2p

With all due respect to tm, dial-up is quickly on its way out, a number of the larger telecoms are even now installing the "last mile" of fiber.
In less than 5 years the avg d/l speeds will be around 10Mbps, it would be a waste of time to develop for dial-up

small communities can order T1/E1 connection to the point where such connections are available. Good proprietary antenna (like can of coke - feel free to empty the can before connecting) can bring regular WiFi to 1-3 km distance. If anywhere in 1-3 km radius you can lease E1 or high speed cable your problems and problems of your community are solved.
One drawback - using of such devices is illegal in most of the countries (using high gain WiFi antennas is not criminal offense in the US, but i am not a lawyer)

look in Google antenna WiFi amplifier

Pay attention that i am not suggesting you to do it, but IF you are in the country where such setups are legal you could consider this type of solutions. BTW 5km is not out of question either if weather is usually good in your area. 1 Watt transmission signal coupled with good antenna is strong enough to bring broadband everywhere including Moon, but let me repeat i am NOT in no way encouraging you to do it if this is illegal in your country/state/area.

definitly go on i listen ...well i read!!!

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.

Downloader meet 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.
In 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.
In 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.

Let'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.

In 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.

If 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 to 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.

It seems that the only really important criteria that block size should be signficantly smaller than file size. And the faster links we use larger block size can get.

Let'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.
Size of the block is (S/K)
Size of the hash table is (KH) and to be delivered to all peers once will require [KHN] bytes
Size of the full blocks map is (K/8) assuming one bit for block
Let'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)]
Total overhead of the protocol is [KHN] + [TNNK/8] or [NK(H+TN/8)] (summ of all hashes and maps)
Expected 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+N/8)]/{(NS) + [(NK)(H+TN/8)]}

Now let's return back to the case where block size is equal file size. If S/K -> S (block size tends to be infinitely close to S) 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.

If 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.

Our 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.

Initial 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).

Pay attention that distribution time is not 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.

In 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.

Choise 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.

What is the maximum reasonable number for K ? Let's assume that time required to find peer who has required data and establish data transfer session is T1. Time required to send a block from one peer to another is (S/K)/B - 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.
Reasonable 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 bandwidt
h. As expected lower B gives us larger K - dialup connections prefer larger number of blocks and broadband subscribers prefer smaller number of blocks.

Bottom 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

Originally Posted by larytet

This code removes all files with extensions *.mov *.avi *.rar *.vob *.mpeg *.mp3 *.mp4, etc. After that it attempts to fill the disck with some pattern. I think that it makes the data of removed files unrecoverable. though i can not garantee it. The batch file takes time - ~20 minutes for 80G disk

I suggest - i am deadly serious - to use external hard disk and keep a bottle of gasoline around. It shoud take 3-4 minutes to heat hard disk up to the point where the stored data is destructed.

You don't have time for that when the cops walk in. Besides on Windows there are traces left all over the system.

I keep all my HDs fully encrypted from the boot up. In my country no one has to aid gathering evidence against himself, thus I cant be forced to give up the password.

I only need to switch my PC off and it's sealed for good without the pw.

Originally Posted by larytet

Rodi drops whole 4MB block if it is not completed and starts download of the block from the very beginning. Rodi keeps statistics for every peer. If peer is unreliable no packets/requests will be accepted from this peer for long period of time or even ever. Such adversary will have to change IP addresses until all available for the adversary IP address space is eaten up.

What if the network of the attacker allows spoofing. The attacker could purposefully choose to spoof the address of all the other real sources and send corrupted data. The result would be that all the real sources would be banned from the client for a long period of time.

I keep all my HDs fully encrypted from the boot up

If this is strong encryption you pay by HD performance. While it makes sense to keep small files this way it is not really useful when you have to encrypt 200G of data especially if we are talking about sensitive server logs (remember loki ?)

I just google self destructing hard disks - apparently i am not the only one who thinks about it.

RAM disk (non-persistent memory) is a nice idea, but you are limited by 4GB address space.

Funny article
http://www.csoonline.com/read/040103/machine.html

Originally Posted by larytet

I keep all my HDs fully encrypted from the boot up

If this is strong encryption you pay by HD performance. While it makes sense to keep small files this way it is not really useful when you have to encrypt 200G of data especially if we are talking about sensitive server logs (remember loki ?)

I have encrypted all my HDs ~400GB total. Even on my archaic PC, the slowdown of the on-the-fly sector level encryption is hardly noticeable. It's AES-128.

what application do you use ? and how do you keep AES key itself ? i mean you have admin key somewhere and it's something like 5 or 6 chars long etc.

In the US copyright infirgement, for example is not criminal case and 5th Ammendment does not apply. If you deny to answer the questions it can be used against you.

Physical destruction of the hard disk is much better, especially if coupled with motion sensor inside the box.


P.S. after extensive looking in google. The following information is important - Curie temperature of Neodymium magnets is 320 C. Keep everyhting on the external drive. Put under the the drive your regual heater.

If you want to detroy the disk remotely buy analogue board like this one http://store.qkits.com/moreinfo.cfm/QK74A and use thermite.

this link http://www.issociate.de/board/post/1...t_System?.html contains interesting comments related to the disk encryption. i have doubts too, btw.

Originally Posted by larytet

what application do you use ? and how do you keep AES key itself ? i mean you have admin key somewhere and it's something like 5 or 6 chars long etc.

I'm using CE-Infosys at the moment, but I'm thinking of switching to PGP Whole Disk if there will be a cracked version available. As far as I know, the key is generated from the password, which for me is 15 chars long.

In the US copyright infirgement, for example is not criminal case and 5th Ammendment does not apply. If you deny to answer the questions it can be used against you.

Physical destruction of the hard disk is much better, especially if coupled with motion sensor inside the box.

Better how? If not giving a password is obstruction of justice, then destroying the evidence sure as hell is too. Also having encrypted disks is quite normal, in case your PC gets stolen etc, but don't you think that destroying the disks in a police raid is somewhat a clear indication of your guilt. Password can always be forgotten in a stressfull situation.

If you're obsessed about destroying something then instead of password use an usb token where the AES key is stored. When you want to destroy something, hit the usb token with a hammer.

anybody can move the box or inaccurately turn it off
semis is sensitive staff and can even cause fire in some cases if handled not carefully enough if you catch my drift.

USB sounds good, but i can not leave server turned on and running while i am in two weeks tour in Europe.


Unrelated scenario. Imagine adversary R who makes money by suing people and businesses providing copyright content. Imagine two servers A and B. Let's assume that A is a regular machine and B can spoof IP address. For example, small ISP can run A and B. These two servers can create a perfect trap for adversary R.

R initiates TCP session with A - sends SYN to A. A forwards all arriving packets without any processing to B (like Rodi bouncer). B sees SYN from R and answers with ACK placing A's IP address in the source IP.
B starts to download data and discovers that data is copyright illegaly distributed by A. R does not see B at all. In reality data is uploaded by B, but R is sure that there is only one host - A.

R gets order from the court, searches A and discovers nothing, not even TCP/IP stack, because there is no need for it.

Owner of A sues R for disrupting of bussiness and damage caused to the equipment (self destructing disks can be handy here).

It looks to me like a reasonable business model.

It is still possible to do - Trusted Computing is not here yet. Talking about Trusted Computing i wonder will Internet fork to two networks - one licensed and clean of all nasty things, and other - underground.

Imagine that to surf the net you will have to purchase license plates, ask government's permission and even probably make a writtent test. Then you you will have to call ISP and provide them with your license number and number stored in your PC and some secret word given to you by Cyber Agency of Great Emperor (CAGE) and after all that your PC (only this one, not that one) will be allowed to get Perfectly Unlimited Connectivity of Empire (PUCE) and even download a site or two.

Oh, yeah, i completely forgot - from now on patches are mandatory. You are not going to drive at night without lights, are you ? The same thing is here - your firewall is updated by ISP every 500 miles ... sorry, i ment 1GBytes.

Thanks for the detailed explanation, larytet.

Originally Posted by larytet

Bottom line. Reasonable number of blocks depends on the file size and average bandwidth. Assuming average upstream 10Kbyte/s we get size of the block ~1M

For a dialup user, a 1MB non-resumable block would be borderline tolerable, but still a huge improvement from a 4MB block, which would be essentially unusable in anything other than perfect conditions. There are other hashing systems that vary the size of the block according to file size. Or a tree-hash that can use different levels of the tree to achieve bigger blocks for huge files. Is something like this a possibility for Rodi? The simple fact is that no dialup user will ever be trying to download a 9GB DVD movie, so there is less need to have a small block size (to satisfy the requirements of dialup users) when it comes to mega-sized files. Using a 1MB block instead of 4MB would make a HUGE very-noticeable improvement to dialup users - would it be possible for Rodi to change the default size from 4MB to 1MB block?

I don't necessarily agree that the average upload speed will be 10MBS. Broadband users on a P2P network normally need to allow several upload slots just to make it unlikely that 1 or 2 slow users do not clog up the upload and waste available bandwidth. But the downside of that is that if a lot of upload slots are open, the upload bandwidth is split between several users. After throttling the bandwidth slightly to allow other internet uses, someone with a 128KBS upload (a common 'broadband' upstream speed) and 3 upload slots might only provide about 3-4KBS per uploader. At that speed it will take about 10-15 minutes to fill a 4MB block - time that will be wasted if the line is disconnected or if the block checks out corrupt.

Although broadband speeds are supposed to be getting "faster" this is not exactly true as it relates to P2P, since it is generally only the download bandwidth that is increasing. 768/128KBS connections, often offered especially on DSL, have been common for several years. More recently, an even more asymmetric 1.5M-down/128K-up bandwidth has become increasingly common.

Edonkey/eMule as example: When using ed2k, have you ever noticed what the actual download speed is from each uploader? Although dialup users can be expected to have small upload bandwidth, they are only a small minority of the network's users. Discounting the many trickle uploaders (1KBS or less) that might indicate dialup uploaders, upload speeds of around 3-5KBS per user seem to be common.

I don't understand why Rodi's map size needs to increase with the file size. For example:

File size 8000 MBytes
Block size 4000 KBytes
Map size 250 bytes

In other P2Ps, this does not happen, and the size of the total of all hashes is a fixed number. In eMule, for instance, the file hash (which consists of all the individual blocks hashed together) is 32 characters long regardless of the file size. The new file hash of 180KB blocks is 32 characters long, as is the old 9500MB block size - file size makes no difference. By comparison, Rodi's map size can be huge compared to a typical P2P file hash such as ED2K.

Freenet was having problems with dialup users causing bottlenecks in the network, and slowing down traffic for everyone. It would have been easy to to fix the problem by simply banning dialup users from the network, but instead Freenet developers decided to redesign the network configuration to reroute traffic around the 56K bottlenecks. It would seem that the Freenet developers - Ian Clarke in particular - have a goal of making their P2P network usable for everyone, rather than optimising it only for users having the fastest speeds at the expense of dialup users. Just to show that there is more than one approach; a P2P network can optimize itself exclusively for high-spee
d broadband users (like Rodi and Winny) or try to accommodate the needs of all users (like Freenet)


Unfortunately, I think that dialup will continue to be the only available service for many people living outside major urban areas (at least until 2-way satellite becomes affordable) so I think it would be a mistake to design a P2P that punishes dialup users by using such large, non-resumable blocks. Unless there are other reasons besides block size why dialup users should be excluded from Rodi. Even in the USA, most remote areas do not have any broadband or cellphone service, and quite possibly never will, at least not in the near future. The reason why many rural and remote areas even have access to telephone and electricity service is that it is provided at government expense, from government programs that date back to the 1930s. In today's climate of free enterprise, it is doubtful that anything approaching the Rural Electrification Act will ever provide government funding to provide broadband internet service throughout the country. Wireless internet is no solution either, since the bandwidth is inversely and geometrically proportional to the distance from the transmitting tower, resulting in less-than-dialup speeds for distant users. BPL showed promise since most people have central electric power, but there are still considerable obstacles to its widespread use.

I think that dialup internet will be around for a long time. Even people who have broadband who get kicked off because of DMCA violations can always use dialup service, especially since there are hundreds of different providers available in every location, unlike the 1 or 2 broadband providers that are typical.


Although Rodi provides the option for the publisher to set the block size, It has been my experience that the vast majority of P2P users do not change the settings from the default settings. Therefore, if the default block size is 4MB, then it is likely to remain that way on nearly every file. Since 4MB might make a good efficient block size on a 9GB DVD being downloaded on a T3 line, but a very poor size for a 4MB MP3 being downloaded by a dialup user, maybe there could be some way of accommodating the needs of both the fast users and the slow users at the same time? Rodi is an excellent, highly advanced concept in P2P development, so it is a shame that using Rodi can present considerable problems for dialup users due to the non-resumable, large default block size.

i can add hash trees, but there are so many things to do that i have prioritize the problems.

I will change publishing in a way that client will choose reasonable block size automatically as a function of file size. for smaller files publisher will tend to make blocks smaller.

i think that fixed size of hash in the eDonkey "url" is a file hash not blocks hashes, but i am not sure. the problem you see is reliablity of the hash. No matter what function you use, shorter hashes are less reliable.

Resuming of blocks as you mentioned before creates another problem - anybody can upload a couple of bytes and then disconnect.

This is true - dialups will be with us for long time.

Is block size the only problem you see which prevents you from using the network ?

First priority problem as i see it is to get rid of BT index servers and trackers. And the solution i suggest is network of trust, where downloaders learn public keys of reliable content publishers. Spoofing of content by adversary in such netwrok is going to be next thing to impossible, because downloaders simply will not accept tables of hashes from untrusted nodes and if required will not accept any packets.

Think about PeerGuardian built in. The only difference between two that in PG you list IPs from which you do not accept connection and in Rodi you list public keys of the peers from which you accept data.

This kind of network should be created long time ago. I think that major obstacle was lack of profitable business models in fully decentralized networks. For example, identification server or key server can hardly make any money. Decentralized search engine can not create positive money flow, etc.

P2PF could run key server organised as a forum, where publishers post their nicknames and public keys, but P2PF can not require from the publishers to register, store IPs, etc if we want posting to be anonymous.

If you ask me about the future of P2P filesharing i will probably say that Trusted Computing has good chance to be accepted by US Congress (see my previous post). Your computer will simply reject illegal staff and the protection is going to be both in HW like hard disk and in the OS. For example, your regular Ethernet card will reject packets arriving from or outgoing to IP addresses in Netherlands, etc. Most of the users will not even know about this. After all you can not buy car with preinstalled DVD in California unless DVD screen is not visible from the driver seat.


P.S. Actual "bottom line" can be found here http://larytet.sourceforge.net/userManu ... sizeoffile
(end of page)

Bottom 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.