Slashdot Mirror


Microsoft Wants P2P Avalanche to Crush BitTorrent

pacopico writes "Microsoft seems to think it can be the better Bittorrent. You know faster and more well-behaved. The Register has a story on the P2P work being done by Microsoft's researchers in the UK. Redmond reckons its "Avalanche" technology will be 20 to 30 percent faster than BitTorrent. It's meant for legal downloads only, of course."

2 of 545 comments (clear)

  1. Distributed PAR2 by Ececheira · · Score: 4, Informative

    The way the Register describes it, it appears that rather than sending out chunks of the actual file, it's sending out something similar to PAR chunks where once you have enough data, you can reconstruct the original file.

    Futher, with a few chunks, you can calculate new chunks to send over to others, that way more people have access to more of pieces of the file.

    Sounds interesting, I wonder if it'll be incorporated into the next version of BT.

    1. Re:Distributed PAR2 by ChadN · · Score: 4, Informative

      A simple example for those reading who don't understand, then some follow up comments:

      Say I have bits 'a' and 'b', that other people want.

      I could sent bit 'a', then bit 'b' to receiver FOO, who can pass them on to others. However, if I send bit 'a' first, and others want 'b', they have to wait.

      Now, instead of transmitting to FOO bit 'a' then bit 'b', I send to FOO ('a' XOR 'b') first, then either bit 'a' or bit 'b'. I'll end up sending FOO the same amount of information (assuming the order is specified in the protocol itself).

      BUT, and here's the cool part. If someone already has 'a', they can get ('a' XOR 'b') from you, and complete their set of data (bits 'a' and 'b'). Furthermore, if someone already has 'b', they also get ('a' XOR 'b') from you, and complete their set. So, by only downloading 1 bit, instead of 2, you can complete the set for others who already have one or the other bits.

      Now, in practice it'll get a lot more complicated, and the method presented in the paper is not exactly like I describe, but the idea is that you can send data to help people complete their data sets, even though you yourself do not yet have the actual uncomputed data. Instead, you have a computed function of the data, which others can use immediately, and from which you can reconstruct the actual data later when you have more information.

      The practical upshot is that the computed data is more valuable to other peers than the uncomputed data, as they may be able to use it to complete their data set, rather than wait for the remainder of the uncomputed data.

      So, in reference to your comments, it may not be so much more practical to any one receiver; they still need to wait for all the data, in either computed or uncomputed form. But, for the network as a whole, it means that each receiver has many more options from which to download and compute each chunk, and thus make available to others. It is not hard to imagine that this can benefit the overall throughput of the network (which the authors of the paper claim).

      --
      "It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward