Implementazione bittorrent in java && necessitano di alcune informazioni sul comportamento dello sciame

Question

Sto sviluppando un client bitTorrent in Java. So che ci sono molte librerie là fuori, online, ma non posso farci niente; Voglio il mio. Ad ogni modo, ho notato alcuni comportamenti strani e forse voi ragazzi sanno qualcosa che mi manca:

• Circa l'80% di sconto su tutti i coetanei che sto cercando di connettersi a provocare le connessioni senza successo (sia socketTimeOut o "non può collegare "errori"). Ovviamente, l'elenco dei peer è ricevuto dai tracker. Ho anche testato casualmente alcuni IP cercando di eseguirne il ping; il ping è di solito successo.
• quando faccio Connect: connessione goccia
  • 50% dopo stretta di mano,
  • il 30% ho notato un comportamento strano: ricevo Stretta di mano, ricevo campo di bit (hanno tutti i pezzi), vengo bombardato da + 20 Avere messaggi (ho controllato l'indice del pezzo che hanno già menzionato in BitField), quindi rilasciano la connessione, il che è strano.

(per tutte le statistiche, le cifre non sono precise.)

Alcune domande di BitTorrent:

UPDATE # 4: im tagliare alcune domande a causa di considerando risposta trovato

• questa era la '80% non riuscita della domanda di connessione': Quale potrebbe essere la ragione per cui il mio 80% non è riuscito a collegare la velocità? Questo non può essere sfortuna, nel senso che ogni cliente che ho provato a collegare non ha più spazio per me. Sto ascoltando 6881, ma ho anche provato con altre porte. Ieri ho avuto un grande successo, un mucchio di connessioni accettate (lo stesso codice, alcune modifiche nella settimana passata), i messaggi di Piece hanno iniziato a scorrere ... quindi il mio codice non è totalmente inutile.

• fare client torrent inviare, prima della chiusura, un ultimo messaggio all'inseguitore con event=stopped per renderlo aggiornare il suo database interno con informazioni tra pari in modo che non invierà, come risposta, una lista con informazioni inutili tra pari? O semplicemente dovrebbero ... perché sembra davvero che sto ricevendo coetanei morti.

• L'ordine dei peer ricevuti di qualsiasi importanza? Forse percentuale di completamento .. o davvero casuale.
• Inoltre, ogni tanto ricevo un peer con la porta 0, che fa sì che il costruttore Socket generi un'eccezione. Cosa significa port 0? Posso contattarlo su qualsiasi porto?
• Può il mio PeerId (che invio Handshake o annunciare me stesso al tracker) influenza se i client torrent che provo a comunicare continueranno una connessione avviata? Cosa significa se menti e dico che sono un cliente Azureus usando '-AZ2060-' come mio ID?
• questa era la 'domanda di disponibilità scaring off peers': La disponibilità del mio pezzo spaventa i colleghi? Sto provando a connettermi e invio un bitfield vuoto (non ho pezzi, [length: 1][Id = 5][payload: {}]); sembra che mandino bitfield, io mando bitfield .. (alcuni mandano come matti hanno messaggi), si rendono conto che sono povero, mi lasciano cadere .. qualche goccia di connessione dopo la stretta di mano. (Quanto scortese.)
• C'è un vantaggio di non utilizzare il classico intervallo di porta: 6881 - 6889?
• questa era la "lista di domande negative": I client torrent mantengono internamente un elenco di peer non validi (come una lista nera)? A volte, dopo aver trovato un buon peer, ho continuamente usato le sue informazioni nei miei test ma solo una connessione 1/3 è stata accettata. A volte dovevano passare 10 minuti per avere di nuovo una connessione di successo.

UPDATE # 1: sembra che le connessioni con i clienti μ Torrent si comportano nello schema di cui sopra (campo di bit, AVERE bombardamento, stretta connessione). Ho provato localmente con un gruppo di client bitTorrent (μ Torrent, BitTorrent, Vuze, BitCommet, Deluge) e ho notato questo modello solo sul Torrent μ. Sugli altri, la comunicazione andava bene (HS, BITFIELD, UNCHOCE & condivisione felice dei pezzi). Ora, questo μ Torrent è probabilmente il client bitTorrent più popuaro (6/8 connessioni avviate erano μ Torrent), quindi & hellip; qualche idea?

UPDATE # 2: In termini di mantenimento di uno "bad list," sembra così (e in realtà ha senso farlo). Ad esempio, con μ Torrent, ho notato i seguenti intervalli di non collegamento (30s, 1min, 1min30s, 2min ..). Con "no-connect" in media, dopo la precedente connessione terminata, per x secondi non è stata accettata alcuna nuova connessione.

UPDATE # 3: che hanno un messaggio bombardamento potrebbe essere stato il cosiddetto "campo di bit pigro" (ha fatto un paio di test, ogni pezzo di cui HAVE non era presente nel campo di bit). Vedo che μ Torrent e BitTorrent utilizzano questo approccio.

Un'altra conclusione: alcuni client sono più restrittivi in ​​termini di rispetto delle specifiche BitTorrent e chiudono la connessione se si interrompe una regola. Es: Ho notato con BitTorrent e BitTornado che se si invia un messaggio bitfield ma non ci sono pezzi che chiudono la connessione (nessun pezzo = campo bit vuoto .. ma le specifiche dicono "È opzionale, e non è necessario che venga inviato se un client ha no pieces "), mentre altri chiudono la connessione se invii un qualunque tipo di messaggio prima che inviino un messaggio UNCHOKE (anche non INTERESSATO).

UPDATE # 4: Dal im per lo più interessati a prima domanda (Quale potrebbe essere la ragione del mio 80% è riuscito a connettersi tasso .. le domande striked sono più che probabilmente è piaciuto?), Qui ci sono alcune spiegazioni del perché a volte le connessioni non hanno avuto successo:

1) se avvio una connessione con peer poco dopo aver interrotto una connessione precedente (tramite stop - intendo socket chiuso): il peer sull'altro lato non saprà fino alla successiva lettura/scrittura.

