Rien que la bande passante, de recherche de fichier répliqué au peer passif (ie : derrière un firewall fermé ou sans nat de port) peux "tuer" un serveur 10Mbit avec 3000peer !!!
Maintenant pour bittorrent il n'y a pas de recherche de fichier, mais uniquement un envoi des couples ip+port et dans l'autre sens les stats d'upload du peer (et peut-être les hash dispo).
Mais si jamais il y a envoi des hash dispo ça pourrait "tuer" sous la charge de débit de réception (qui ne peux pas être limité !).
Donc sans regarder le code, je pense que les hash dispo ne sont pas envoyé au client.
Il faut éviter a TOUT prix les débit entre peer et tracker, tant au niveau nombre de paquet (faiblesse emule) et volume (recherche passive direct connect)
Vala, hésite pas a regarder le protocole.
En fait la raison est que moins tu gère de peer, moins la charge processeur est importante car les évènements pour chaque peer sont des tueurs de CPU :
- connexion-déconnexion (login+pass par ex, hash spécifique pour bt dans la ligne $_GET)
- timeout
- demande de source
- fin de dl
- etc...
Sans compter la consomation mémoire, car rien qu'une structure minable avec 3-4 fichiers en seed ça en bouffe, enfin pas pour un utilisateur, mais pour des milliers ça peux mettre a la rue un serveur...
Bref, bittorrent marche très bien car les transactions peer-traqueur sont limités (ce qui rend possible des torrents trackeless : réseau neural de peer)
Ok, je pensais que les clients envoyaient leur état sur l'avancement du fichier, vu qu'on savait deja qui était seed ou peer.
Après pour l'état d'avancement il est évident que les clients s'envoient mutuellement leur état d'avancement (chunk disponibles)
C'est ce qui permet l'existence de client bittorrent qui ne télécharge pas complètement les packs (évite les fichier sfv, nfo, md5 et sample inutiles car bittorrent peux lui-même obtenir les hash des chunk)
[^] # Re: Mon avis
Posté par Raphaël G. (site web personnel) . En réponse au journal Vive le libre ... en partage !. Évalué à 2.
Rien que la bande passante, de recherche de fichier répliqué au peer passif (ie : derrière un firewall fermé ou sans nat de port) peux "tuer" un serveur 10Mbit avec 3000peer !!!
Maintenant pour bittorrent il n'y a pas de recherche de fichier, mais uniquement un envoi des couples ip+port et dans l'autre sens les stats d'upload du peer (et peut-être les hash dispo).
Mais si jamais il y a envoi des hash dispo ça pourrait "tuer" sous la charge de débit de réception (qui ne peux pas être limité !).
Donc sans regarder le code, je pense que les hash dispo ne sont pas envoyé au client.
Il faut éviter a TOUT prix les débit entre peer et tracker, tant au niveau nombre de paquet (faiblesse emule) et volume (recherche passive direct connect)
Vala, hésite pas a regarder le protocole.
En fait la raison est que moins tu gère de peer, moins la charge processeur est importante car les évènements pour chaque peer sont des tueurs de CPU :
- connexion-déconnexion (login+pass par ex, hash spécifique pour bt dans la ligne $_GET)
- timeout
- demande de source
- fin de dl
- etc...
Sans compter la consomation mémoire, car rien qu'une structure minable avec 3-4 fichiers en seed ça en bouffe, enfin pas pour un utilisateur, mais pour des milliers ça peux mettre a la rue un serveur...
Bref, bittorrent marche très bien car les transactions peer-traqueur sont limités (ce qui rend possible des torrents trackeless : réseau neural de peer)
Ok, je pensais que les clients envoyaient leur état sur l'avancement du fichier, vu qu'on savait deja qui était seed ou peer.
Après pour l'état d'avancement il est évident que les clients s'envoient mutuellement leur état d'avancement (chunk disponibles)
C'est ce qui permet l'existence de client bittorrent qui ne télécharge pas complètement les packs (évite les fichier sfv, nfo, md5 et sample inutiles car bittorrent peux lui-même obtenir les hash des chunk)