Loading ...
Sorry, an error occurred while loading the content.

"Crystalization" of the network and snubbing

Expand Messages
  • larytet
    from http://larytet.sourceforge.net/btRatDesign.shtml#snubbing Snubbing ... Every packet and every request has price because processing of every request carry
    Message 1 of 1 , Mar 2, 2005
    • 0 Attachment
      from http://larytet.sourceforge.net/btRatDesign.shtml#snubbing

      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

      Crystalization
      ... 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
      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
      - 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
      block n.

      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.