"Crystalization" of the network and snubbing
- from http://larytet.sourceforge.net/btRatDesign.shtml#snubbing
... Every packet and every request has price because processing of
every request carry some costs in terms of upstream, downstream and
CPU consumption. There are two kinds of packets - packets which are
usefull for peer and packets which are not. Every peer collects and
keeps statistics for all other peers with how many usefull packets it
recieved and how many usefull packets it sent. Before processing next
request from a remote peer Rodi client checks the mark of the remote
peer and if it's too low drops the packet.
Mark is a function of number of usefull packets and not usefull
packets. There are different kinds of packets - packets which consume
bandwidth, packets which are costly for CPU, etc. Different kinds of
packets have different weight in the resulting mark
... Let's say that peer P1 has block m and does not have block n (m,
n), let's say also that peer P2 can be described by pair (n, m) - has
block n and does not have block m. It appears that if two such peers
find each other quickly and establish connection that would reduce
protocol overhead and improve overall performance of the network.
We call the process of establishing of such pairs - crystalization. In
the beginning we have liquid - chaotic movement of molecules. With
time peers learn maps of each other and connect to each other -
crystalization phase. Good cooperation algorithm tends to crystalize
the system in full - create one crystall where all peers are locked
and satisfied and do not attempt to establish new connections.
One of the proposed solutons of the problem that in the GET DATA ACK
status BUSY peer can add estimated time when the upstream is getting
Let's say that P1 sends GET DATA request for block n to P2. P2 can not
open upstream immediately because it busy serving other peers, but P2
wants to help P1, because P1 has a block which P2 does not - block m.
P2 wants to be cooperative. P2 estimates - best effort guess - for how
long time P1 should wait before it gets data from P2, sends the result
- time T1 in the GET DATA ACK message and puts P1 onto the waiting list.
P1 is connected to the network for some time already and can estimate
typical time which it takes to find a free uploader with requierd
blocks - time T2. P1 compares T1 and T2 and if the deal is good starts
timer. When the timer expires P1 sends new GET DATA request to P2 for
P2 keeps free upstream for the P1 for some limited and relatively
short time. If P1 fails to send packet P2 will use the upstream to
serve other peers.