[eMule-Web] - MUTE 0.5 in Entwicklung mit multisourcing

MUTE 0.5 in Entwicklung: mit multisourcing
http://cvs.sourceforge.net/viewcvs.p...xt?view=markup
http://www.northcountrynotes.org/jas...klog/index.php

Zitat:

Version ??? ???

--Fixed a minorGems SimpleVector compilation bug on newer versions of gcc.

--Upgraded to Crypto++ v5.2.1 (patched to work with GCC 4.0). MUTE should
now compile using GCC 4.0

--Changed name prefix of MUTE's special directores from MUTE_ to MUTE_INTERNAL_

--Added ROUTE_ONLY flag to certain message types (like file chunks) to ensure
that they are dropped if no route for them exists. This flag prevents these
message types from being used for route discovery (only small messages, like
file chunk requests, should be used for route discovery). This should
dramatically reduce traffic in the MUTE network.

--Added download queuing support.

--Fixed a bug in timeouts when requesting file chunks.

Zitat:

Mutli-Source Done Sunday, March 5, 2006 [12:47 pm]
The multi-source implementation for the next version of MUTE is now complete.

This is a round-robin style implementation intended primarily to spread the load of a download across multiple nodes (and also, in the case of MUTE, across multiple routes). The implementation detects the fastest sources for a given file and uses them more often, dynamically switching to other sources as response times change.

The goal, again, is to spread the load of your download out and place more load on the nodes that can best handle your request. This will result in better overall network scaling and generally faster downloads for everyone.

Also, this implementation ensures that a download will stay active, searching periodically for more sources, until it is complete (or canceled).

The goal is not to make your download as fast as possible at the expense of everyone else in the network. Your node still sends out one request at a time (per file that you are downloading) and waits for that chunk to come back before asking for the next chunk.

Also, some people have been asking about partial file sharing (in other words, sourcing chunks of a partial download for others before you have received the complete file). My multi-source implementation does not support this because it would require a complete overhaul of the MUTE file sharing protocol (there is nothing in the protocol to describe partial files).

There are a number of reasons why I don't plan on implmenting true "swarming" (where you download from several sources simultaneously) in MUTE:

1. It greatly increases the complexity of the software.

2. It places extra load on the netowork, which in the case of MUTE is a shared resource.

3. It may not speed downloads up in many cases (because multiple sources for a file may all be connected to you through one "bottleneck" intermidiary node anyway).

Swarming does make sense in a direct-connection network, because the primary bottle neck is the direct connection between you and a given source (in most cases, it is the upstream connection of the source that is the slowest point). Additional sources can be viewed as independent, at least in terms of bandwidth and bottlenecks.