Protocole Bittorrent Peer Wire implémenté en Java

Question

J'ai quelques questions concernant le protocole Bittorrent Peer Wire. J'essaie de l'implémenter en Java avec cette spécification .

Dans la section Peer Wire Protocol, il est indiqué que tous les entiers sont des valeurs big endian de quatre octets. Autant que je sache java utilise big endian. Est-ce que cela signifie que si je veux envoyer un message d'étouffement

étranglement: < len = 0001 > < id = 0 >

Dois-je simplement écrire au sokcet 1 suivi de 0?

Quant à ma deuxième question. quand je demande un morceau, est-ce que je pense à plusieurs fichiers en un seul gros fichier continu? ou penser dans des fichiers individuels? parce que la longueur de la pièce ne s'aligne pas sur les fichiers, un index peut à la fois contenir la fin d'un fichier et le début d'un autre?

En ce qui concerne ma dernière question lorsque j'ouvre une connexion à l'homologue et envoie ma poignée de main, est-ce que je continue de demander des morceaux ou une requête, puis d'attendre un moment pour voir s'il va demander quelque chose de notre part? comment se passe la conversation? J'ai surtout fait de la programmation réseau de type http où je demande quelque chose en attente d'une réponse. mais si je continue à demander des pièces, comment vais-je envoyer des pièces?

Answer 1

Question 1

Si vous utilisez des méthodes simples, si vous utilisez des E / S basées sur le flux, utilisez DataInputStream et DataOutputStream lors de l'écriture de types primitifs ( octet , int , long , etc.:

):

Socket s; // assume this is already connected
DataOutputStream out = new DataOutputStream( s.getOutputStream );
out.writeByte( 1 );
out.writeInt( 0 );
out.flush(); // optional

Si vous utilisez des E / S non bloquantes (par exemple, des classes du package java.nio), utilisez ByteBuffer s:

Socket s; // assume this is already connected
SocketChannel = s.getChannel();
ByteBuffer buf = ByteBuffer.allocate(8); // two 4-byte integers
buf.put( 1 ).putInt( 0 );
buf.flip();
c.write( buf ); // assuming channel is writable :)

Chacune de ces méthodes s’occupe des problèmes de commande d’octets en votre nom.

Question 2

(Notez que vous transférez généralement des blocs , qui sont des fragments de morceaux, sur le fil. Je vais les masquer ici :))

Lors de l'envoi / de la réception de pièces, il est préférable de penser aux fichiers (ou aux fichiers) comme étant continus, comme vous l'avez dit. Le fichier .torrent contient des informations sur les limites de fichier, dans le dictionnaire d'informations. Dans la traitement multi-fichiers , chaque fichier a un chemin d'accès et une longueur; le la gestion de fichier unique a un nom et une longueur facultatifs. Étant donné que vous connaissez la taille, le nombre et la longueur totale du contenu (tous issus du fichier .torrent), vous pouvez placer les éléments & "Au bon endroit &"; comme vous les recevez.

Une chose simple à faire est de créer un fichier unique égal à la taille du torrent. Lorsque vous recevez un élément, écrivez-le avec le décalage d'octet approprié dans ce fichier unique (parfois appelé fichier & "; .Downloading &";). Par exemple, considérons un torrent composé de deux fichiers:

a/b/file1.txt [100 bytes]
a/b/file2.txt [200 bytes]

piece size (pz) = 50 bytes
total size (tz) = 100+200 = 300 bytes
number pieces (np) = 300/50 = 6
file = my_torrent.downloading

Supposons que nous numérotions des morceaux et des décalages d’octets en commençant par zéro. Disons que vous recevez tout le morceau 1. À quel décalage d'octets (début) est-il affecté dans my_torrent.downloading? Cela va à (1 * pz) = (1 * 50) = 50 . Où va la pièce 0? À (0 * pz) = (0 * 50) = 0 . Et ainsi de suite ...

Je parie que vous pouvez maintenant comprendre comment transformer ce fichier .downloading en & "vrai &"; contenu dans votre torrent.

Question 3

Lorsque vous participez à un essaim BitTorrent, vous téléchargez et téléchargez des éléments vers et depuis plusieurs pairs simultanément . Pensez à celui-là pendant une seconde. En même temps que vous demandez un morceau à un pair, un autre pair pourrait faire la même chose de votre part. Tout à fait différent de la sémantique de HTTP, comme vous l'avez déjà souligné. Donc, pour répondre directement à votre question, d’autres pairs vous demanderont les données qui les intéressent. :)

Juste pour vous assurer que, avant de demander une pièce à un homologue, assurez-vous qu’il en a une (consultez le bitfield et avez des messages ) et vous avez respecté le choking / intéressé comportement. Dans ce cas, vous souhaitez généralement demander des données à votre liste de pairs connus (dont le suivi ou DHT vous a parlé) dans l'ordre le plus rare en premier . La spécification en parle et il y a BEAUCOUP d'optimisations et de considérations de politesse ici. (Comportement particulier, par exemple.) Vous remarquerez peut-être que la spéc n'épelle pas un beaucoup de ceci dehors. En effet, une grande partie de la sauce secrète des clients BitTorrent réside dans cette partie de la mise en œuvre. :)

J'espère que cela vous aide!