Tecnología, Internet y juegos
132 meneos
2707 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear

Construyendo un cliente de BitTorrent completo en Go [ENG]

Un cliente de BitTorrent escrito desde cero en Go, con el protocolo muy bien explicado y el fuente comentado según va progresando el desarrollo.

| etiquetas: go , bittorrent
77 55 22 K 15
77 55 22 K 15
  1. Interesante!!
  2. Un tutorial muy majo.
    A ver si alguien me encuentra fuentes para rust (que compilen/funcionen con versiones actualizadas).
  3. Go es una puñeteras maravilla para estas cosas.
  4. Se echa de menos mas meneos como este
  5. #6 tendrás que pasarlo a Java primero
  6. #5 en C se puede hacer igual de fácil si tienes ya unas librerías que te permitan manejar comunicaciones y procesar los streams igual que en GO. Si no las tienes te toca hacerlas... es lo que tendrías que teclear de mas.
  7. #7 ¿es portable a java?
  8. #10 pues no conozco GO pero para hacer un cliente de bittorrent con una buena librería de comunicaciones tcp sincrona y/o asincrona mas otra que maneje streams (memoira y disco), alguna para manejar listas,colecciones o diccionarios, multithread sería un plus bastaría.
  9. #8 Por no hablar que la concurrencia a lo CSP que tienes de gratis.

    >multithread sería un plus

    golang.org/doc/faq#goroutines
  10. #8 Te dejas que Go puede compilar de forma cruzada automágicamente desde y para WIndows/Linux/OSX y BSD.
  11. #14 no no me lo dejo la pregunta no es la diferencia entre go y c es qué necesitaría para programarlo en C
  12. #15 Una librería y mucho más código. Entre memcpy y usar canales de Go, la respuesta es obvia.

    blog.golang.org/share-memory-by-communicating

    golang.org/doc/codewalk/sharemem/
  13. #16 creo que sigues sin entender la pregunta y mi respuesta. Pero te puedo asegurar por que lo he hecho que con una buena librería de TCP y streams haces un cliente de bitorrent en un pispas.
    Hay librerias para threading que no tienen nada que envidiar al GO, lo mismo para el resto de cosas....
  14. #14 C también.
  15. #20

    a:~/Docs/go/stuff>nvi ex.go
    a:~/Docs/go/stuff>env GOOS=windows GOARCH=amd64 go build ex.go
    a:~/Docs/go/stuff>file *
    ex.exe: MS-DOS executable PE for MS Windows (console) Mono/.Net assembly
    ex.go: ASCII Java program text
  16. Pregunta de no-experto: ¿se puede crear (es factible) un cliente de bittorrent realmente anónimo? O sea, me refiero a que no comparta tu IP con otros clientes de la red, sin necesidad de VPN y demás.

    Para mí es lo único que le falta (o que no he sabido encontrar) al tema. De esto que en "pares" no te salga la IP en la info del archivo vamos.

    PD: uso transmission.
  17. #24 El delito sería añadir un comentario a ese código. Con el nombre de la clase debería ser suficientemente auto explicativo. Cualquier comentario explicando lo obvio no es mas que ruido.
  18. #18 ¿qué tiene que ver SOLID en un lenguaje que no es orientado a objetos (tal y como reconoce el propio autor de tu enlace)? Y lo que es más, ¿qué tiene que ver el enlace que pones con el meneo?
  19. #23 Hasta donde yo se no. Bittorrent es un protocolo de comparticion distribuido entre pares. Al no haber servidor en medio, es necesario que las dos pares se conecten y para crear la conexión se requiere la ip.
  20. #26 el comentario en ese caso es el nombre de la función.
    El problema con los comentarios es que te puedes olvidar actualizarlos, con lo que si tienes ese código y un comentario diciendo "hago A si a es impar" y ya no sabes si el código está mal o el comentario no corresponde.
  21. Segundo párrafo de tu enlace:
    Here is why you shouldn't think very much about SOLID in Go

    Repito: ¿para qué quieres mezclar churras (SOLID/POO) con merinas (Go)?

    Uno crea interfaces (por regla general) si espera que su código sea reusado en algún momento. Para hacer una aplicación final sencilla, lo más probable es que no haga falta crearse abstracciones. ¿Para qué complicar el código?
  22. #31 Oops, esto iba para #29 :-)
  23. #30 Completamente de acuerdo. Recomiendo la lectura de uncle Bob en su libro de prácticas sobre Clean Code.
  24. #9 ni que eso le importara a Indra :-D
  25. #28 Sí, eso lo entiendo, pero ¿no habría un modo de que tu cliente, digamos... "cifrase/ocultase" tu IP de forma que otros clientes sólo viesen **.***.***.**, como al introducir contraseñas? El propio programa se comunicaría con el otro, pero el cliente no lo ve. Aunque pensándolo bien, supongo que si el otro programa "ve" tu IP porque lo necesita, está en la programación del otro qué hacer con esa IP. Vamos, que en todo caso sólo podría hacerse si ambos usasen el mismo programa, y este ocultase la IP, no si mezclo clientes.
  26. #36 el cliente recibe tu ip para poder conectarse, eso significa que ya la tiene, si la enseña o no al usuario es otra cosa. Pero en cualquier caso, aunque el cliente la ocultase el otro lado podría seguir viendo tu ip mirando las conexiones abiertas o analizando los paquetes de red. Además conseguir asegurarte de que el otro lado no hay un cliente que enseñe al usuario tu ip es extremadamente costoso, sino imposible, para la poca utilidad que tendría.
  27. #37 Un buen código de debe autodescribir. Comentarios que explican lo que hace un trozo de código pueden implicar "un problema". Además después tenemos otro problema: hay que mantener el código Y los comentarios doble trabajo y doble posibilidad de error sobre todo si pasa por 5 manos distintas.
    Igualmente en otros casos concretos si veo necesario poner ejemplos en código. Una regular expression por poner un ejemplo muy concteto aunque es aplicable a otros casos. Depende del uso. Siempre hay que aplicar la lógica y filosofía KISS. En mi experiencia es lo que mejores resultados ha dado.
    Saludos.
  28. #23 Aunque el cliente torrent no envíe la IP, el servidor vería la IP desde donde el cliente se conecta, ya que es parte de los headers del protocolo IP.
    Sin esa IP, no se puede establecer una comunicación a través de internet.
  29. #38 #40 Gracias a ambos. Vamos, que el propio diseño torrent lo hace imposible.
  30. #42 En assembler es el típico ejemplo de lenguaje de bajo nivel que como bien comentas sin comentarios estás muerto.
    El resto como decía depende del contexto. Un i++ dentro de un bucle puede ser nada o bien siguiente estrella como mencionas, con lo cual el sentido del comentario cambia en función de la semántica. Uno es relevante y otro no en el caso de un bucle.
    Creo que en el fondo del asunto estamos de acuerdo.
  31. #42 Y haciendo una breve puntualización: Sí i++ es siguiente estrella entonces lo mejor es llamar a esa variable siguienteEstrella y ya está.
  32. #21 claro que de forma trivial. Tienes el compilador de GNU para todas las plataformas y C siempre ha sido muy portable.
  33. #47 No señor. Estamos hablando de que ahora mismo desde mi OpenBSD he generado un binario para Windows sin necesidad de MinGW.
    Puedo hacer lo mismo con un target FreeBSD y ARM:

    a:~/Docs/go/stuff>uname -s
    OpenBSD
    a:~/Docs/go/stuff>env GOOS=freebsd GOARCH=arm go build ex.go
    a:~/Docs/go/stuff>file ex
    ex: ELF 32-bit LSB executable, ARM, version 1

    Intenta eso con C sin meter una suite gorda de compiladores cruzados.

    Yo solo he instalado el paquete "go" en OpenBSD. Nada más, cero dependencias.
  34. #47 Y lo que tu dices es posible, pero con lo opuesto a GNU: el C de plan9 :-)

    Tienes el compilador 1-9c, donde un número va a asociado a cada plataforma de CPU. Y 1-9l, el enlazador. Todos los binarios son estáticos, y claro está que crear un binario para ARM o MIPS en C de ARM está tirado. Otra cosa son rollos big/little endian, pero creo que la librería C de plan9 (u.h, libc.h) están en un nivel bastante superior en capacidad y sencillez respeto a POSIX.

    De hecho la filosofía de Go está basada en la suite de plan9 y en dicho diseño, y creo que usan una concurrencia similar :). Por algo son de los misma gente ha creado C.
  35. #49 #41 No exactamente, el propio diseño de internet hace que necesites saber la IP para poder conectarte.
    No es algo del torrent.
comentarios cerrados

menéame