Por ahora, eche un vistazo al FAQ (disponible en Inglés, Alemán y Francés) For now, please look at the FAQ (available in English, German, and French) en la web principal del proyecto.
Si tiene que usar un servidor proxy http para acceso a la web y quiere que el GUI use ese servidor proxy cuando obtenga listas de servidores via http, establezca la variable de entorno 'http_proxy' antes de iniciar el GUI desde el shell (=línea de comandos):
export http_proxy=http://wwwcache.algunhost.net:8080/
Fíjese bien en la barra del final. Otros programas como wget y lynx también
usan esta configuración si la variable está establecida. Puede comprobar si la variable
está establecida con el comando echo $http_proxy.
La mejor forma es probablemente poner la línea de arriba (la del export) al final de su fichero ~/.bashrc, de forma que no tenga que escribirlo cada vez que vaya a iniciar el GUI, si no que la variable 'http_proxy' de entorno se creará automáticamente cada vez que se identifique en el sistema.
Esto significa que después de completar una parte de un fichero, el checksum ('del pedazo parcial') de esta parte del fichero en su disco duro no coincide con el checksum que debería tener.
Esto no es nada de lo que deba preocuparse. eDonkey/overnet se han dado cuenta del problema y volverán a descargar esta parte.
Ha ocurrido una corrupción en los datos. No puede hacer nada a respecto. No se preocupe por eso. Sin embargo, si ocurre muchas muchas veces en diferentes ficheros, debe plantearse si tiene algún problema de hardware (fallos en la RAM, fallos en el disco duro, fallos en el controlador, fallos en el cable IDE, problemas debidos a overclocking, sobrecalentamiento del sistema, problemas con el sistema de ficheros, etc).
Por defecto, el GUI buscará un navegador en su sistema y usará el primero que pueda encontrar (de Galeon, Konqueror, Mozilla, Netscape, Opera). Si prefiere especificar un navegador, debe establecer la variable 'BROWSER' antes de iniciar el GUI desde el shell (=línea de comandos):
export BROWSER=/usr/bin/konqueror
Es necesario especificar la ruta absoluta hacia el binario. Puede encontrar esta ruta
usando cualquiera de los comandos whereis konqueror o which konqueror
(nota: no tiene porqué encontrar siempre el binario debido a que las rutas
están dentro del código).
Lo mejor probablemente es poner la línea de arriba de export en el final de su fichero ~/.bashrc, de modo que no tenga que escribirlo cada vez que inicie el GUI, si no que la variable 'BROWSER' se cree automáticamente cada vez que se identifique en el sistema.
La última versión del GUI le permite 'previsualizar' las descargas antes de que hayan finalizado si el core le comunica los nombres de fichero x.part temporales al GUI (todas las versiones recientes deberían hacerlo) y su core está ejecutándose en la máquina local.
Si ejecuta la función 'vista previa' por primera vez, el GUI escribirá un scrip por defecto
para vistas previas en su disco duro. Este script de vista previa se encuentra en
~/.ed2k_gui/ed2k_gui_preview. Puede abrirlo en un editor de texto normal y personalizarlo
de acuerdo con sus propias preferencias.
Aquí se dice como funciona: El GUI llama al script y le pasa la localización del fichero parcialmente
descargado como parámetro. En el script esto aparece como $* (que básicamente no significa
más que 'reemplazar con todos los parámetros que se le pasen'). El GUI también establece una variable
de entorno llamada ED2K_PREVIEW_EXTENSION que contiene la extensión del fichero en minúsculas
(debido a que no se puede facilmente decir el tipo de fichero que es algo llamado /mnt/temp/34.part).
Ahora el script coje la extensión del fichero y busca si coincide con cualquiera de los casos
preconfigurados dentro de case en el script. Si coincide, entonces la variable PREVIEW_BIN
es establecida con el nombre del programa que debe usarse para previsualizar el fichero, incluyendo cualquier
parámetro que sea necesario para el programa. Entonces el programa para este tipo de fichero es ejecutado.
Como puede comprobar es endiabladamente facil cambiar a su reproductor favorito o añadir nuevas extensiones.
Después de que el programa de vista previa haya finalizado, deberá pulsar la tecla Enter para cerrar la ventana de terminal de xterm que fue abierta para mostrar la salida de los programas de vista previa (y que le permite interrumpir la vista previa usando Control-C, por ejemplo en el caso de mpg123/ogg123).
Si no desea que el script espere hasta que la vista previa haya finalizado, borre las siguiente líneas del mismo:
echo "Finished. Hit <enter> to close this window"
read
Si desea que la ventana de xterm se cierre justo después de llamar al programa de visualización, borre las do líneas de arriba y modifique la línea del programa de previsualizado para que quede como la siguiente:
$PREVIEW_BIN "$*" &
Diríjase a la sección de enlaces-ed2k en el capítulo de 'Uso' de esta documentación.
POR HACER, vea el FAQ
Si es en nombres de archivo o en nombres de servidores, entonces probablemente es debido al locale que tiene elegido. Necesita entonces ver cómo cambiar su locale por algún otro valor apropiado. Si cambia su locale de todos modos, por favor cámbielo para que todo use la codificación de caracteres UTF8, y no ISO-8859-X (p.e. es_ES.UTF8 o similar).
Sin embargo, tanto eDonkey2000 como Overnet no usan los locales para nada, en ese sentido no hay que decirle al GUI u otros clientes en qué conjunto de caracteres ha sido codificada una cadena de texto. Por eso nunca será capaz de ver un nombre de archivo en las búsquedas exactamente del mismo modo que lo ve otra persona en otro idioma. Normalmente esto no debe ser un gran problema.
POR HACER, vea el FAQ
¿Por qué? No lo sé. Posiblemente sea un bug de GTK+. Vaya a la página de opciones y asegúrese de que está establecida la opción 'deshabilitar doble clic en la listas'. Eso debería solucionar sus problemas.
La función de 'vista previa' de la lista de descargas en el menú emergente del botón derecho está deshabilitada en dos casos:
(1) No hay nada seleccionado
(2) el GUI piensa que el core se está ejecutando en otro ordenador. El GUI puede asumir que este es el caso cuando usa un nombre_de_host/IP diferentes a 'localhost' o '127.0.0.1' como nombre de host para el core (nota: otras formas más sofisticadas para comprobar si la dirección/nombre_del_host son locales han sido deshabilitadas debido a peticiones por parte de los usuarios). Por ahora todo lo que no sea 127.0.0.1 o localhost no es local.
Problema: Solo puede configurar su router para IP-forward a un puerto exacto de una dirección IP, los otros ordenadores no pueden usar el mismo puerto y no tiene un ID alto.
Solución: Ejecute cada cliente donkey en un puerto diferente (e.g. uno en 3662, otro en 4662, otro en 5662, otro en 6662, etc.), y configure su router para que haga IP-forward de cada puerto a la IP correcta. Nota: solo necesita redirigir un puerto tcp por cliente para obtener un ID alto.
Puede tener múltiples cores ejecutándose y controlarlos todos al mismo tiempo o a la vez. En este caso probablemente quiera usar la opción en línea de comandos '-n' para el GUI, que hace que el GUI cree otra 'copia', lo que quiere decir que se usará otro conjunto de ficheros de configuración para el GUI completamente diferentes. Para el primer core, inicie el GUI de la forma habitual. Para el segundo core pase la opción '-n 2' al GUI. De esta forma sus estadísticas, etc. se mantendrán limpias y separadas y también podrá configurar el GUI para que se auto-conecte al core durante el inicio.
Esto es un problema. Un core solo puede ser controlado por un GUI en un momento dado.
Sin embargo, hay una manera facil y gratis para resolver este problema: usar VNC.
Instale un servidor VNC en la máquina en la que ejecuta el core, y visores VNC (disponibles para todo tipo de plataformas) en los sistemas desde los que quieres controlar el GUI y el core. Ahora puede ejecutar el GUI en la máquina en la que el core se encuentra, y controlar de forma remota el GUI en cualquier máquina usando VNC. Un escritorio VNC puede ser compartido por múltiples usuarios, esto debería resolver su problema. En teoría el menos, yo no lo he probado todavía.
Este es mi (Thomas) script de inicio para donkey, estoy cansado de cambiar al directorio correcto manualmente todos los dias... coje una lista nueva de servidores, inicia el core, espera y entonces inicia el GUI.
#!/bin/sh # Script de inicio E-Donkey 2000 # Inicia el donkey desde el directorio home, reemplace esto con su directorio de donkey! cd ~/ablage/edonkey # Obtener lista de servidores, haciendo unos truquillos mv server.met _server.met wget http://ocbmaurice.dyndns.org/pl/slist.pl/server.met?download/server-max.met || cp _server.met server.met rm _server.met # Iniciar eDonkey en una sesión de pantalla con nombre (¡Necesita una pantalla GNU!) screen -dmS donkey -- ./donkey - ! # De otro modo: # ./donkey - ! & # Esperamos un poco... sleep 5 # Iniciamos el GUI ed2k_gui -c
Usualmente puede iniciar programas con un '&' al final en el terminal y esto los ejecutará en segundo plano. Con el cliente en línea de comandos de eDonkey, sin embargo, esto no funciona del todo bien. Puede tener problemas similares si inicia el donkey desde una sesión telnet/ssh (no use telnet, ¡use ssh!), pero lo mantiene activo incluso después de cerrar la sesión. 'nohup' no funciona con donkey en muchos sistemas.
Para este tipo de magia necesita la utilidad 'screen', que probablemente se encuentre ya instalada en su sistema.
Compruebe la página del manual con man screen. Aquí se muestra un resumen:
Inicie el donkey con
cd /home/joe/ed2k/
screen -dmS donk ./donkey0.50.1 - !
El 'cd es para asegurarse de que el core lee y escribe sus propios ficheros de configuración siempre en el mismo directorio (i.e. /home/joe/ed2k/ aquí). Si no hace esto, el core sobreescribirá sus ficheros de configuración en el directorio actual, lo que probablemente cause confusión
La opción '-' es para poner el donkey en modo GUI, y la opción '!' es para asegurarse de que donkey acepta comandos solo via GUI, pero no desde la línea de comandos, que es lo que necesita para cerrar el core de forma correcta desde el GUI.
Deje la pantalla lo primero pulsando Control-A, después Control-D. Debe ahora haber vuelto a su consola.
Puede volver a la consola de donkey en el momento que quiera con
screen -d -r donk
then.
Esto puede tener varias causas. Note que 'firewalled' no se debe de interpretar literalmente. 'Firewalled' símplemente significa que otros servidores no pueden conectarse con éxito a su cilente en el puerto configurado (que es 4662 por defecto).
Una razón de por qué esto puede ocurrir es que usted esté realmente detrás de un cortafuegos, quizá en su ordenador, o quizá en su gateway/router, y el cortafuegos bloquee los intentos de conexión entrantes desde el servidor.
Otra razón puede ser que esté usando un router DSL y algún otro router/gateway, y este rourter haga NAT(= Network Address Translation = IP Masquerading = Internet Connection Sharing/ICS). NAT es usado por muchos ordenadore sen una pequeña red privad que comparte una conexión a internet. En este caso la 'IP pública' de su ISP está asignada a su router, y todos lo ordenadores de la red privada tienen una 'IP privada' (e.g. 192.168.x.x o 10.x.x.x). Si este es el caso, necesitará configurar redirección de puertos de su router. Necesita redirigir el puerto tcp 4662 de la IP de su ordenador a donde el donkey se esté ejecutando. Si tiene varios donkeys ejecutándose en su red, ejecute todos en diferentes puertos y configure redirección de puertos para cada uno de los puertos a sus diferentes IPs privadas.
Finalmente, algunos servidores están mal configurados y no permiten conexiones entrantes en puertos no-estandar. Estos servidores siempre le dirán que está tras un cortafuegos, incluso si son ellos los que lo están y no usted. Esto ocurre ocasionalmente si ejecuta donkey en un puerto diferente al estandar (tcp 4662). Sin embargo, si realmente todos los servidores le dicen que está tras un cortafuetos, esto último no será la causa de ello.
Desafortunadamente el cliente actual en línea de comandos no soporta un servidor proxy SOCKS, pero puede probar a usar tsocks, que proporciona soporte para programas que necesitan servidor proxy SOCKS y no lo tienen de forma nativa. (Se trata de una librería de pre-carga que intercepta las llamadas del sistema de red a connect() y 'redirige' estas al servidor proxy etc.).
Puede encontrar que después de ejecutar el donkey durante un momento su conexión a internet se vuelve horriblemente lenta, o al menos no se obtiene mucha respuesta: conectar a un servidor web o chequear su cuenta de correo electrónico de repente tarda varios segundos en lugar de milisegundos.
Descartando cosas: si el error puede ser reproducido con servidores específicos e independientes esté el donkey ejecutándose o no, entonces el problema puede estar escondido. Si está usando PPP-sobreEthernet (PPPoE) entonces debe comprobar doblemente su interfaz de red (pppX o ethX), la configuración MTU (por ejemplo). Si el problema solo ocurre cuando el donkey está fuertemente sobrecargado, lea más adelante.
Aquí está el problema en un nutshell: su router DSL tiene una cola pre-construida de paquetes, que funciona de forma bastante simple: el primer paquete que llega sale el primero (FIFO). Si la cola de paquetes de su router está llena, entonces el router silenciosamente elimina paquetes. Es normal que esto ocurra, y el protocolo TCP se da cuenta de ello. El problema es cuando cada paquete TCP que recibe su ordenador necesita enviar un pequeño reconocimiento (ACK) al que envia para que este sepa que los datos han llegado. Este mecanismo es usado para compensar la pérdida de paquetes y ajustar la velocidad dinámicamente con respecto a la variable de ancho de banda. Ahora si la cola de paquetes de su router está llena porque donkey está subiendo ficheros y quiere conectarse a un servidor, entonces la petición de conexión (paquete SYN) se envía al router, y éste lo pone en cola. Pero como la cola está llena, tarda varios segundos hasta que la petición SYN es aceptada y enviada al servidor al que desea conectarse, debido a que su router normalmente no podrá distinguir entre paquetes importantes y no importantes. Lo mismo ocurre para paquete que desee enviar (e.g. la petición HTTP-GET de su navegador de Internet). Es por eso que la conexión se vuelve inactiva. Lo que necesita saber es que incluso si la velocidad de su línea es técnicamente de 128kbps = 16kB/s (por ejemplo), parte de esto es usado para información administrativa (cabeceras) de los protocolos involucrados. De este modo su velocidad de subida es menor, y su subida puede llenarse facilmente incluso si parece que se estuviese por debajo del límite superior.
¿Qué hacer?
Bastante simple: necesita algo llamado Calidad-de-Servicio (QoS - del inglés Quality-of-Service). Los núcleos de Linux posteriores a 2.4.x disponen de esta característica implementada, solo necesita asegurarse de que su kernel ha sido compilado con soporte QoS completo (dentro del kernel o como módulos).
El principio es simple: asegurarse de que la cola de paquetes de su router nunca se llena. Para conseguir esto, necesita poner en cola todos los paquetes en su equipo Linux en lugar de en su router (nota: normalmente, no ocurre así porque la conexión entre el router y su linux es mucho más rápida que entre el router y el resto de internet, por lo que el kernel de linux envia todo al router inmediatamente y sin retardos). Ahora que la cola de paquetes está administrada por su kernel de linux, puede decir a linux el tipo de ordenación que necesita. Por ejemplo, puede asignar a unos paquetes más prioridad que a otros. Entonces esos paquetes se 'saltan la cola' y se envian inmediatamente incluso si otros (menos importantes) están esperando en la cola. Personalmente, tengo marcado todo el tráfico en los puertos 'interactivos' 21, 22, 23, 110 (menos 80 porque alguna gente de windows configura el donkey para que use el puerto 80) y el tráfico a mis sitios web favoritos y todos los 'paquetes pequeños' (normalmente paquetes SYN o ACK) a la prioridad más alta.
Una buena descripción realizada por Emmanuel Roger sobre como establecer todo esto se puede encontrar aquí: http://www.prout.be/qos/QoS-connection-tuning-HOWTO.html.
Desde mi experiencia se aconsejo leer otros COMOs como el ADSL-Bandwidth-Management-HOWTO), a menos que le gusten los retos. Este y la mayoría de los otros COMOs que he encontrado acerca de este tema requieren que se parchee el kernel y su código fuente de iptables (e.g. para el dispositivo-IMQ), que provee especial dificultad si los parches mencionados no funcionan con la última versión de kernel/iptables...
Aquí tiene un recorte de mi script de inicio de iptables, por si hay alguien interesado:
##########################################################
#
# Quality of Service (QoS)
#
# desde http://www.prout.be/qos/QoS-connection-tuning-HOWTO-4.html
#
##########################################################
# reset
tc qdisc del dev eth1 root 2>/dev/null > /dev/null
# marcar paquetes con tamaño 0-500 (considerado como tráfico inactivo)
#
iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 3
# marcar paquetes UDP como importantes
#
iptables -t mangle -A OUTPUT -p udp -j MARK --set-mark 3
# los paquetes grandes se marcan como tráfico de datos
#
iptables -t mangle -A OUTPUT -m length --length 500:1500 -j MARK --set-mark 4
# marcar paquetes de ssh/smtp/pop3 también como prioritarios
# (no http, debido a que alguna gente de donkey usa el puerto 80)
for i in 22 25 110
do
iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j TOS --set-tos Minimize-Delay
done
# marcar sitios favoritos con tráfico prioritario.
#
# slashdot(new) slashdot.org, www.ct.heise.de,
# edonkey2000, jigle.com, jabber.org
# google
#
for i in "66.35.250.150" "64.28.67.150" "193.99.144.71" \
"198.77.34.120" "212.249.10.246" "208.245.212.108" \
"216.239.39.101"
do
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j TOS --set-tos Minimize-Delay
done
# marcar subdominios enteros como importantes
#
# amazon/imdb - sourceforge.net
#
for i in "207.171.166.0" "216.136.171.201"
do
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j TOS --set-tos Minimize-Delay
done
# crear root cvq qdisc para nuestro dispositivo eth1
#
tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64
# Ancho de banda de bajada = 576 kbits
# Ancho de banda de subida = 288 kbits
#
# Relación de tipo interactivo = Ancho de banda de bajada / 20 = 29
# Relación de tipo de datos = UL bandwidth - Interactive class rate = 259
#
# Hagamos lo último un poco más pequeño para estar a salvo
# (no queremos que un simple paquete siempre esté en cola en el router)
# => 190, que es mucho menos del sugerido, pero funciona bien para mí
#
# (¿1500 es el MTU de la interfaz?)
#
tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit \
rate 29Kbit allot 1500 prio 1 maxburst 10 avpkt 100 isolated weight 100
tc class add dev eth1 parent 10:0 classid 10:2 cbq bandwidth 10Mbit \
rate 190Kbit allot 1500 prio 8 maxburst 2 avpkt 1500 bounded weight 1500
# le decimos al kernel qué tipo de paquetes queremos enviar
tc filter add dev eth1 parent 10:0 protocol ip handle 3 fw flowid 10:1
tc filter add dev eth1 parent 10:0 protocol ip handle 4 fw flowid 10:2
Esto ocurre con los núcleos recientes. La razón normalmente es que eDonkey/Overnet usa demasiados descritores de archivos (un descriptor de archivo por cada archivo abierto y cada conexión de red activa), que es más de lo que usted como usuario joe tiene permitido en su sistema.
Puede comprobarlo con
%ulimit -n
el número de descriptores de archivos abiertos que su usuario tiene en total permitido (teniendo en cuenta todos los programas y procesos que está ejecutando actualmente).
Puede cambiar este límite editando el archivo /etc/security/limits.conf (como root) y añadiendo una línea como esta al final:
tim hard nofile 4096
'tim' es el nombre de usuario que está usando, 'hard' significa 'límite fuerte', 'nofile' significa el número de descriptores de archivo abierto permitidos, y 4096 es el valor (puede que quiera usar un valor más alto, pero 4096 debe ir bien).
Ahora necesita comprobar una cosa más, algo que puede diferir ligeramente de
una distribución a otra. Si tiene un archivo /etc/pam.d/common-session,
asegúrese de que tiene una línea como esta dentro:
session required pam_limits.so
Si no tiene un archivo como ese, añade o comente la línea de encima en
/etc/pam.d/login. Si usa gdm/kdm/xdm para iniciar sesión, deberá
comprobar también /etc/pam.d/gdm, /etc/pam.d/kdm, y/o
/etc/pam.d/xdm y si tienen esa línea añadirla/descomentarla
si es necesario.
Después de que haya editado ese archivo, necesitará re-identificarse 'correctamente' (cierre su sesión de X y re-identifíquese en el sistema en la consola o xdm/kdm/gdm). Después de que haya ejecutado 'ulimit -n' en una ventana xterm, debe mostrar el nuevo límite y el problema debe haberse solucionado.
En Mac OS X el límite por defecto parece ser 256 descriptores de archivo por usuario. Este límite es muy pequeño para eDonkey2000/Overnet. Puede cambiar el límite escribiendo
limit descriptors 4096 (¡esto es en MacOSX tcsh!)
en la línea de órdenes y luego iniciar el GUI o el núcleo (esto es porque la configuración solo funciona para el proceso hijo que inicie, no lo cambia para el sistema completo). Puede comprobar su límite escribiendo 'limit' en la línea de órdenes. (Gracias a un usuario anónimo en los foros por esto).
El proceso exacto depende de su sistema/distribución. Comuníqueme si necesita se resuelto de modo diferente en otros sistemas.
Lo primero, ¿ha pasado '-' en las opciones de la línea de órdenes del core cuando lo ha iniciado? La opción en línea de órdenes '-' le dice al core que escuche peticiones del GUI en un puerto específico. Sin pasarle esa opción, el GUI no será capaz de conectar con el núcleo, lo que el GUI busca es un núcleo que tenga esa opción pasada en la línea de órdenes.
Lo segundo, el GUI espera que el binario del núcleo se llame 'donkey*', 'overnet*', o 'cdonkey*' (solo mira el principio del nombre). Si ha renombrado el programa, el GUI no lo encontrará (¿cómo es que ha hecho eso?).
Dos soluciones fáciles: PUede usar una de las otras IPs no locales de su máqina, por ejemplo la IP de su tarjeta de red (p.e. 192.168.0.2), o editar su archivo /etc/hosts y añadir una línea como 'core.outerspace.world 127.0.0.1' y poner 'core.outerspace.world' en el campo de nombre del host en el diálogo de 'Conectar a..'
De todos modos esto es algo que no va a ser 'arreglado', porque la decisión de insistir en ejecutar un núcleo local en el caso de 'localhost' ha sido hecha a propósito, para facilitar a un usuario novato joe el proceso de como empezar.
Note también que el 'running core detection' solo funciona en GNU/Linux con un sistema de archivos /proc montado por el momento. Los usuarios de otros Sistemas Operativos (p.e. *BSD, MacOSX) puede que nos quieran enviar un parche para arreglar esto :)
Vea si puede reproducirlo y/o cómo reproducirlo
Compruebe si el error ya ha sido reportado, y de ser así, si ya ha sido corregido. Asegúrese de mirar en 'todos' los errores en el sistema de control de errores, de otro modo solo verá los errores 'abiertos' pero no los corregidos.
Si sabe como usar CVS, compruebe la última versión del GUI desde el CVS para ver si el error sigue estando presente en esta versión.
Envíe el error al sistema de control de errores del proyecto con tanto detalle como sea posible. Si dispone de una cuenta en sourceforge, identifíquese para que pueda contactar con usted si tengo alguna pregunta más acerca del error. Si no la tiene, monitorice el error o compruebe su estado de vez en cuando para ver si hay alguna pregunta a respecto.
Escríbame un correo electrónico. Respuestas positivas siempre me hacen feliz :-)
También tengo una amazon.co.uk wishlist y una amazon.de wishlist en el caso de que se sienta bien dandome una pequeña cantidad por las miles de horas de trabajo que he invertido en el GUI y en el core ;)