Arkady
2005-03-02 18:44:01 UTC
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 overhead and improve overall performance of the
network.
We call the process of establishing of such pairs -
crystalization. In the beginning we see 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 srystalize 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 free. 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 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 free uploader with
requierd blocks. P1 compares the timeout specified by
P2 with the estimated and if the deal is good starts
timer. When the timer expires P1 trys to send new GET
DATA request to P2.
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.
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/
<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
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 overhead and improve overall performance of the
network.
We call the process of establishing of such pairs -
crystalization. In the beginning we see 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 srystalize 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 free. 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 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 free uploader with
requierd blocks. P1 compares the timeout specified by
P2 with the estimated and if the deal is good starts
timer. When the timer expires P1 trys to send new GET
DATA request to P2.
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.
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/
<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/