Si ya sabes de qué va esto, HAZ CLICK AQUÍ para enterarte de qué proxy debes ponerte para intentar que esto funcione lo mejor posible de cara a la comunidad.
Otra web con ayuda y proxies webcache:
Este hilo se irá actualizando poco a poco con la información que se conozca en cada momento con respecto a la función webcaché.
- Para preguntar cosas específicas sobre los Proxies, no sobre la función webcaché, pásate por el HILO DE PROXIES.
- Para preguntar DUDAS específicas sobre la función webcaché QUE NO VENGAN YA RESUELTAS AQUI, pásate por el HILO DE DUDAS. Eso sí, ¡¡¡LEETE ESTE HILO ANTES DE POSTEAR ALLI!!!!
_______________________________________________________________________________________
¿Qué es Webcache? Es una nueva opción que incorporan los últimos MODs de Emule basados en las versiones oficiales 0.44. En realidad es un MOD llamado directamente así, webcache, que ha sido implementado en las últimas versiones de otros MODs como Pawcio o Phoenix. Las versiones oficiales no lo implementan aún, y los desarrolladores de la versión oficial han dicho que no lo van a meter por ahora, para no tener problemas legales, pero eso no significa que no sea una característica muy beneficiosa para la comunidad Ed2k en general.
¿En qué consiste Webcache? Bueno, es algo un poco difícil de explicar y largo, pero básicamente consiste en que cuando quieres bajar de alguien un trocito, en lugar de decirle que te lo pase directamente ese alguien, le vas a decir que te lo suba a un proxy-caché. Esto es una máquina como la que puso Telefónica hace meses, que permite "guardar" en la memoria de la máquina lo que acaba de pasar por ella en tránsito de un PC a otro. El motivo es que, si ahora otro usuario le pide al usuario fuente inicial el mismo trozo de archivo el primer usuario que recibio el trozo le va a decir "mira, mejor pídeselo al proxy-caché, que lo tiene en memoria y es mucho más rápido que el uploader". El usuario 2 se lo pide entonces al proxy caché y se baja el archivo a la velocidad del rayo sin gastar ancho de banda del uploader.
Esas máquinas proxy tienen un ancho de banda gigantesco, más que cualquier conexión actual entre usuarios, y es por eso que te permiten bajar al máximo de tu velocidad siempre que no se colapsen. Generalmente se utilizan para ahorrar tráfico de datos a las compañías telefónicas en la navegación por Internet. Es decir, cuando tú pides una página web, pasa por el proxy-caché y se queda allí grabada. Si otro pide la misma página, el proxy se la manda y así no tiene que pedirla 2 veces al sitio remoto, ahorrando tráfico. Ahora se va a sustituir el server de la página web remota por un usuario Emule, pero la base es la misma.
¿Qué ventajas tiene eso? Ventajas fundamentales. Vamos a ver:
1. La velocidad de transmisión de datos se multiplicará por cientos, ya que lo que antes tenía como límite la velocidad de subida de CADA usuario respecto a quien bajaba, ahora el único límite es la velocidad de subida del PRIMER usuario. Es perfectamente factible que en el tiempo que tarda en subir un archivo el compartidor inicial, se lo hayan bajado 100 personas o más, sin tiempos de espera de colas ni nada.
2. Esto también conviene a las compañías que gestionan el servicio de banda ancha, en especial a las de ADSL, tanto a las vendedoras primarias (Telefónica) como a las de reventa (Ya.com, Wanadoo,...). Si disminuye el tráfico externo, las primeras ahorran ancho de banda y tener que pagar a otros proveedores por descargar cosas de su red más de una vez, y las segundas ahorran porque deben pagar propocionalmente al tráfico soportado. De modo que a ellas también les conviene.
3. Con las últimas versiones del webcaché se puede usar también el famoso proxy de Telefónica en todos aquellos usuarios que pertenezcan a su red (que se llama GIGAADSL). Por lo tanto, no se necesitará buscar un proxy adicional, basta con el que Telefónica ya tiene implementado.
4. Cuando los usuarios bajan de un proxy-cache, evidentemente ya no bajan del usuario inicial el mismo trozo, con lo que el ancho de banda de este último queda libre para subir a otros usuarios o a otros proxys, optimizando la red. Pensad que, en realidad, es como si ahora hubiera nuevos servers que no solo conectan a los usuarios entre sí, sino que además aceleran bestialmente el tramo de tráfico desde ellos hacia el resto de usuarios que van a recibir un archivo. El usar webcaché beneficia también a aquellos que no lo usen, porque les quedarán más slots de descarga libres en el resto de usuarios.
5. Por último, y es lo que me lleva a escribir esto, a partir de Octubre de 2004 comienzan a doblar la velocidad de las líneas básicas de ADSL en España, pero no lo hacen en la subida (upload); solo en la bajada (download). En las líneas de gama alta si suben el upload, pero no es proporcional al aumento experimentado por el download correspondiente. Como ejemplos:
- ADSL 256/128 sube a 512/128. El upload queda igual y el download sube al doble.
- Nuevas líneas de 1024/300. Si pasamos a esta desde una 256/128, el upload se multiplica por 2.34, pero el download se multiplica por 4, con lo que proporcionalmente el download sube más que el upload. Igual si subimos desde una 512/256.
- En cable pasa lo mismo, en aquellas conexiones en que sube el upload también, el download aumenta proporcionalmente mucho más.
De lo que se deduce que, en las próximas semanas vamos a experimentar un problema de ahogo del upload total común de todos los usuarios con respecto al download. Las líneas son asimétricas, y el download siempre es mucho mayor que el upload. Hasta ahora la cosa más o menos se mantenía gracias a la interconexión de bajadas de archivos extranjeros (que tienen mucho mejores líneas) para que todo el mundo bajara con una media bastante cercana a su máximo de download, cuya diferencia con el upload total era suplida por esas líneas extranjeras, algúnas de ellas simétricas y otras tan anchas que no notarían la diferencia.
No hay que olvidar que la red Emule es cerrada, salvo algúnos clientes Shareaza y unos pocos intentos por desarrollar un plug-in para bittorrent. Eso significa que todo lo que se está descargando en la red a cada momento, proviene de los mismos usuarios que están descargando, usuarios que están subiendo datos al mismo tiempo. La cantidad de datos posible para descargar es la misma que se está subiendo a cada momento y no hay más.
En las próximas semanas vamos a llegar a un escenario bastante menos halagüeño que el actual. Por decirlo con una metáfora: el pastel de datos se va a agrandar un poco, no demasiado (porque hay líneas que no aumentan su upload), pero el estómago de los comensales va a crecer al menos al doble, y en algúnos casos puede que más, con respecto al aumento de pastel. Si el pastel no aumenta en la misma proporción que el hambre de los comensales, está claro que los comensales van a tener que repartirse el pastel como buenos hermanos, o puede que llegue algúno que se hinche la tripa llena y deje SIN NADA a otros. Ahora podía pasar, que alguien, por ejemplo con una ADSL 256/128, bajara a 27 KB/s y otro no pasara de 8, cuando la media de upload son 10-12 KB/s; esto quedaba más o menos compensado por el intercambio de archivos con el extranjero, como ya he comentado. Pero si en el futuro el que bajaba a 27 va a bajar a 53 sin aumentar su upload para compensar; o si va a bajar a 110 KB/s sin aumentar su upload más que de 10 a 25, os podéis imaginar que alguien se va a quedar sin su trozo de pastel. Y eso, con líneas dobladas en velocidad, va a sentar muy muy mal a más de uno.
¿Cuál es la solución? El WEBCACHE. El webcache permitiría si conseguimos implantarlo en suficientes fuentes que todo el mundo descargue a velocidades de vértigo aún cuando los uploads no suban demasiado. Es como si tuviéramos un pastelero al lado de la tarta que, para cada trocito que se saque de tarta, él va a fabricar cientos iguales. Todos los comensales podrán hartarse llenando sus estómagos por grandes que sean. Pero si no lo hacemos, es posible que comiencen los problemas.
Dado que todo son ventajas y solo hay algún inconveniente (que comentaré más tarde), os animo a que TODOS comencéis a usar una de estas versiones que permiten webcaché. Cuantas más personas estén usando el webcaché, mejor funciona el tema, pues todo el mundo está en condiciones tanto de recibir como de enviar datos a los proxy-cachés, y estos dispondrán de muchos más trocitos que enviar y recibir para aumentar la velocidad.
¿Cómo se utiliza? Bueno, es muy fácil. En esas versiones MOD de Emule que digo, hay una nueva opción en preferencias llamada precisamente Webcaché. Hay que activarlo ("Enabled"). Tiene varias opciones. De las opciones que vienen al pulsar el botón de "Opciones Avanzadas" podéis olvidaros porque no sirven para nada en las líneas de España. Las casillas "proxy" y "puerto" hay que configurarlas manualmente, con los proxys que funcionen. Para saber cómo configurar esas 2 casillas, pasaos por estas 2 webs:
Luego hay que apagar Emule y volverlo a reiniciar, con lo que ya empezaremos a estar en condiciones de subir y bajar datos desde proxys-caché. No hay que andar pulsando el botón de Autoconfiguración porque ahora mismo NO funciona en condiciones, hay que hacerlo de forma manual.
Funciona un poco a saltos, porque las versiones actuales solo suben y bajan trocitos de 180 KBs cada vez, así que funciona como un muelle, dándote picos de bajada cada pocos segundos. Se puede ver quién tiene webcaché activado en una nueva categoría de la pestaña de Tráfico. No obstante, si hubiera el suficiente número de fuentes subiendo por webcaché el resultado para todos sería mucho más continuo y estable, ya que la descarga desde el proxy iría saltando de un bloque de 180 KBs a otro casi ininterrumpidamente y no se notarían las pausas entre pico y pico, con lo que no habría picos, solo una "meseta".
Y por último, los inconvenientes. El problema es que no todas las compañías que ofrecen banda ancha en España tienen un proxy. Los clientes de ADSL hoy en día pasan todos por Telefónica, así que TODOS tienen proxy. Los de cable... pues no. Por ejemplo, ONO no tiene. Con lo cual, si estos usuarios quieren usarlos, tendrían que buscar un proxy abierto a usuarios que no sean internos del ISP, que suelen ser extranjeros. Cuanto más lejos esté el proxy-caché del cliente, peor es el rendimiento. Hay varios por ahí y todo es ponerse a buscar...
Pues eso es todo. Más nos vale a todos que esto se difunda y todo el mundo se ponga el webcaché o nos las vamos a ver oscuras por no decir negras en el futuro.
----------------------------------------------------------------------------------------------------
ACTUALIZACION CON INFORMACION UTIL PARA PODER USARLO:
NUEVA VERSION 1.2F DEL MOD WEBCACHE:
Descarga directa: eMule 0.44b WebCache 1.2f
Cambios:
Yonatan añadió: protocolo Webcache
JP arregló: detección del webcache en el primer arranque
JP añadió: preveción de falsos clientes con ID Alta del uso del proxy-test (que provocaba falsas detecciones negativas)
JP añadió: opción para apagar los mensajes de depuración de log del AICH
JP añadió: estadísticas de Webcache en el diálogo detallado del Cliente
JP añadió: estadísticas de Webcache en el diálogo detallado del archivo
JP añadió: detección de cabeceras "Proxy-Connection: close"
JP añadió: detección simple de ID Altas falsas (importante para el test de configuración del webcache) - de Netfinity
JP/Superlexx arregló: WebCache-Release
Yonatan añadió: envío de Stop-sending-OHCBs si el cliente no es de confianza nunca más
Superlexx arregló: soporte para el Pexy Transparente (espero ...)
Basicamente arregla el bug del que se habló hace tiempo de perder bloques de cola, añade estadísticas para cada cliente y cada archivo de lo que ha bajado por webcaché, arregla la fiabilidad del test para los proxys y mejora el soporte para Proxys Transparentes (los que están por delante de los proxys que usamos realmente, como el Nuria y los de Madrid y Barcelona. Habrá que probarlo).
Os recomiendo ENCARECIDAMENTE QUE LO ACTUALICEIS.
COMO CONFIGURARLO: Debes tener un MOD que implemente la opción. En las Preferencias del Emule, ve a la opción "Webcaché" y allí activa la casilla "Enable Webcached Downloads". Esto permite utilizar el webcaché tanto para las subidas como para las bajadas. En realidad las subidas ya funcionan con solo tener un MOD que incorpore el módulo de webcaché.
CONFIGURACION AUTOMATICA: en realidad no es automática. Es simplemente un fichero de Excel que lleva una pequeña base de datos con servidores que manda la gente y que se supone que funcionan como proxys para determinados grupos de IPs de los usuarios (generalmente, cada grupo es un conjunto de usuarios del mismo proveedor de Internet (ISP)). Actualmente está obsoleto y no funciona. Hay que hacer la configuración manualmente. Algunas notas sobre los proxys:
- Parece que los de Telefónica base (no sus revendedores, sino la propia Telefónica) están teniendo problemas con sus propios proxys, mientras que a los revendedores (Terra, Ya.com, Wanadoo con red de Telefónica) no les dan ningún problema. A algúnas personas se les ha solucionado reiniciando tanto su PC como su línea de ADSL a la vez.
- Para saber si eres de la red de Telefónica, haz lo siguiente:
1. Vete a Inicio>Ejecutar de tu Windows
2. Escribe "nslookup" sin las comillas y dale a Enter.
3. En la ventana de comandos que sale (siempre que no tengas muy cargada la conexión en ese momento), se cargará tu DNS primario.
4. Escribe directamente tu IP en la línea de comandos. Por ejemplo, "80.12.115.33" sin las comillas, tal cual (no esos números, sino tu IP propia!!!). Dale a Enter.
5. En las líneas que siguen te tiene que salir algo así:
Lo que sale después de Nombre es lo que debes mirar. Si termina en algo así: "rima-tde-net" entonces tu conexión pertenece a la red GIGAADSL, o sea, a Telefónica. Si no sale eso, sale otra cosa, entonces no perteneces a la red de Telefónica y tu ISP tiene red propia.
SOBRE LA IDEA EQUIVOCADISIMA DE QUE HAY QUE METERSE EN EL PROXY DONDE MAS GENTE HAYA: esto no funciona así. Es cierto que se tendrán más bloques de 180 KBs disponibles para descargar en un proxy donde haya más gente que en uno que haya menos. Pero la solución no es meterse en ese proxy todo el mundo, porque si puedes meterte desde cualquier ISP, es que el proxy es abierto, y si es abierto llegará un momento en que se colapsará y los dueños lo cerrarán, con lo cual se quedará todo el mundo tirado; sobre todo los que no pueden usar un proxy propio en su compañía ISP (por ejemplo, los de ONO, Jazztel,...). Si tú, pudiendo meterte en un proxy propio, como los de Telefónica, R, etc... te metes en el proxy abierto, tan solo para descargar más algún día, lo único que haces es perjudicar a la comunidad, pues del cierre del proxy abierto habrás tenido tú parte de culpa. Pero bueno, leechers hay en todas partes, claro.
Agrupar a la gente por ISPs es la única vía razonable de optimizar más o menos el uso de los proxys sin que se sobrecarguen. Cualquier otra en la que penséis ya la hemos pensado nosotros y NO FUNCIONARA: ni agrupar por contenidos (en este proxy ANIME, en este JUEGOS,... porque no sabemos realmente cuanta gente baja cada cosa y seguro que algún proxy caía) porque además casi nadie baja solo de un tema; ni agrupar por zonas geográficas; ni por IPs; ni por pertenencia a páginas web; ni nada de nada: la única forma con un poco de objetividad que permite homogeneizar el uso de los proxys es por proveedores, dato con el que más o menos sí que podemos intuir cuanta gente habría en cada proxy.
Lo que hay que hacer NO es meterse en el proxy donde haya más gente, sino usar el proxy de tu ISP y animar e informar a la gente de tu mismo ISP para que utilice ese mismo proxy. Ese proxy no os lo quitará nadie y con el suficiente número de usuarios dentro funcionará igual de bien que cualquier otro; incluso mejor porque estará en España, mucho más cerca que los de Reino Unido, USA y similares, ahorrando también ancho de banda a vuestro ISP que es de lo que se trata (que todos salgan ganando).
TEST DEL PROXY: la última opción del webcaché a la fecha (1.2f) introduce un testeo del proxy que estemos usando. Este testeo solo es válido (como dicen en la documentación) para proxys que NO sean transparentes, pero puede dar error en el caso de que el proxy que usemos esté a su vez detrás de un proxy transparente como el de Telefónica. Por eso, si lo usáis teniendo configurado el de Telefónica os puede dar error, funcione o no el de Telefónica con vuestro sistema.
Además, para realizar el TEST es imprescindible que la línea esté "despejada". No vale realizarlo al principio de abrir Emule porque el test dará error sin duda, aunque en realidad sea válido. El motivo es que al reiniciar Emule, la línea está colapsada haciendo intentos y peticiones de conexión y de fuentes, y todo el ancho de banda lo monopoliza. Hacer el test en ese momento implica que las peticiones que realiza el test se diluyan en las que realiza Emule y al final salga negativo. Para que el resultado sea más o menos fiable, el test hay que hacerlo pasado un buen rato de abierto Emule, CUANDO EMULE HAYA ENCONTRADO TODAS LAS FUENTES POSIBLES. Esto se puede ver en el gráfico de conexiones en Estadísticas: cuando haya bajado por debajo de 80 conexiones o así, entonces el test es cuando puede salir bien.
La condición de que el TEST salga correcto es SUFICIENTE pero NO NECESARIA. Es decir, si el test sale correcto, el proxy funciona. Pero si el test sale erróneo, el proxy puede que funcione o puede que no, no es seguro.
Si el Test sale erróneo, te obliga a desconectar el webcaché hasta que reinicies Emule, así que no lo uséis sin razón o tendréis que reiniciar Emule si os da resultado erróneo, para poder seguir usando el webcaché.
EL ARCHIVO CSV: Webcache Proxies. Este es el archivo de autoconfiguración de los proxys, y ahora mismo no sirve para nada porque ni está actualizado ni funciona el link, así que olvidaos de él. El webcaché hay que configurarlo manualmente.
LA PESTAÑA TRAFICO: para ver el webcaché funcionando, hay que activar la columna "Webcaché" en la ventana de downloads (click derecho en las cabeceras de las columnas y marcamos con un tick la opción de webcaché). Veremos varios datos:
Sin desplegar, aparece el # de fuentes que tienen el webcaché (activado o no), y el % que suponen con respecto al total de fuentes de ese archivo.
Desplegando el archivo, se ve en cada fuente si tienen proxy o no, y qué proxy tienen. Las opciones son:
- En blanco: no tienen la opción de poner proxy webcaché.
- "No proxy set": tienen opción de poner el webcaché, pero no lo tienen activado en Preferencias.
- Nombre del proxy: tienen activado el webcaché y ese es el proxy que están usando.
Las nuevas versiones del webcache, a partir de la 1.2e tienen un código de 3 números en la columna, con este formato: xx/yy/zz (##%), donde:
- xx = nº de fuentes totales con posibilidad de poner webcaché en ese archivo.
- yy = nº de fuentes con el mismo proxy que nosotros.
- zz = nº de fuentes con otro proxy distinto al nuestro
- ## = tanto por ciento de fuentes que tienen la posibilidad de usar webcaché con respecto al total.
OTROS ERRORES: a veces a alguien le ha salido ID Baja al conectar por primera vez el webcaché e intentar conectarse a los servidores de edonkey. Se ha solucionado reiniciando el PC, o bien reseteando la línea de ADSL o cable.
ESTADISTICAS: se puede ver cómo ha funcionado el webcaché en las ramas:
NO HAY ESTADISTICAS DE UPLOAD POR EL MOMENTO, SOLO DE DOWNLOAD. No se puede saber lo que has subido a un proxy, solo lo que te has bajado de un proxy.
Descargas>Sesion>Datos Descargados>Clientes>Webcaché : para ver lo que hemos descargado vía webcaché en esta sesión de Emule.
Descargas>Acumulado>Datos Descargados>Clientes>Webcaché : para ver lo que se ha descargado vía webcaché en total.
Descargas>Sesion>Sesiones de Descarga>Successful WC-DL/WC-Requests : esto indica el % de trocitos del caché de los que hemos tenido noticia y hemos bajado correctamente con respecto al total de trocitos de los que hemos tenido noticia. Evidentemente las tasas de éxito deberían estar cercanas al 100% para un funcionamiento óptimo.
Además, desde la versión 1.2f se puede ver cuántos bloques de has bajado via proxy de cada archivo y de cada usuario, mirando la información de las propiedades de cada uno. Hay una línea que pone "WC-Downloads" en la info de cada archivo que NO FUNCIONA AUN, porque no la han implementado, no porque funcione mal el webcache.
EL FICHERO DE TEST PARA DESCARGAR: tiene este elink: ed2k://|file|Webcache Emule Test.file|1078989657|E9057ADC38054AFA24816E86BB08D270|/ Solo sirve para eso, para testear que se puede usar el webcaché y que funciona, porque todo el que se está bajando este fichero tiene (o debería tener) activado el webcaché. No tiene ninguna otra función, pero conviene que lo dejéis bajando al menos un día para comprobar que funciona con las opciones de configuración seleccionadas y cuánto supone con respecto al total de lo que tienes descargando (a no ser que tengas muchas cosas y vayan rápido, en cuyo caso apenas notarás el webcaché porque tendrás toda tu línea copada por el resto de descargas).
MODs QUE LO SOPORTAN: hacer una lista de esto es una tarea bastante ardua y tediosa, pero ahí van 2 ó 3:
eMule Webcache
eMule Pawcio (discontinuada)
eMule MorphXT v7.1 (la 7.2 actualmente da problemas)
eMule Phoenix (discontinuada)
Para estar al día, nada mejor que pasarse por el Site de Soporte de Spanishare: Soporte Spanishare (necesitas estar logueado para descargar Binarios).
Importante: los MODs que incorporan la versión de webcaché 1.2c y anteriores no funcionan bien, y por lo tanto no notaréis apenas que descargáis algo. Utilizad los MODs que incorporan la versión 1.2d del webcaché y posteriores.
¿DEBEMOS PONERNOS TODOS EL MISMO PROXY?: la respuesta más adecuada es que NO. Debes ponerte el que te corresponda según tu ISP. Si no te pones el que te corresponde, y te dedicas a usar el mismo que el resto de la gente, lo que vas a conseguir es que haya tanta gente metida en los proxys abiertos que al final los cierren y dejen tirados a los usuarios que por no disponer de proxy propio en su ISP no pueden utilizar otro, mientras que tú si puedes usar el de tu ISP. Como eso nos perjudica a todos (pensad a largo plazo, por favor), hay que intentar meterse todos en proxys propios para "desmasificar" los proxys abiertos y que aguanten el máximo de tiempo posible online.
Al final terminarán chapando los proxys abiertos y los que no puedan usar uno propio de su ISP se tendrán que buscar la vida, así que pensad un poco en la comunidad y usad el que os corresponde.
LAS OPCIONES AVANZADAS DEL WEBCACHE: yo no soy experto en estos temas, pero voy a intentar explicar lo que hace cada una:
- Number of Blocks to download before reconnecting to the proxy: esta opción ayuda en algúnos proxys que pueden dejar de responder antes de tiempo, por lo que se puede obligar a Emule a reconectar con ellos tras bajar 1, 2, 3... o los que sea, bloques de 180 KB. No parece que haga falta en los proxys que se están manejando aquí en España, y en cualquier caso la autoconfiguración ya pone la opción adecuada (siempre que la autoconfiguración esté correcta, claro - léase el caso ONO). El valor 0 es como decirle que lo deje en "automático", que es lo más aconsejable.
- Extra long Timeout for webcaché connections: algo parecido a lo anterior, permite tiempos de espera más largos a la hora de establecer conexiones con el proxy. No parece que haga falta en los proxys que se manejan en España.
- This webcaché does NOT cache traffic within the same ISP: sería el caso por ejemplo de que en el proxy de Telefónica no se cacheara el tráfico que viene de dentro de Telefónica, o sea, su tráfico interno. Ahora mismo esto no es así, es decir, el proxy de Telefónica lo cachea todo, tanto lo que se pide de fuera como lo que se pide de otros usuarios o páginas web de dentro de la red de Telefónica. Así que no hace falta marcarla. Existen proxys que no cachean el tráfico interno, y por eso existe la opción. Según parece, el proxy abierto cache4 también permite cachear el tráfico interno, así que tampoco hay que marcarla actualmente.
- Persistent connections for proxy downloads: esta opción se impuso porque algúnos servers extranjeros permiten mantener la conexión para seguir descargando el siguiente trozo de 180 KBs sin necesidad de cortarla como hace el proxy de Telefónica. Pero si usas un server que hace una petición cada vez que baja un trozo (como el de Telefónica), lo que se consigue al activar esta opción es que se pierdan bloques de la cola de descarga desde el proxy, así que es MUY PERJUDICIAL para la continuidad y la estabilidad en la descarga por webcaché el activar esta opción si el proxy no la soporta. Repito: el proxy nuria de Telefónica no soporta la opción, por lo que activarla es perjudicial.
---------------------------------------------------------------------------------------------------
ZONA DE CONOCIMIENTOS AVANZADOS
Para el usuario normal esto ya no tiene ninguna importancia, así que si no os interesa, podéis pasar del tema.
ACTIVAR EL LOG DEL FUNCIONAMIENTO INTERNO DEL WEBCACHE: nos vamos a Preferencias>Opciones Adicionales>Información Extra y activamos tanto la casilla de activación como la de "Log Webcache Events". Además, desactivamos el resto de casillas si es que hay algúna más marcada, porque si no el log será un lío impresionante.
Con eso obtenemos una nueva pestaña en el botón de Servidores, al lado del Registro de Emule llamada "Verbose", que nos irá mostrando todo lo que hace el Webcaché.
ALGUNOS COMANDOS NORMALES DEL LOG:
Proxy-Connections for this file: 0 Allowed: 5 -> Indica cuántas conexiones tiene abiertas para un determinado archivo. Normalmente no subirá de 1 ó 2. No se puede saber a qué archivo corresponde directamente. Mostrará 2 conexiones si estamos bajando por webcaché un archivo que estemos subiendo por webcaché a alguien al mismo tiempo.
Received WCBlock - UDP: alguien te ha informado de que se acaba de descargar un bloque de 180 KB vía proxy-caché y puedes descargártelo tú también si te interesa (esto lo decide el Emule, claro).
CWebCachedBlock: proxy-ip=AAA, host-ip=BBB, host-port=CCC, filehash=DDD, start=EEE, end=FFF, key=GGG
"Mensaje de bloque". Informa del bloque que ha encontrado en el proxy. Significa:
- AAA = la IP de tu proxy.
- BBB = la IP del usuario que pasa el trozo de 180 KB originalmente (el uploader)
- CCC = el puerto del que pasa el trozo originalmente
- DDD = el hash de ese fichero (permite reconocer a qué archivo corresponde de nuestra lista mirándolo)
- EEE = dirección de inicio del trozo en bytes dentro del archivo
- FFF = dirección final del trozo. Tiene que ser 184320 bytes (180 KBs) mayor que la anterior, claro.
- GGG = clave de desencriptación del HTTP.
CWebCachedBlock::~CWebCachedBlock(): blocks on queue: X -> Esto es un mensaje recordatorio que aparece de cuando en cuando para ver cuántos bloques llevamos en la cola interna del webcaché. También aparece justo después del "mensaje de bloque" encontrado si dicho bloque no nos vale para nuestros archivos porque ya lo tengamos descargado por otras vías.
CWebCachedBlock:: DownloadIfPossible(): blocks on queue: 0 -> Nos sale después de un "mensaje de bloque" si el bloque nos vale para nuestras descargas porque no lo tenemos aún. Comienza a descargar en la pestaña de Tráfico del Emule.
CWebCachedBlock:: DownloadIfPossible(): blocks on queue: X -> igual que el anterior, pero ya tenemos algo en la cola, y por lo tanto no entra a descargar directamente.
CWebCachedBlockList::AddTail called, queue length: X -> Sale después de un "mensaje de bloque" si el bloque nos vale para nuestras descargas pero ya estamos descargando otro bloque, luego pone el bloque nuevo a la cola interna ("tail") en el puesto X. En cuanto terminemos el bloque que estemos descargando, el número 1 de la cola interna pasará a entrar en descarga. Si esta cola es suficientemente larga, la descarga es muy continua y apenas se notan las pausas entre bloques. Si no es muy larga, se acaba rápido y si no hay cola, no hay descarga -> aparecen pausas entre bloques.
WebCachedBlock added to queue: confirma el mensaje anterior.
WCBlock sent to client - UDP: envía información a otros usuarios conectados a nosotros de que acabamos de recibir vía-proxy un trozo de 180 KBs que ellos pueden necesitar, y que lo tienen disponible en el proxy.
new CWebCacheDownSocket: ProxyConnectionCount=X: cada vez que tiene una conexión ocupada porque estemos bajando algo con ella, porque estemos subiendo algo con ella, o porque estemos a la escucha de los bloques que nos informen otros usuarios, abre una nueva para estar alerta, haciendo la número X del total.
deleted CWebCacheDownSocket: ProxyConnectionCount=X: es el mensaje que cierra la anterior si no se necesita más.
Cached block downloaded from proxy!!!: acaba de descargar un bloque de 180 KBs completo.
WebCache: Socket closed unexpedtedly, trying to reestablish connection -> Mensaje de error que sale en las versiones actuales del webcaché por un bug y que se espera puedan solucionar los programadores en el futuro. No obstante, en algúnos usuarios podría ser síntoma de que algo va mal con su proxy, porque es un mensaje genérico de que no ha podido establecer conexión con el proxy adecuadamente.
RECONNECTING ProxyClient!!: En ciertos proxys como el de Telefónica, cada vez que termina de descargar un bloque y tiene algún otro en cola, dice esto. La razón es que el proxy de Telefónica no permite descargar más de un bloque por conexión, y hay que cerrarla y abrirla cada vez que pone un nuevo bloque a descargar. No tiene más importancia, salvo que puede suponer un poco de tiempo perdido entre bloque y bloque.
Received cached block info from unknown client (UDP) -> Según me han dicho los desarrolladores, esto sale cuando se ha cerrado y abierto el Emule recientemente, o cuando se ha pausado o detenido un archivo que tenía muchas peticiones vía-proxy, pues nos siguen mandando información de esos trozos que no podemos aprovechar por estar pausados los archivos, y nos los mandan gente a la que ya no tenemos de fuente (y por eso son "unknown" = desconocidos) por haber detenido el archivo.
BUGS CONOCIDOS: el bug más gordo actualmente aparece cuando tenemos 2 ó más trozos disponibles en la cola y terminamos de descargar el bloque que estuviéramos descargando en ese momento. Entonces pone a descarga el bloque #1 de la cola, pero inexplicablemente tira el bloque #2 y aparece el mensaje de error comentado antes. Esto provoca que la tasa de éxitos sea cercana al 50%, algo por encima ya que el bug no aparece si no hay nada en cola o solo hay 1 trozo disponible, por lo que en estos casos sí que se descargan los bloques sin problemas según llegan. Se espera que lo resuelvan los programadores en la próxima versión, pues ahora mismo lo tienen todas (incluida la 1.2e).
Otro bug algo menos molesto es el siguiente. Os pego lo que nos dice Dragonfire_2000:
PEQUEÑA DISCUSION SOBRE EL EFECTO DE ESTE "INVENTO" SOBRE LOS PROXYS: en mi opinión ocurre lo siguiente. Supongamos para simplificar 3 proveedores: Telefónica, PSI (la del cache4 abierto) y ONO. Los 2 primeros tienen proxy, el de PSI abierto, y ONO no tiene proxy propio.
Un ISP paga por tráfico recibido y cobra por tráfico enviado. Eso quiere decir que los sentidos de tráfico Telefónica->PSI y Telefónica->ONO hacen ganar dinero a Telefónica, mientras que los sentidos PSI->Telefónica y ONO->Telefónica le hacen perder dinero a Telefónica. Cada uno de esos tráficos en ausencia de proxys se realiza UNA VEZ por cada usuario que quiere pedir algúna página o trozo de 180 KBs que pertenece a la red de la competencia. Si hay 100 usuarios que piden ese trozo de 180 KBs (bloque) de un usuario de PSO o de ONO se hacen 100 peticiones a PSI o a ONO desde Telefónica, y Telefónica tiene que pagar 100 veces el coste de esa transferencia. Si se hacen en sentido contrario sucede al revés, y es Telefónica la que cobra de esos proveedores. En teoría estos cruces están más o menos desequilibrados en beneficio de los mayores proveedores, pues son los que más líneas manejan y los que más páginas y bloques pueden servir al resto, por tanto.
Si ahora Telefónica pone proxy propio, los sentidos PSI->Telefónica y ONO->Telefónica solo se producen 1 UNICA VEZ, la inicial, cuando el primer usuario de Telefónica pide al usuario externo el bloque que necesita. Los 99 usuarios restantes ya no se lo piden al usuario externo, se lo bajan del proxy; y por lo tanto, Telefónica se ahorra 99 veces el coste de la transferencia.
Pero resulta que en los sentidos contrarios, si no hay proxy, ONO y PSI tienen que seguir pagando 100 veces el coste de la transferencia Telefónica->PSI o Telefónica->ONO. Por lo cual, Telefónica sale ganando claramente, ya que ella solo va a pagar 1 transferencia gracias a su proxy, y a cambio va a cobrar 100 transferencias, por aquellos ISPs que no tengan proxy. Este es el caso de ONO, y en general cualquier otro ISP que no tenga proxy propio. O lo ponen o van a perder dinero, porque las transferencias hacia Telefónica se van a reducir drásticamente por los proxys, mientras que en sentido contrario, las que le hacen perder dinero a ONO se mantienen (al no haber proxy). El balance deja de estar "equilibrado" como antes y claramente favorece a aquel proveedor que tiene proxy. Es la razón principal de que Telefónica pusiera su proxy transparente.
Telefónica tiene un tráfico interno que le cuesta muy poco y se supone además que ya está sufragado por las cuotas de sus abonados, igual que las de cualquier otro ISP.
Ahora metamos el proxy abierto de PSI (cache4) en la ecuación. Este proxy está en el Reino Unido (UK), pero es abierto, lo que significa que lo pueden utilizar más usuarios aparte de sus propios clientes. Los usuarios de ONO lo están usando ahora mismo porque no tienen proxy propio. Pues vamos a ver. Si un usuario de ONO pide que uno de Telefónica o de ONO le suba un bloque al proxy y otros 99 se lo van a descargar ocurre lo siguiente:
- Si el bloque es de un usuario de ONO, el bloque hace el trayecto ONO->PSI una sola vez, pero luego hace el trayecto PSI->ONO 100 veces, con lo que el balance le sale a ONO que tiene que pagar 98 transferencias netas. ¿Y a PSI? Bueno, habría que echar números, porque con dejar que el resto de ISPs usen su proxy está ganando dinero (como acabamos de ver), pero al mismo tiempo está sobrecargando su máquina, que le costará dinero. Es un balance del que habría que echar números, pero no sería de extrañar que le saliera positivo al proxy abierto y por eso dejen usar el proxy desde fuera.
- Si el bloque es de un usuario de Telefónica, el bloque hace el trayecto Telefónica->PSI una sola vez y luego el trayecto PSI->ONO 100 veces. Curioso este caso, porque PSI ahora tiene que pagar 1 transferencia a Telefónica, y ONO tiene un balance negativo de 100 transferencias. Con este tipo de transferencias ONO pierde incluso más que antes.
Con lo que usar el proxy abierto en principio el efecto que tiene es que sobre los proveedores que lo utilicen se generará un recargo gigantesco de transferencias que se podían haber ahorrado si tuvieran proxy propio. Y sobre el mismo proxy, pues no se puede saber a priori: puede que le convenga si le sale más rentable cobrar por transferencias que dejar sobrecargar la máquina; o puede que no le convenga. Lo que está claro es que a ONO y al resto que no tienen proxy propio les convendría poner uno o van a perder mucha pasta...
________________________________________________________________________________________
Eso es todo lo que hay por ahora. Saludos.
(post por Ryderark, de Spanishare.com - Última edición: 10/11/2004 )
Otra web con ayuda y proxies webcache:
Código:
http://webcache.6x.toEste hilo se irá actualizando poco a poco con la información que se conozca en cada momento con respecto a la función webcaché.
- Para preguntar cosas específicas sobre los Proxies, no sobre la función webcaché, pásate por el HILO DE PROXIES.
- Para preguntar DUDAS específicas sobre la función webcaché QUE NO VENGAN YA RESUELTAS AQUI, pásate por el HILO DE DUDAS. Eso sí, ¡¡¡LEETE ESTE HILO ANTES DE POSTEAR ALLI!!!!
_______________________________________________________________________________________
¿Qué es Webcache? Es una nueva opción que incorporan los últimos MODs de Emule basados en las versiones oficiales 0.44. En realidad es un MOD llamado directamente así, webcache, que ha sido implementado en las últimas versiones de otros MODs como Pawcio o Phoenix. Las versiones oficiales no lo implementan aún, y los desarrolladores de la versión oficial han dicho que no lo van a meter por ahora, para no tener problemas legales, pero eso no significa que no sea una característica muy beneficiosa para la comunidad Ed2k en general.
¿En qué consiste Webcache? Bueno, es algo un poco difícil de explicar y largo, pero básicamente consiste en que cuando quieres bajar de alguien un trocito, en lugar de decirle que te lo pase directamente ese alguien, le vas a decir que te lo suba a un proxy-caché. Esto es una máquina como la que puso Telefónica hace meses, que permite "guardar" en la memoria de la máquina lo que acaba de pasar por ella en tránsito de un PC a otro. El motivo es que, si ahora otro usuario le pide al usuario fuente inicial el mismo trozo de archivo el primer usuario que recibio el trozo le va a decir "mira, mejor pídeselo al proxy-caché, que lo tiene en memoria y es mucho más rápido que el uploader". El usuario 2 se lo pide entonces al proxy caché y se baja el archivo a la velocidad del rayo sin gastar ancho de banda del uploader.
Esas máquinas proxy tienen un ancho de banda gigantesco, más que cualquier conexión actual entre usuarios, y es por eso que te permiten bajar al máximo de tu velocidad siempre que no se colapsen. Generalmente se utilizan para ahorrar tráfico de datos a las compañías telefónicas en la navegación por Internet. Es decir, cuando tú pides una página web, pasa por el proxy-caché y se queda allí grabada. Si otro pide la misma página, el proxy se la manda y así no tiene que pedirla 2 veces al sitio remoto, ahorrando tráfico. Ahora se va a sustituir el server de la página web remota por un usuario Emule, pero la base es la misma.
¿Qué ventajas tiene eso? Ventajas fundamentales. Vamos a ver:
1. La velocidad de transmisión de datos se multiplicará por cientos, ya que lo que antes tenía como límite la velocidad de subida de CADA usuario respecto a quien bajaba, ahora el único límite es la velocidad de subida del PRIMER usuario. Es perfectamente factible que en el tiempo que tarda en subir un archivo el compartidor inicial, se lo hayan bajado 100 personas o más, sin tiempos de espera de colas ni nada.
2. Esto también conviene a las compañías que gestionan el servicio de banda ancha, en especial a las de ADSL, tanto a las vendedoras primarias (Telefónica) como a las de reventa (Ya.com, Wanadoo,...). Si disminuye el tráfico externo, las primeras ahorran ancho de banda y tener que pagar a otros proveedores por descargar cosas de su red más de una vez, y las segundas ahorran porque deben pagar propocionalmente al tráfico soportado. De modo que a ellas también les conviene.
3. Con las últimas versiones del webcaché se puede usar también el famoso proxy de Telefónica en todos aquellos usuarios que pertenezcan a su red (que se llama GIGAADSL). Por lo tanto, no se necesitará buscar un proxy adicional, basta con el que Telefónica ya tiene implementado.
4. Cuando los usuarios bajan de un proxy-cache, evidentemente ya no bajan del usuario inicial el mismo trozo, con lo que el ancho de banda de este último queda libre para subir a otros usuarios o a otros proxys, optimizando la red. Pensad que, en realidad, es como si ahora hubiera nuevos servers que no solo conectan a los usuarios entre sí, sino que además aceleran bestialmente el tramo de tráfico desde ellos hacia el resto de usuarios que van a recibir un archivo. El usar webcaché beneficia también a aquellos que no lo usen, porque les quedarán más slots de descarga libres en el resto de usuarios.
5. Por último, y es lo que me lleva a escribir esto, a partir de Octubre de 2004 comienzan a doblar la velocidad de las líneas básicas de ADSL en España, pero no lo hacen en la subida (upload); solo en la bajada (download). En las líneas de gama alta si suben el upload, pero no es proporcional al aumento experimentado por el download correspondiente. Como ejemplos:
- ADSL 256/128 sube a 512/128. El upload queda igual y el download sube al doble.
- Nuevas líneas de 1024/300. Si pasamos a esta desde una 256/128, el upload se multiplica por 2.34, pero el download se multiplica por 4, con lo que proporcionalmente el download sube más que el upload. Igual si subimos desde una 512/256.
- En cable pasa lo mismo, en aquellas conexiones en que sube el upload también, el download aumenta proporcionalmente mucho más.
De lo que se deduce que, en las próximas semanas vamos a experimentar un problema de ahogo del upload total común de todos los usuarios con respecto al download. Las líneas son asimétricas, y el download siempre es mucho mayor que el upload. Hasta ahora la cosa más o menos se mantenía gracias a la interconexión de bajadas de archivos extranjeros (que tienen mucho mejores líneas) para que todo el mundo bajara con una media bastante cercana a su máximo de download, cuya diferencia con el upload total era suplida por esas líneas extranjeras, algúnas de ellas simétricas y otras tan anchas que no notarían la diferencia.
No hay que olvidar que la red Emule es cerrada, salvo algúnos clientes Shareaza y unos pocos intentos por desarrollar un plug-in para bittorrent. Eso significa que todo lo que se está descargando en la red a cada momento, proviene de los mismos usuarios que están descargando, usuarios que están subiendo datos al mismo tiempo. La cantidad de datos posible para descargar es la misma que se está subiendo a cada momento y no hay más.
En las próximas semanas vamos a llegar a un escenario bastante menos halagüeño que el actual. Por decirlo con una metáfora: el pastel de datos se va a agrandar un poco, no demasiado (porque hay líneas que no aumentan su upload), pero el estómago de los comensales va a crecer al menos al doble, y en algúnos casos puede que más, con respecto al aumento de pastel. Si el pastel no aumenta en la misma proporción que el hambre de los comensales, está claro que los comensales van a tener que repartirse el pastel como buenos hermanos, o puede que llegue algúno que se hinche la tripa llena y deje SIN NADA a otros. Ahora podía pasar, que alguien, por ejemplo con una ADSL 256/128, bajara a 27 KB/s y otro no pasara de 8, cuando la media de upload son 10-12 KB/s; esto quedaba más o menos compensado por el intercambio de archivos con el extranjero, como ya he comentado. Pero si en el futuro el que bajaba a 27 va a bajar a 53 sin aumentar su upload para compensar; o si va a bajar a 110 KB/s sin aumentar su upload más que de 10 a 25, os podéis imaginar que alguien se va a quedar sin su trozo de pastel. Y eso, con líneas dobladas en velocidad, va a sentar muy muy mal a más de uno.
¿Cuál es la solución? El WEBCACHE. El webcache permitiría si conseguimos implantarlo en suficientes fuentes que todo el mundo descargue a velocidades de vértigo aún cuando los uploads no suban demasiado. Es como si tuviéramos un pastelero al lado de la tarta que, para cada trocito que se saque de tarta, él va a fabricar cientos iguales. Todos los comensales podrán hartarse llenando sus estómagos por grandes que sean. Pero si no lo hacemos, es posible que comiencen los problemas.
Dado que todo son ventajas y solo hay algún inconveniente (que comentaré más tarde), os animo a que TODOS comencéis a usar una de estas versiones que permiten webcaché. Cuantas más personas estén usando el webcaché, mejor funciona el tema, pues todo el mundo está en condiciones tanto de recibir como de enviar datos a los proxy-cachés, y estos dispondrán de muchos más trocitos que enviar y recibir para aumentar la velocidad.
¿Cómo se utiliza? Bueno, es muy fácil. En esas versiones MOD de Emule que digo, hay una nueva opción en preferencias llamada precisamente Webcaché. Hay que activarlo ("Enabled"). Tiene varias opciones. De las opciones que vienen al pulsar el botón de "Opciones Avanzadas" podéis olvidaros porque no sirven para nada en las líneas de España. Las casillas "proxy" y "puerto" hay que configurarlas manualmente, con los proxys que funcionen. Para saber cómo configurar esas 2 casillas, pasaos por estas 2 webs:
Código:
http://www.webcache.cjb.net
http://webcacheproxys.cjb.netLuego hay que apagar Emule y volverlo a reiniciar, con lo que ya empezaremos a estar en condiciones de subir y bajar datos desde proxys-caché. No hay que andar pulsando el botón de Autoconfiguración porque ahora mismo NO funciona en condiciones, hay que hacerlo de forma manual.
Funciona un poco a saltos, porque las versiones actuales solo suben y bajan trocitos de 180 KBs cada vez, así que funciona como un muelle, dándote picos de bajada cada pocos segundos. Se puede ver quién tiene webcaché activado en una nueva categoría de la pestaña de Tráfico. No obstante, si hubiera el suficiente número de fuentes subiendo por webcaché el resultado para todos sería mucho más continuo y estable, ya que la descarga desde el proxy iría saltando de un bloque de 180 KBs a otro casi ininterrumpidamente y no se notarían las pausas entre pico y pico, con lo que no habría picos, solo una "meseta".
Y por último, los inconvenientes. El problema es que no todas las compañías que ofrecen banda ancha en España tienen un proxy. Los clientes de ADSL hoy en día pasan todos por Telefónica, así que TODOS tienen proxy. Los de cable... pues no. Por ejemplo, ONO no tiene. Con lo cual, si estos usuarios quieren usarlos, tendrían que buscar un proxy abierto a usuarios que no sean internos del ISP, que suelen ser extranjeros. Cuanto más lejos esté el proxy-caché del cliente, peor es el rendimiento. Hay varios por ahí y todo es ponerse a buscar...
Pues eso es todo. Más nos vale a todos que esto se difunda y todo el mundo se ponga el webcaché o nos las vamos a ver oscuras por no decir negras en el futuro.
----------------------------------------------------------------------------------------------------
ACTUALIZACION CON INFORMACION UTIL PARA PODER USARLO:
NUEVA VERSION 1.2F DEL MOD WEBCACHE:
Descarga directa: eMule 0.44b WebCache 1.2f
Cambios:
Yonatan añadió: protocolo Webcache
JP arregló: detección del webcache en el primer arranque
JP añadió: preveción de falsos clientes con ID Alta del uso del proxy-test (que provocaba falsas detecciones negativas)
JP añadió: opción para apagar los mensajes de depuración de log del AICH
JP añadió: estadísticas de Webcache en el diálogo detallado del Cliente
JP añadió: estadísticas de Webcache en el diálogo detallado del archivo
JP añadió: detección de cabeceras "Proxy-Connection: close"
JP añadió: detección simple de ID Altas falsas (importante para el test de configuración del webcache) - de Netfinity
JP/Superlexx arregló: WebCache-Release
Yonatan añadió: envío de Stop-sending-OHCBs si el cliente no es de confianza nunca más
Superlexx arregló: soporte para el Pexy Transparente (espero ...)
Basicamente arregla el bug del que se habló hace tiempo de perder bloques de cola, añade estadísticas para cada cliente y cada archivo de lo que ha bajado por webcaché, arregla la fiabilidad del test para los proxys y mejora el soporte para Proxys Transparentes (los que están por delante de los proxys que usamos realmente, como el Nuria y los de Madrid y Barcelona. Habrá que probarlo).
Os recomiendo ENCARECIDAMENTE QUE LO ACTUALICEIS.
COMO CONFIGURARLO: Debes tener un MOD que implemente la opción. En las Preferencias del Emule, ve a la opción "Webcaché" y allí activa la casilla "Enable Webcached Downloads". Esto permite utilizar el webcaché tanto para las subidas como para las bajadas. En realidad las subidas ya funcionan con solo tener un MOD que incorpore el módulo de webcaché.
CONFIGURACION AUTOMATICA: en realidad no es automática. Es simplemente un fichero de Excel que lleva una pequeña base de datos con servidores que manda la gente y que se supone que funcionan como proxys para determinados grupos de IPs de los usuarios (generalmente, cada grupo es un conjunto de usuarios del mismo proveedor de Internet (ISP)). Actualmente está obsoleto y no funciona. Hay que hacer la configuración manualmente. Algunas notas sobre los proxys:
- Parece que los de Telefónica base (no sus revendedores, sino la propia Telefónica) están teniendo problemas con sus propios proxys, mientras que a los revendedores (Terra, Ya.com, Wanadoo con red de Telefónica) no les dan ningún problema. A algúnas personas se les ha solucionado reiniciando tanto su PC como su línea de ADSL a la vez.
- Para saber si eres de la red de Telefónica, haz lo siguiente:
1. Vete a Inicio>Ejecutar de tu Windows
2. Escribe "nslookup" sin las comillas y dale a Enter.
3. En la ventana de comandos que sale (siempre que no tengas muy cargada la conexión en ese momento), se cargará tu DNS primario.
4. Escribe directamente tu IP en la línea de comandos. Por ejemplo, "80.12.115.33" sin las comillas, tal cual (no esos números, sino tu IP propia!!!). Dale a Enter.
5. En las líneas que siguen te tiene que salir algo así:
Lo que sale después de Nombre es lo que debes mirar. Si termina en algo así: "rima-tde-net" entonces tu conexión pertenece a la red GIGAADSL, o sea, a Telefónica. Si no sale eso, sale otra cosa, entonces no perteneces a la red de Telefónica y tu ISP tiene red propia.
SOBRE LA IDEA EQUIVOCADISIMA DE QUE HAY QUE METERSE EN EL PROXY DONDE MAS GENTE HAYA: esto no funciona así. Es cierto que se tendrán más bloques de 180 KBs disponibles para descargar en un proxy donde haya más gente que en uno que haya menos. Pero la solución no es meterse en ese proxy todo el mundo, porque si puedes meterte desde cualquier ISP, es que el proxy es abierto, y si es abierto llegará un momento en que se colapsará y los dueños lo cerrarán, con lo cual se quedará todo el mundo tirado; sobre todo los que no pueden usar un proxy propio en su compañía ISP (por ejemplo, los de ONO, Jazztel,...). Si tú, pudiendo meterte en un proxy propio, como los de Telefónica, R, etc... te metes en el proxy abierto, tan solo para descargar más algún día, lo único que haces es perjudicar a la comunidad, pues del cierre del proxy abierto habrás tenido tú parte de culpa. Pero bueno, leechers hay en todas partes, claro.
Agrupar a la gente por ISPs es la única vía razonable de optimizar más o menos el uso de los proxys sin que se sobrecarguen. Cualquier otra en la que penséis ya la hemos pensado nosotros y NO FUNCIONARA: ni agrupar por contenidos (en este proxy ANIME, en este JUEGOS,... porque no sabemos realmente cuanta gente baja cada cosa y seguro que algún proxy caía) porque además casi nadie baja solo de un tema; ni agrupar por zonas geográficas; ni por IPs; ni por pertenencia a páginas web; ni nada de nada: la única forma con un poco de objetividad que permite homogeneizar el uso de los proxys es por proveedores, dato con el que más o menos sí que podemos intuir cuanta gente habría en cada proxy.
Lo que hay que hacer NO es meterse en el proxy donde haya más gente, sino usar el proxy de tu ISP y animar e informar a la gente de tu mismo ISP para que utilice ese mismo proxy. Ese proxy no os lo quitará nadie y con el suficiente número de usuarios dentro funcionará igual de bien que cualquier otro; incluso mejor porque estará en España, mucho más cerca que los de Reino Unido, USA y similares, ahorrando también ancho de banda a vuestro ISP que es de lo que se trata (que todos salgan ganando).
TEST DEL PROXY: la última opción del webcaché a la fecha (1.2f) introduce un testeo del proxy que estemos usando. Este testeo solo es válido (como dicen en la documentación) para proxys que NO sean transparentes, pero puede dar error en el caso de que el proxy que usemos esté a su vez detrás de un proxy transparente como el de Telefónica. Por eso, si lo usáis teniendo configurado el de Telefónica os puede dar error, funcione o no el de Telefónica con vuestro sistema.
Además, para realizar el TEST es imprescindible que la línea esté "despejada". No vale realizarlo al principio de abrir Emule porque el test dará error sin duda, aunque en realidad sea válido. El motivo es que al reiniciar Emule, la línea está colapsada haciendo intentos y peticiones de conexión y de fuentes, y todo el ancho de banda lo monopoliza. Hacer el test en ese momento implica que las peticiones que realiza el test se diluyan en las que realiza Emule y al final salga negativo. Para que el resultado sea más o menos fiable, el test hay que hacerlo pasado un buen rato de abierto Emule, CUANDO EMULE HAYA ENCONTRADO TODAS LAS FUENTES POSIBLES. Esto se puede ver en el gráfico de conexiones en Estadísticas: cuando haya bajado por debajo de 80 conexiones o así, entonces el test es cuando puede salir bien.
La condición de que el TEST salga correcto es SUFICIENTE pero NO NECESARIA. Es decir, si el test sale correcto, el proxy funciona. Pero si el test sale erróneo, el proxy puede que funcione o puede que no, no es seguro.
Si el Test sale erróneo, te obliga a desconectar el webcaché hasta que reinicies Emule, así que no lo uséis sin razón o tendréis que reiniciar Emule si os da resultado erróneo, para poder seguir usando el webcaché.
EL ARCHIVO CSV: Webcache Proxies. Este es el archivo de autoconfiguración de los proxys, y ahora mismo no sirve para nada porque ni está actualizado ni funciona el link, así que olvidaos de él. El webcaché hay que configurarlo manualmente.
LA PESTAÑA TRAFICO: para ver el webcaché funcionando, hay que activar la columna "Webcaché" en la ventana de downloads (click derecho en las cabeceras de las columnas y marcamos con un tick la opción de webcaché). Veremos varios datos:
Sin desplegar, aparece el # de fuentes que tienen el webcaché (activado o no), y el % que suponen con respecto al total de fuentes de ese archivo.
Desplegando el archivo, se ve en cada fuente si tienen proxy o no, y qué proxy tienen. Las opciones son:
- En blanco: no tienen la opción de poner proxy webcaché.
- "No proxy set": tienen opción de poner el webcaché, pero no lo tienen activado en Preferencias.
- Nombre del proxy: tienen activado el webcaché y ese es el proxy que están usando.
Las nuevas versiones del webcache, a partir de la 1.2e tienen un código de 3 números en la columna, con este formato: xx/yy/zz (##%), donde:
- xx = nº de fuentes totales con posibilidad de poner webcaché en ese archivo.
- yy = nº de fuentes con el mismo proxy que nosotros.
- zz = nº de fuentes con otro proxy distinto al nuestro
- ## = tanto por ciento de fuentes que tienen la posibilidad de usar webcaché con respecto al total.
OTROS ERRORES: a veces a alguien le ha salido ID Baja al conectar por primera vez el webcaché e intentar conectarse a los servidores de edonkey. Se ha solucionado reiniciando el PC, o bien reseteando la línea de ADSL o cable.
ESTADISTICAS: se puede ver cómo ha funcionado el webcaché en las ramas:
NO HAY ESTADISTICAS DE UPLOAD POR EL MOMENTO, SOLO DE DOWNLOAD. No se puede saber lo que has subido a un proxy, solo lo que te has bajado de un proxy.
Descargas>Sesion>Datos Descargados>Clientes>Webcaché : para ver lo que hemos descargado vía webcaché en esta sesión de Emule.
Descargas>Acumulado>Datos Descargados>Clientes>Webcaché : para ver lo que se ha descargado vía webcaché en total.
Descargas>Sesion>Sesiones de Descarga>Successful WC-DL/WC-Requests : esto indica el % de trocitos del caché de los que hemos tenido noticia y hemos bajado correctamente con respecto al total de trocitos de los que hemos tenido noticia. Evidentemente las tasas de éxito deberían estar cercanas al 100% para un funcionamiento óptimo.
Además, desde la versión 1.2f se puede ver cuántos bloques de has bajado via proxy de cada archivo y de cada usuario, mirando la información de las propiedades de cada uno. Hay una línea que pone "WC-Downloads" en la info de cada archivo que NO FUNCIONA AUN, porque no la han implementado, no porque funcione mal el webcache.
EL FICHERO DE TEST PARA DESCARGAR: tiene este elink: ed2k://|file|Webcache Emule Test.file|1078989657|E9057ADC38054AFA24816E86BB08D270|/ Solo sirve para eso, para testear que se puede usar el webcaché y que funciona, porque todo el que se está bajando este fichero tiene (o debería tener) activado el webcaché. No tiene ninguna otra función, pero conviene que lo dejéis bajando al menos un día para comprobar que funciona con las opciones de configuración seleccionadas y cuánto supone con respecto al total de lo que tienes descargando (a no ser que tengas muchas cosas y vayan rápido, en cuyo caso apenas notarás el webcaché porque tendrás toda tu línea copada por el resto de descargas).
MODs QUE LO SOPORTAN: hacer una lista de esto es una tarea bastante ardua y tediosa, pero ahí van 2 ó 3:
eMule Webcache
eMule Pawcio (discontinuada)
eMule MorphXT v7.1 (la 7.2 actualmente da problemas)
eMule Phoenix (discontinuada)
Para estar al día, nada mejor que pasarse por el Site de Soporte de Spanishare: Soporte Spanishare (necesitas estar logueado para descargar Binarios).
Importante: los MODs que incorporan la versión de webcaché 1.2c y anteriores no funcionan bien, y por lo tanto no notaréis apenas que descargáis algo. Utilizad los MODs que incorporan la versión 1.2d del webcaché y posteriores.
¿DEBEMOS PONERNOS TODOS EL MISMO PROXY?: la respuesta más adecuada es que NO. Debes ponerte el que te corresponda según tu ISP. Si no te pones el que te corresponde, y te dedicas a usar el mismo que el resto de la gente, lo que vas a conseguir es que haya tanta gente metida en los proxys abiertos que al final los cierren y dejen tirados a los usuarios que por no disponer de proxy propio en su ISP no pueden utilizar otro, mientras que tú si puedes usar el de tu ISP. Como eso nos perjudica a todos (pensad a largo plazo, por favor), hay que intentar meterse todos en proxys propios para "desmasificar" los proxys abiertos y que aguanten el máximo de tiempo posible online.
Al final terminarán chapando los proxys abiertos y los que no puedan usar uno propio de su ISP se tendrán que buscar la vida, así que pensad un poco en la comunidad y usad el que os corresponde.
LAS OPCIONES AVANZADAS DEL WEBCACHE: yo no soy experto en estos temas, pero voy a intentar explicar lo que hace cada una:
- Number of Blocks to download before reconnecting to the proxy: esta opción ayuda en algúnos proxys que pueden dejar de responder antes de tiempo, por lo que se puede obligar a Emule a reconectar con ellos tras bajar 1, 2, 3... o los que sea, bloques de 180 KB. No parece que haga falta en los proxys que se están manejando aquí en España, y en cualquier caso la autoconfiguración ya pone la opción adecuada (siempre que la autoconfiguración esté correcta, claro - léase el caso ONO). El valor 0 es como decirle que lo deje en "automático", que es lo más aconsejable.
- Extra long Timeout for webcaché connections: algo parecido a lo anterior, permite tiempos de espera más largos a la hora de establecer conexiones con el proxy. No parece que haga falta en los proxys que se manejan en España.
- This webcaché does NOT cache traffic within the same ISP: sería el caso por ejemplo de que en el proxy de Telefónica no se cacheara el tráfico que viene de dentro de Telefónica, o sea, su tráfico interno. Ahora mismo esto no es así, es decir, el proxy de Telefónica lo cachea todo, tanto lo que se pide de fuera como lo que se pide de otros usuarios o páginas web de dentro de la red de Telefónica. Así que no hace falta marcarla. Existen proxys que no cachean el tráfico interno, y por eso existe la opción. Según parece, el proxy abierto cache4 también permite cachear el tráfico interno, así que tampoco hay que marcarla actualmente.
- Persistent connections for proxy downloads: esta opción se impuso porque algúnos servers extranjeros permiten mantener la conexión para seguir descargando el siguiente trozo de 180 KBs sin necesidad de cortarla como hace el proxy de Telefónica. Pero si usas un server que hace una petición cada vez que baja un trozo (como el de Telefónica), lo que se consigue al activar esta opción es que se pierdan bloques de la cola de descarga desde el proxy, así que es MUY PERJUDICIAL para la continuidad y la estabilidad en la descarga por webcaché el activar esta opción si el proxy no la soporta. Repito: el proxy nuria de Telefónica no soporta la opción, por lo que activarla es perjudicial.
---------------------------------------------------------------------------------------------------
ZONA DE CONOCIMIENTOS AVANZADOS
Para el usuario normal esto ya no tiene ninguna importancia, así que si no os interesa, podéis pasar del tema.
ACTIVAR EL LOG DEL FUNCIONAMIENTO INTERNO DEL WEBCACHE: nos vamos a Preferencias>Opciones Adicionales>Información Extra y activamos tanto la casilla de activación como la de "Log Webcache Events". Además, desactivamos el resto de casillas si es que hay algúna más marcada, porque si no el log será un lío impresionante.
Con eso obtenemos una nueva pestaña en el botón de Servidores, al lado del Registro de Emule llamada "Verbose", que nos irá mostrando todo lo que hace el Webcaché.
ALGUNOS COMANDOS NORMALES DEL LOG:
Proxy-Connections for this file: 0 Allowed: 5 -> Indica cuántas conexiones tiene abiertas para un determinado archivo. Normalmente no subirá de 1 ó 2. No se puede saber a qué archivo corresponde directamente. Mostrará 2 conexiones si estamos bajando por webcaché un archivo que estemos subiendo por webcaché a alguien al mismo tiempo.
Received WCBlock - UDP: alguien te ha informado de que se acaba de descargar un bloque de 180 KB vía proxy-caché y puedes descargártelo tú también si te interesa (esto lo decide el Emule, claro).
CWebCachedBlock: proxy-ip=AAA, host-ip=BBB, host-port=CCC, filehash=DDD, start=EEE, end=FFF, key=GGG
"Mensaje de bloque". Informa del bloque que ha encontrado en el proxy. Significa:
- AAA = la IP de tu proxy.
- BBB = la IP del usuario que pasa el trozo de 180 KB originalmente (el uploader)
- CCC = el puerto del que pasa el trozo originalmente
- DDD = el hash de ese fichero (permite reconocer a qué archivo corresponde de nuestra lista mirándolo)
- EEE = dirección de inicio del trozo en bytes dentro del archivo
- FFF = dirección final del trozo. Tiene que ser 184320 bytes (180 KBs) mayor que la anterior, claro.
- GGG = clave de desencriptación del HTTP.
CWebCachedBlock::~CWebCachedBlock(): blocks on queue: X -> Esto es un mensaje recordatorio que aparece de cuando en cuando para ver cuántos bloques llevamos en la cola interna del webcaché. También aparece justo después del "mensaje de bloque" encontrado si dicho bloque no nos vale para nuestros archivos porque ya lo tengamos descargado por otras vías.
CWebCachedBlock:: DownloadIfPossible(): blocks on queue: 0 -> Nos sale después de un "mensaje de bloque" si el bloque nos vale para nuestras descargas porque no lo tenemos aún. Comienza a descargar en la pestaña de Tráfico del Emule.
CWebCachedBlock:: DownloadIfPossible(): blocks on queue: X -> igual que el anterior, pero ya tenemos algo en la cola, y por lo tanto no entra a descargar directamente.
CWebCachedBlockList::AddTail called, queue length: X -> Sale después de un "mensaje de bloque" si el bloque nos vale para nuestras descargas pero ya estamos descargando otro bloque, luego pone el bloque nuevo a la cola interna ("tail") en el puesto X. En cuanto terminemos el bloque que estemos descargando, el número 1 de la cola interna pasará a entrar en descarga. Si esta cola es suficientemente larga, la descarga es muy continua y apenas se notan las pausas entre bloques. Si no es muy larga, se acaba rápido y si no hay cola, no hay descarga -> aparecen pausas entre bloques.
WebCachedBlock added to queue: confirma el mensaje anterior.
WCBlock sent to client - UDP: envía información a otros usuarios conectados a nosotros de que acabamos de recibir vía-proxy un trozo de 180 KBs que ellos pueden necesitar, y que lo tienen disponible en el proxy.
new CWebCacheDownSocket: ProxyConnectionCount=X: cada vez que tiene una conexión ocupada porque estemos bajando algo con ella, porque estemos subiendo algo con ella, o porque estemos a la escucha de los bloques que nos informen otros usuarios, abre una nueva para estar alerta, haciendo la número X del total.
deleted CWebCacheDownSocket: ProxyConnectionCount=X: es el mensaje que cierra la anterior si no se necesita más.
Cached block downloaded from proxy!!!: acaba de descargar un bloque de 180 KBs completo.
WebCache: Socket closed unexpedtedly, trying to reestablish connection -> Mensaje de error que sale en las versiones actuales del webcaché por un bug y que se espera puedan solucionar los programadores en el futuro. No obstante, en algúnos usuarios podría ser síntoma de que algo va mal con su proxy, porque es un mensaje genérico de que no ha podido establecer conexión con el proxy adecuadamente.
RECONNECTING ProxyClient!!: En ciertos proxys como el de Telefónica, cada vez que termina de descargar un bloque y tiene algún otro en cola, dice esto. La razón es que el proxy de Telefónica no permite descargar más de un bloque por conexión, y hay que cerrarla y abrirla cada vez que pone un nuevo bloque a descargar. No tiene más importancia, salvo que puede suponer un poco de tiempo perdido entre bloque y bloque.
Received cached block info from unknown client (UDP) -> Según me han dicho los desarrolladores, esto sale cuando se ha cerrado y abierto el Emule recientemente, o cuando se ha pausado o detenido un archivo que tenía muchas peticiones vía-proxy, pues nos siguen mandando información de esos trozos que no podemos aprovechar por estar pausados los archivos, y nos los mandan gente a la que ya no tenemos de fuente (y por eso son "unknown" = desconocidos) por haber detenido el archivo.
BUGS CONOCIDOS: el bug más gordo actualmente aparece cuando tenemos 2 ó más trozos disponibles en la cola y terminamos de descargar el bloque que estuviéramos descargando en ese momento. Entonces pone a descarga el bloque #1 de la cola, pero inexplicablemente tira el bloque #2 y aparece el mensaje de error comentado antes. Esto provoca que la tasa de éxitos sea cercana al 50%, algo por encima ya que el bug no aparece si no hay nada en cola o solo hay 1 trozo disponible, por lo que en estos casos sí que se descargan los bloques sin problemas según llegan. Se espera que lo resuelvan los programadores en la próxima versión, pues ahora mismo lo tienen todas (incluida la 1.2e).
Otro bug algo menos molesto es el siguiente. Os pego lo que nos dice Dragonfire_2000:
PEQUEÑA DISCUSION SOBRE EL EFECTO DE ESTE "INVENTO" SOBRE LOS PROXYS: en mi opinión ocurre lo siguiente. Supongamos para simplificar 3 proveedores: Telefónica, PSI (la del cache4 abierto) y ONO. Los 2 primeros tienen proxy, el de PSI abierto, y ONO no tiene proxy propio.
Un ISP paga por tráfico recibido y cobra por tráfico enviado. Eso quiere decir que los sentidos de tráfico Telefónica->PSI y Telefónica->ONO hacen ganar dinero a Telefónica, mientras que los sentidos PSI->Telefónica y ONO->Telefónica le hacen perder dinero a Telefónica. Cada uno de esos tráficos en ausencia de proxys se realiza UNA VEZ por cada usuario que quiere pedir algúna página o trozo de 180 KBs que pertenece a la red de la competencia. Si hay 100 usuarios que piden ese trozo de 180 KBs (bloque) de un usuario de PSO o de ONO se hacen 100 peticiones a PSI o a ONO desde Telefónica, y Telefónica tiene que pagar 100 veces el coste de esa transferencia. Si se hacen en sentido contrario sucede al revés, y es Telefónica la que cobra de esos proveedores. En teoría estos cruces están más o menos desequilibrados en beneficio de los mayores proveedores, pues son los que más líneas manejan y los que más páginas y bloques pueden servir al resto, por tanto.
Si ahora Telefónica pone proxy propio, los sentidos PSI->Telefónica y ONO->Telefónica solo se producen 1 UNICA VEZ, la inicial, cuando el primer usuario de Telefónica pide al usuario externo el bloque que necesita. Los 99 usuarios restantes ya no se lo piden al usuario externo, se lo bajan del proxy; y por lo tanto, Telefónica se ahorra 99 veces el coste de la transferencia.
Pero resulta que en los sentidos contrarios, si no hay proxy, ONO y PSI tienen que seguir pagando 100 veces el coste de la transferencia Telefónica->PSI o Telefónica->ONO. Por lo cual, Telefónica sale ganando claramente, ya que ella solo va a pagar 1 transferencia gracias a su proxy, y a cambio va a cobrar 100 transferencias, por aquellos ISPs que no tengan proxy. Este es el caso de ONO, y en general cualquier otro ISP que no tenga proxy propio. O lo ponen o van a perder dinero, porque las transferencias hacia Telefónica se van a reducir drásticamente por los proxys, mientras que en sentido contrario, las que le hacen perder dinero a ONO se mantienen (al no haber proxy). El balance deja de estar "equilibrado" como antes y claramente favorece a aquel proveedor que tiene proxy. Es la razón principal de que Telefónica pusiera su proxy transparente.
Telefónica tiene un tráfico interno que le cuesta muy poco y se supone además que ya está sufragado por las cuotas de sus abonados, igual que las de cualquier otro ISP.
Ahora metamos el proxy abierto de PSI (cache4) en la ecuación. Este proxy está en el Reino Unido (UK), pero es abierto, lo que significa que lo pueden utilizar más usuarios aparte de sus propios clientes. Los usuarios de ONO lo están usando ahora mismo porque no tienen proxy propio. Pues vamos a ver. Si un usuario de ONO pide que uno de Telefónica o de ONO le suba un bloque al proxy y otros 99 se lo van a descargar ocurre lo siguiente:
- Si el bloque es de un usuario de ONO, el bloque hace el trayecto ONO->PSI una sola vez, pero luego hace el trayecto PSI->ONO 100 veces, con lo que el balance le sale a ONO que tiene que pagar 98 transferencias netas. ¿Y a PSI? Bueno, habría que echar números, porque con dejar que el resto de ISPs usen su proxy está ganando dinero (como acabamos de ver), pero al mismo tiempo está sobrecargando su máquina, que le costará dinero. Es un balance del que habría que echar números, pero no sería de extrañar que le saliera positivo al proxy abierto y por eso dejen usar el proxy desde fuera.
- Si el bloque es de un usuario de Telefónica, el bloque hace el trayecto Telefónica->PSI una sola vez y luego el trayecto PSI->ONO 100 veces. Curioso este caso, porque PSI ahora tiene que pagar 1 transferencia a Telefónica, y ONO tiene un balance negativo de 100 transferencias. Con este tipo de transferencias ONO pierde incluso más que antes.
Con lo que usar el proxy abierto en principio el efecto que tiene es que sobre los proveedores que lo utilicen se generará un recargo gigantesco de transferencias que se podían haber ahorrado si tuvieran proxy propio. Y sobre el mismo proxy, pues no se puede saber a priori: puede que le convenga si le sale más rentable cobrar por transferencias que dejar sobrecargar la máquina; o puede que no le convenga. Lo que está claro es que a ONO y al resto que no tienen proxy propio les convendría poner uno o van a perder mucha pasta...
________________________________________________________________________________________
Eso es todo lo que hay por ahora. Saludos.
(post por Ryderark, de Spanishare.com - Última edición: 10/11/2004 )