I noticed that it probably depends (amongst others) much of the number of interested peers (and not really of their download capacity). Yes indeed uT has a weird algorithm for priorizing the seeding.
killing the torrent definitively.Ĭan someone shed some light on this mystery? As a result uT clearly shifts his bandwith priority to other tasks what can be very counter productive in this example e.g. no fully completed seed available anymore? Does this special situation negatively impact on the BT client "readiness" to share? I mean a seed is obviously seeding as much as possible but it clearly seems that a peer is only willing to share well if reciprocated (tid for tat) from time to time at least. Can it be a major problem if in a given swarm only peers are remaining e.g. So maybe the incompatibility between Xunlei clients and other major clients on "this side of the wall" is purely or mainly of technical nature?ĪDDENDUM: Oh, one more thing I forgot to mention. Disconnection and reconnection made my client to send him a chunk of pieces and then back to nothing, again and again. Recently I had a uT 1.8.2 client sharing very well with others but not willing to take a piece from me (being the only (inital) seed). Or may all this only be mainly imagination? Could it be that the chinese (virtual) wall be the real culprit? Maybe they can share well inside or outside but not accross?!?.Īnd on the technical level there are sometimes really weird things happening. Ok some proposed to accept only encrypted connections (if Xunlei really do not support encryption) but that would also cut off a part of other peers not willing to accept encrypted connections. So only a one by one IP selecting an entering in the ipfilter.dat would lead to a result (for those not changing the IP regularly). with uT not having a way to ban on a per client basis.
But even then it's practically a pain in the a. So what is the way to handle this problem?Ĭould be a solution if not all or the major part of the pieces would be "in the hands" of Xunlei peers. Whatever it is, the fact remains that if all the Xunlei client would only fully leech then this client would not be the most used in the world?!?. So of course the idea crossed my mind that they may (by design?) prefer to share with other Xunlei clients.
Some are sharing the way it should be in P2P BT.įinally there is another group of Xunlei clients which wont' give nor take, at least not with uT (or Tixati I also tried alternatively). On the other hand I observed that not ALL the Xunlei / Thunder peers are acting like that. In that case uT is again and again unchoking (randomly / optimistically) and sending MB of pieces to these leeches yet never getting anything worth to mention in exchange. I observed that they unchoke my client but they never send any block of the piece my client requests.
They remain (connected) in the swarm taking everything they can yet never giving a block back or maybe a block (16kb) every 2 hours. The recurring problem with these Xunlei / Thunder peers is that most of them just leech out and give back almost or simply plain nothing. Though many people on "this side of the wall" may think that only a marginal fraction of the BT users are using this weird (at least not natively available in English.) client in the world, uT having the Lion part, they are fully mistaken according to some statistics published not so long ago on TorrentFreaks. Recently I have been more involved in swarms with a lot of far east peers, most of them using the Xunlei 0.1 client.