Queda mucho camino
Cada dia encuentro nuevos fallos en madagascar: logico, estamos en los primeros lanzamientos y es ahora cuando estoy teniendo la oportunidad de verlo funcionar realmente. En estos momentos estamos reestructurando codigo, incluso estamos usando AOP: programación orientada a aspectos. Además de la reestructuración, estoy haciendo lo posible con los profiler para detectar las zonas en las que hay un exceso de CPU. Hay que tener en cuenta que por cada descarga se lanza un hilo, y en cada ciclo tiene un periodo de sleep. Por supuesto, hay que añadir más sleep si la cola de subida o bajada está llena.
Otro punto importante es el anonimato: En el foro me pasaron artículos acerca del anonimato en las redes Pastry. Es importante este aspecto por lo que haré todo lo posible por incorporar todas las novedades referentes a este tema.
El sistema de búsqueda de archivos en un sistema p2p es muy importante. Tengo pensadas dos opciones: una centralizada y otra descentralizada y montada sobre Pastry. La segunda es basada en el sistema de búsqueda que implementa la red GhostShare, que se basa en aplicar un resumen, mediante SHA-1 por ejemplo, a las palabras clave e insertando en la DHT una n-tupla con la información de los datos que se suben. Aunque parece un poco lioso, podeis ver el articulo aqui.
Proporciono un breve To-do con lo que creo que es más importante en este momento:
- Estabilizar madagascar.
- Controlar y reducir los recursos de CPU.
- Reestructurar el código y hacerlo más eficiente.
- Activar el cifrado de archivos y emplear socket seguros.
Víctor Puertas' Log 
Sobre lo que comentas de la inconveniencia de los threads, se suele utilizar la multiplexación de la entrada/salida mediante llamadas tipo «select» o afines (epoll, poll, kqueue) . En java nunca lo he utilizado pero parece ser que existe). Aunque estas cosas dependen mucho de la implementación de los threads/select.
Las ventajas: la multiplexación de la I/O suele ser más ligera que la multiplexación de un proceso/thread (no hay scheduling y el overhead adicional es mínimo) y evitas problemas de concurrencia (porque no hay concurrencia en absoluto, símplemente se van sirviendo peticiones una detrás de otra). Desventajas: tiene un impacto grande en el diseño de tu código.
A lo mejor ya has tenido esto en cuenta, pero espero que el comentario sea útil 😀
Dani.
Este tipo de comentarios siempre son útiles. La verdad es que la multiplexión es a nivel thread y eso tendrá mucha sobrecarga. Tendré que pensar la mejor forma de implementar y rediseñar eso, todo sea por que funcione de forma ligera.