Dettagli: - Ho notato che questo un mucchio di volte, questo è più evidente dopo aver terminato il download .. se chiudo connessione peer solito realizzare questo fino a quando non tenta di inviare un nuovo KEEP_ALIVE (~ 2 minuti). Ma se chiudo mentre sono in uno scambio REQUEST-PIECE, il peer realizzerà velocemente una preety .. Nel primo scenario dopo la chiusura della connessione, sono ancora presente nella scheda peer di uTorrent. Se guardo all'interno della scheda del logger, dopo circa 2 minuti, realizzerò che sono sparito.

2) sembra che uTorrent vede il mio messaggio bitfield danneggiato (& ovvia dovrebbe chiudere la connessione dopo receving esso) (questo non accade allways .. anche ho controllato & ricontrollato, MSG è OK & con altri client BT non esistevano i problemi)..

Dettagli: - se guardo dentro scheda logger uTorrent, viene visualizzato "Disconnected: Bad pacchetto" subito dopo che trasmetto bitfield - Sto pensando di provare un'implementazione di bitfield lazzy, forse posso sfuggire a questa (anche vedo che la maggior parte dei client BT fa questo)

3) (più che probabilmente collegato al # 1) quando uTorrent non mi consente di riconnettersi, vedo nella scheda logger: "Disconnetti: hanno già la connessione uguale (lasciato connessione extra) ".. Attualmente scelgo una porta locale casuale quando si entra in una nuova connessione (visto che è stata implementata nella maggior parte dei client BT), ma questo non la ingegna, lo vede ancora un peer già presente nella sua" peer list " (probabilmente ip match) .. Buuut: nel 30% dei test, sa me scenario, mi permette di ricollegare :) .. non ho ancora spiegazioni perché

4) un'altra cosa: sembra che l''ascoltatore per connessioni in entrata' sia ancora vivo dopo aver chiuso un torrente in uTorrent (da vicino intendo: tasto destro + stop). Questo significa che posso ancora avviare una connessione, inviare HANDSHAKE .. dopo questo, sono disconnesso (non torna indietro HANDSHAKE). Messaggio in uTorrent logger: "Disconnect: No such torrent: 80FF40A75A3B907C0869B798781D97938CE146AE", questa lunga stringa è il mio hash delle informazioni .. visto questo durante il test con altri client BT.

qualche informazione in più:

• scenari con uTorrent di tipo full-upload/parziale-upload-download & pieno sono di successo, quelli di parziale di download non tanto .. probabilmente a causa di # 2
• ho ancora ottenere con uTorrent che bitfield + hanno bombardamento + vicino connessione .. come ho e ricordate stesso msg in scheda logger "Disconnected: Bad pacchetto" .. probabilmente dovuto al # 2
• oltre uTorrent, Ive testati con : Po Torrent, BitTornado, BitCommet, qBitTorrent, FlashGet (la comunicazione era OK) & con Vuze, FrostWire, Shareaza (con questi ragazzi, era super OK).
• non tutti i client si comportano allo stesso modo. Es: FlashGet & uTorrent (& BitCommet?) non deselezionare finché non si invia INTERESSATO .. ​​mentre altri sembrano deselezionare a destra dopo BITFIELD .. in questo senso sto progettando in qualche modo di trattare i clienti in modo diverso (penso davvero che sia necessario) .. intuire il nome dal campo di bit (ci sono solo 2 le convenzioni di denominazione) & inizio da lì .. Ho già qualcosa implementato, questo è come so che ho collegato a cliente di tipo uTorrent ..

