Últimos Cambios
|
|
|
|
Últimos Cambios |
|
|
|
||
| Mi estado actual
en Jabber/XMPP:
| |||
Última Actualización: 13 de febrero de 2008 - Miércoles
Recientemente, uno de los lugares P2P que frecuento ha instaurado una política de cuota de tráfico de subida, que complementa su ya legendario SR ("Share Ratio"). El objetivo que busca esa medida es que los usuarios que disponen de poco ancho de banda de salida puedan mantener un SR decente, evitando que los que tienen un gran caudal les "pisen" los "peers" y les dejen sin nadie a quien subir.
Dado que mi cliente BitTorrent no permite esa funcionalidad, me tocaba o cambiar de cliente o -dado que el programa está escrito en Python- programarla yo mismo.
Sobra decir qué camino elegí :-)
Para poder realizar un control de la cuota, es preciso llevar contabilidad del tráfico. Dicha contabilidad debe conservarse entre ejecuciones del programa, así que utilizo tecnología de persistencia. Esta tecnología novedosa apenas se emplea por ser poco conocida, pero es muy potente y simple de utilizar. Qué lástima. ¡Ellos se lo pierden! :-).
Así pues, nos hacen falta tres cosas:
Aquí tienes el parche para BitTornado 0.3.17.
Como podemos ver, el parche es relativamente simple:
Otra ventaja de este sistema es que si hemos llegado a nuestra cuota no transmitiremos nada, pero seguimos pudiendo ver si hay demanda en el "swarm" (enjambre). Así, podemos hablar con alguien sin problemas de cuota y pedirle que reactive el "torrent".
La forma de calcular la cuota que corresponde a cada "torrent" es como sigue:
Obsérvese que somos muy conservadores a la hora de calcular si estamos en zona de cuota o no, y de calcular la cuota correspondiente, dejando incluso un margen de seguridad de 10 megabytes, por si las moscas.
Por supuesto, esta parte del código puede fijar una política arbitraria. Todo el meollo del asunto está aquí.
Una vez decidida la cuota que corresponde a este "torrent", se almacena como un valor numérico fijo, a disposición del sistema de control de tráfico.
La parte interesante son las dos rutinas "x". Como puede verse se utiliza el decorador "@monitor" para interactuar con la infraestructura Durus de la forma más transparente posible. La claridad y la sencillez son los paladines de la tecnología de persistencia. ¡¡Aquí se puede comprobar!!.
Es muy importante señalar que este módulo no guarda ninguna relación con BitTornado. Es un decorador genérico que uso siempre que empleo persistencia, para no tener que preocuparme de cosas como conflictos o errores de conexión. Podéis usarlo en vuestros propios proyectos, tal cual. Ésto es todo lo que se necesita, no hay que comerse más el coco.
La mayoría de mis programas "persistentes" integran dentro un servidor Durus. De esta forma tengo todo junto, pero sigo manteniendo la posibilidad de interacturar con el sistema de persistencia de forma manual y externa, si es necesario. En este caso, en cambio, podemos tener muchas instancias de BitTornado funcionando simultáneamente, así que he preferido segregar, en esta ocasión y sin que sirva de precedente, el servidor de persistencia en un proceso aparte y separado. El código del servidor de persistencia es trivial:
#!/usr/local/bin/python
import sys
sys.path.extend(("/video/0/durus-berkeleydbstorage",))
import berkeleydb_storage
storage=berkeleydb_storage.BerkeleyDBStorage("/video/0/durus-berkeleydbstorage/db", \
durable=False,async_log_write=True,do_recover=True)
from durus.storage_server import StorageServer
StorageServer(storage, address="/video/0/durus-berkeleydbstorage/db/unix_socket").serve()
Este programa debe arrancarse antes de los BitTornado. Como veis, un servidor de persistencia simple es muy... simple :-). El único detalle a tener en cuenta es que, por razones de explicaré en otro artículo, configuro un "storage" ACI (no ACID), pero indico escrituras asíncronas de log (lo que indica que es "casi" ACID, salvo fallo del sistema operativo o que se corte la electricidad). Este programa utiliza mi "backend" para Durus y el propio Durus, claro.