Answer 1

Ok , Ho una risposta per te ma devo avvertirti che non ho mai scritto un client bit-torrent e alcune risposte potrebbero non essere accurate al 100%, tutto ciò che ho scritto è dalla mia comprensione del globale vista di come funziona il bit-torrent. Quindi mi scuso se ho sprecato il tuo tempo, ma continuo a pensare che potresti conoscere il nocciolo di ciò che stai chiedendo dalla mia risposta.

• Quale potrebbe essere la ragione per cui il mio 80% non è riuscito a collegare la velocità?

Molto complicato da spiegare in una spiegazione lineare, ma: - bit torrent ideologia è tit-4-tat .. se non stai dando/dover tit non si è trovato tat .. MENO hai appena iniziato per scaricare e in tal caso si potrebbe ottenere una "donazione" per iniziare con ... O l'altro lato è una macchina di semina dedicata .. in tal caso potrebbe controllare se sei un donatore o solo un acquirente ... O molti attualmente stanno scaricando questo ...OPPURE (riempi la tua idea ..) Quindi, vedi che ci sono molti, e in realtà meccanismi molto intelligenti per assicurarsi che lo sciame possa essere agile ed efficiente e mentre alcuni di essi possono essere ricondotti alla tua macchina, la maggior parte di loro non può essere davvero anche monitorato dal tuo computer almeno per dire sotto il suo controllo.

• I client torrent inviano, prima di chiudere, un ultimo messaggio al tracker con event = stopped per aggiornare il suo database interno con informazioni peer in modo che non invii, come risposta, un elenco con informazioni peer inutili ? O semplicemente dovrebbero ... perché sembra davvero che sto ricevendo coetanei morti.

• Dipende dal codice del client - qualcuno potrebbe fare che alcuni non .. (Continua a leggere)

• è l'ordine di coetanei ricevute di qualche importanza? Forse percentuale di completamento .. o davvero casuale.

• Dipende dal codice del server - alcuni potrebbero fare che alcuni non .. (continua a leggere)

Va bene, Nota per quei due (continua a leggere) Note .. Si dovrebbe tenere a mente che in una rete P2P non esiste l'autorità per legare strettamente i client o anche i server per mantenere il protocollo alla lettera, anche se il protocollo indica qualcosa che dovrebbe essere fatto - non significa che ogni cliente lo implementerà o agirà allo stesso modo su di esso o quando manca.

• Inoltre, ogni tanto ricevo un peer con porta 0, che fa sì che il costruttore Socket generi un'eccezione. Cosa significa port 0? Posso contattarlo su qualsiasi porto?

• La porta 0 è una sorta di carattere jolly, se ci si connette a essa - si collegherà automaticamente alla successiva porta disponibile. (Alcuni dicono porta disponibile successiva sopra 1023 - ma non ho mai testati che)

• Può il mio Peerid (che mando in stretta di mano o me annunciare al tracker) influenza se i client torrent che' cercano di comunicare continuerà una connessione avviata? Cosa significa se menti e dico che sono un cliente Azureus usando '-AZ2060-' come mio ID?

Penserà di essere Azureus e se altri Azureuses promuovono la connessione a Azureuses in base a quello (e questo è un grande se ci) otterrete un beneficio da esso.

• La disponibilità del mio pezzo spaventa i colleghi? Sto cercando di connettermi e invio un campo bit vuoto (non ho pezzi, [length: 1] [Id = 5] [payload: {}]); sembra che mandino bitfield, io mando bitfield .. (alcuni mandano come matti hanno messaggi), si rendono conto che sono povero, mi lasciano cadere .. qualche goccia di connessione dopo la stretta di mano. (Come maleducato.)

• possibile ..

• C'è un vantaggio di non utilizzare il classico intervallo di porto: 6881-6889?

• Io non la penso così - tranne forse confondendo il proprio ISP ..

• fare client torrent mantenere internamente una lista di cattivi coetanei (come una lista nera)? A volte, dopo aver trovato un buon peer, ho continuamente usato le sue informazioni nei miei test ma solo una connessione 1/3 è stata accettata.A volte dovevano passare 10 minuti per avere di nuovo una connessione di successo.

• A seconda del codice client.

Sommario

E 'una giungla là fuori - tutti possono scrivere la propria logica finché inviando i comandi del protocollo corrette - le vostre domande si concentrano sul comportamento logico dei clienti, ma non c'è un terreno comune, come si probabilmente inteso ormai, questa è anche la bellezza del bit-torrent e probabilmente la ragione principale del suo successo.