eMule y Webcache

Lectura recomendada del día para todos aquellos que utilicen eMule como programa P2P. Se trata de un hilo del foro de Spanishare explicando qué es y como se utiliza el webcaché, una nueva característica en algunos mods de eMule, que permiten mejorar la velocidad de descarga hasta el punto de llegar a picos con la máxima velocidad de conexión (descargar a 100kbs del eMule es bastante impresionante xD) al utilizar un proxy para cachear las partes descargadas y desde el cual descargarán el archivo los demás clientes. Echadle un vistazo aunque tardeis unos minutos en leerlo todo, porque merece la pena 🙂

Comentarios
  1. Yo uso caché y la verdad es que he notado mejoría, pero no demasiada. Quizás es que los contenidos que descargo sean un poco atípico (últimamente todos los videos habidos y por haber de los Planetas)

    Responder

  2. lo de los planetas y los blogs empieza a ser una conexión bastante normal… igual hasta tendré que volver a escucharlos… :huh:

    Responder

  3. […] acía tiempo que había leido acerca del webcache que se podía aprovechar para el emule. Hoy Zootropo me lo ha recordado y fruto del aburrimiento me he puesto a bajar un nuevo […]

    Responder

  4. bueno, es cuestion de que la gente lo use… entonces se notará mas 🙂 de ahi tb mi intento de hacerle mas publicidad ^^

    Responder

  5. Jeje, yo escribí sobre ello hace casi 1 mes y medio…
    http://guti.bitacoras.com/search.php?q=webcache.

    Responder

  6. lo lei en su momento 🙂

    Responder

  7. Lo voy a probar! Gracias por la info 🙂

    Responder

  8. No esperaba menos de ti, Zootropo.

    Responder

  9. Pues yo lo probé ayer y la verdad que está dando resultado, a ver si la gente se anima 🙂

    Responder

  10. Yo he estado revisando los foros de mldonkey a ver si aparecia algo y de momento no esta implementado. 😕

    Responder

  11. Che, yo soy de Argentina, pero aca Fibertel (mi servidor de cable), dicen que tiene un Proxy MUY groso… asique eso me vendria barbaro (yo no uso el Emule, porque tengo LowID, pero con eso, no me vendria mal utilizarlo un poco….)
    Actualmente utilizo bit torrent, que anda normalmente bien…. pero si va a pasar lo que me decis… repito, me gusta la idea 🙂

    Saludos

    Cristian.

    Responder

  12. Miquelet

    Hola a todos, yo lo estoy usando hace 2 dias y solo me ha bajado el 1,1 % de el total, supongo que debe ser debido a que la gente aun no esta animada o no tiene versiones de emule con el web cache.
    Desde aquí os quiero animar a todos a que lo useis.
    Os copio un manual sobre el tema que me he encontrado por la red.
    Saludos.
    Esto no es realmente un tema técnico, sino de concienciar al personal de la web de que ES NECESARIO utilizar esto a partir de ahora. En el foro de Emule, que es donde se trata la parte técnica, quedaría demasiado difuminado y lo que quiero es divulgarlo para que lo use cuanta más gente mejor, porque así es como mejor funcionará y así ganamos todos, y ya veréis por qué.

    LEE TODO EL POST CON DETENIMIENTO AUNQUE SEA LARGO, POR FAVOR. SERÁN SOLO UNOS MINUTOS, Y LA MAYORIA DE DUDAS DE LA GENTE YA ESTAN RESUELTAS. CON SOLO DEDICAR UNOS MINUTOS A COMPRENDER QUE SUPONE ESTO LUEGO PODRAS DISFRUTARLO MUCHO TIEMPO. Quien ya sepa de qué va esto, que no siga leyendo, pues ya lo estará usando; pero los que no, atentos: ¿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 E2dk 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. 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, algunas 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 algunos 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 algunos 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 alguno 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, pero ya hay un botón para descargarse un archivo que automatiza las preferencias de esa pestaña. Bajaos esto: Webcaché proxys y metedlo en la carpeta Config del Emule. Al pulsar el botón de esa pestaña de Emule os dirá lo que tiene que poner y lo pondrá él solito. 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é.

    Funciona un poco a saltos, porque las versiones actuales son de prueba y 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”.

    El puerto en los proxys de telefónica es variable, se puede poner el que viene por defecto al configurarlo con el botón automático (3128) o bien el 8080.

    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:

    Cómo 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.

    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)). No hace magia ni escanea nada, solo va al fichero Webcaché proxys y compara el DNS (al fin y al cabo la IP) del primer nodo del usuario con las DNSs de la base de datos, a ver si alguna es compatible, y solo en ese caso la presenta al usuario como datos a meter en las casillas. Ahora, por proveedores de lo que sabemos hasta el momento:

    – Telefónica, Terra y Ya.com: debería funcionar el proxy transparente de Telefónica: nscbest1.rs1.nuria.telefonica-data.net con el puerto 3128. Si tienes alguna de estas compañías, al darle al botón de autoconfiguración debería detectarte este proxy, y automáticamente el resto de casillas se rellenan solas, NO HAY QUE TOCAR NINGUNA, porque el proxy ya está configurado óptimamente como debe estar. No hay que marcar ni desmarcar nada que no esté ya colocado.

    Al parecer hay usuarios de Telefónica madre (no revendida, sino de Telefónica-Telefónica) a los que no les funciona el proxy “nscbest1.rs1.nuria.telefonica-data.net”, que es el típico para la red GIGAADSL. En ese caso convendría que la gente probara otros proxys de dicha red, por ejemplo:

    – “proxy.mad.ttd.net” con el puerto 8080
    – “proxy.bcn.ttd.net” con el puerto 8080

    Para probarlos, no basta con meterlo y “a ver si descarga algo”. Para descargar algo y comprobar que funciona, necesitaréis alguna otra persona metida en el mismo proxy que os pase y reciba datos a través de ese proxy. Lo mejor sería que ambos cambiarais de sitio todas las descargas de la carpeta Temp y guardárais en otro sitio los archivos de Incoming; abriérais el Emule y ambos metidos en un mismo server, probar a descargar el archivo TEST. En esas condiciones debería subir y bajar vía webcaché a alguno de los 2, provenientes de otros usuarios. Esta prueba vale PARA CUALQUIER PROXY, y conviene que la gente se esfuerce por buscar alternativas. Yo lo digo y vosotros ya hacéis lo que queráis, pero al final terminarán cerrando el proxy público que usa todo el mundo y a ver lo que hacemos entonces…

    – Jazztel, Euskaltel, AUNA y otras compañías de CABLE o de ADSL fuera de la red de Telefónica: por no compartir la red de Telefónica, o por convenio con dicha compañía, las conexiones de estos ISPs no son cacheadas por los proxys transparentes, y además, siendo dichos proxys cerrados, no pueden usarse con estos ISPs. De forma que no utilicéis el proxy de Telefónica porque no va a funcionar como debe. Lo suyo sería enterarse de si estos ISPs utilizan algún proxy propio optativo no transparente (porque es evidente que proxys transparentes no utilizan) y comentarlo por aquí para que la peña lo use. A falta de tal proxy, lo que se debe hacer es usar un proxy “abierto”, es decir, que permite las conexiones desde el exterior al ISP y por lo tanto no tienes que pertenecer a ese ISP para poder usarlo. Ahora mismo la gente está usando el proxy “cache4.www.uk.psi.net” con el puerto 8080 y parece que funciona. Para configurar esto NO hay que darle al botón de autoconfiguración, se pone a mano.
    Importante: no debe usarse este proxy si puede usarse el de Telefónica, porque si todos empezamos a usar este, terminarán cerrándolo al recibir demasiado tráfico externo al Reino Unido, y al final todos seremos los perjudicados: los de cable no podrán usar proxy y tendrán que volver a tirar de los slots de subida, asfixiando de nuevo la red ed2k. Si puedes usar el de Telefónica, usa el de Telefónica, que es totalmente válido, y no lo van a quitar ya que el tráfico que soporta es solo el interno de Telefónica y para eso ha sido diseñado.

    – Wanadoo: hago copy-paste de lo que nos cuenta forenaitweel:
    quote:

    Aclaro lo de Wanadoo:

    Wanadoo compró en el 2003 a eresMas(que era una subempresa de Retevisión(ahora llamada Auna) que ofrecía ADSL de Auna). Al comprar eresMas tenia derecho de acceso a una parte de la red de Auna.

    Los que eran usuarios de eresMas pasaron a ser de Wanadoo(yo uno de ellos), y a partir de septiembre de 2003(más o menos) Wanadoo hizo todas sus altas a través de la red de Auna, así se ahorraba mucha pasta, pero las antiguas las dejó intactas.

    Auna antes tenia varios proxys, tenia un par en Menta, y uno en madritel, tambíen tenia uno suyo(netcache.red.retevision.es) que hasta el 2002 era transparente en sus adsl, pero los desactivaron todos.

    Por eso hay algunos usuarios de Wanadoo que van por Telefónica, y otros virtualmente van por Auna y no les sirve el proxy.

    Resumen: A los que tengais Wanadoo y os vaya el de telefónica, perfecto, a los que no…buscaros uno gratuito, porque ni Wanadoo ni Auna ni Uni2 tienen proxy(ni opcional ni nada).

    Y no sirve un proxy de Uni2 francia ni Wanadoo holanda, porque las ips son diferentes, y Wanadoo Holanda no saben que ips son las de Wanadoo España, ni quiere saberlas.(aparte, no hay ninguna ip de Wanadoo que sea tararítarari.wanadoo.es), todo esto a no ser que el proxy sea abierto, como el de PSI.

    En resumen nos dice que algunas líneas al ser más antiguas pasan por la red de Telefónica y les funciona el proxy de Telefónica, pero otras se hacen pasar directamente por la red de AUNA y no les funciona el proxy de Telefónica, luego tendrán que buscarse otro.

    – ONO: caso particular, porque es similar al resto de cableras PERO el archivo de configuración, a día 10 de Octubre de 2004 está mal y tiene datos erróneos. Para ONO, si usamos la autoconfiguración, hay 2 posibilidades: que nos encuentre un proxy con nombre http://www.proxy-ono.com o algo similar, o bien que nos diga que ha encontrado el proxy de telefónica (nscbest1.rs1.nuria.telefonica-data.net). AMBAS opciones son erróneas y si ponemos alguna de las 2, no nos va a funcionar. Para ONO, por tanto, aunque la autoconfiguración diga una cosa, por ahora hay que usar el mismo proxy abierto que para el resto de cableras.

    – R: la cablera gallega parece que tiene proxy propio y que funciona, así que ya sabéis los que tenéis R lo que hay que hacer: “proxy.mundo-r.com” con el puerto 8080. De todas formas el webcaché lo detecta automáticamente al darle al botón Autoconfigurar porque este proxy ya lo tiene metido en la base de datos. Ahora puede que vaya un poco mal, pero tened paciencia porque falta que se meta mucha gente en él y comenzará a ir perfectamente. Y sobre todo, que es vuestro proxy y no os lo van a quitar

    Por último, para poder usar la autoconfiguración, es necesario que hayamos entrado en algún servidor de edonkey, o bien que hayamos hecho algún contacto por Kademlia, para que la conexión a Internet digamos que está activada y el chequeo de la autoconfiguración pueda comparar la IP de nuestro nodo con la del archivo Excel. Si no estás conectado, dará un mensaje de error.

    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.

    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.2e) 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 (o sea, el cache4 anterior, los proxys que usan los alemanes,…), 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. Si tenéis el de Telefónica porque os lo ha dado la autoconfiguración (salvo con ONO), os puede funcionar o puede que no, pero independientemente de lo que diga el TEST.

    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: Webcaché proxys. Este es el archivo de autoconfiguración de los proxys, y se va actualizando periódicamente. Para poder usarlo, hay que bajarlo y meterlo en la carpeta Config del Emule. En esas condiciones, cuando pulsemos autoconfiguración el Emule encontrará la lista de proxys actual y podrá decidir si encuentra uno que se ajuste a nuestras características.

    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:

    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.

    EL FICHERO DE TEST PARA DESCARGAR: tiene este elink: Webcache Emule Test.file. 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 0.44b webcache 1.2e
    Emule 0.44b Pawcio 5.14
    Emule 0.44b Pawcio 5.14 LSD 18b
    Emule 0.44b Phoenix 1.10

    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, y si tu ISP no tiene ninguno, entonces sí que debes ponerte uno abierto que tenga mucha gente. 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 el proxy abierto 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 algunos 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 algunos 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 alguna 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 algunos 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:
    quote:

    Una pequeña explicacion de lo que ocurre cuando te mandan un bloque:
    (aclarando el tema de la linea -> WebCache: Socket closed unexpedtedly, trying to reestablish connection).

    Bien, voy a comentar lo q ocurre cuando te estan mandando un bloque y tanto tu como la persona q lo manda teneis el webcache activado (en este caso no importa el servidor del proxy ya q al mandartelo a ti, te lo suben a tu proxycache):

    1º Te pasan un bloque de ~180KB (encriptados) a traves de tu propio proxycache. Cuando completas el bloque, este a su vez ya ha sido cacheado por el proxy.
    2º Informas al resto de clientes con el webcache activado y tu mismo proxycache (WCBlock sent to client – UDP) de q ese bloque esta disponible en el proxycache por si quieren descargarlo.
    3º El emule intenta hacer una nueva peticion de bloque en la misma sesion q tiene abierta con el proxycache, como los nuestros (timofonica y demas) solo permiten una peticion por sesion (conexion), aparecera el mensaje: WebCache: Socket closed unexpedtedly, trying to reestablish connection, vamos q el proxy te desconecta (probablemente tambien lo haga aunque no realices la nueva peticion).
    4º Enseguida restablece la conexion con el proxycache y el cliente q te estaba mandando los bloques continua con el siguiente.

    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 alguna 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…

    Aquí va a pasar algo gordo dentro de poco

    Responder

  13. edusnognig

    mirar en esta pagina http://www.razorman.net creo que lo explica bastante bien

    Responder

  14. champy

    mejor no usemos los proxys, para que tengamos durante mas tiempo la mula, mejor no juguemos a la guerra.

    Responder

  15. :huh: eh? que tiene de malo los proxys? incluso a tu isp le interesa que los uses

    Responder

  16. Anónimo

    Esto del pastel y tal,yo que se,lo hace tandificil que no se…,Miren,si cuando se duplique la velocidad me toca a 110 kbs,dejemos todo como esta,si me tocan a 8 kbs,entonces hablamos.

    Responder

  17. Gabriel

    No se si sera bueno el webcache, pero creo que para el futuro puede ser una buena idea, todo tiene un comienzo y este es un paso….

    Responder

  18. kolepep

    Yo ya me lo acabo de poner. El de …nuria… no me funcionaba pero al hacer el test con el proxy.mad.ttd.net, puerto 8080, proxy de telefonica, parece que funciona. A esperar…

    Responder

  19. pues vamos a probarlo luego le cuento, pero igual habeces se tarda mucho el emule en bajar, considerando que los puertos que utiliza estan bloqueados por mis proveedores de internet!!! malditos yankis

    Responder

  20. El link no funciona. Hay una lista actualizada de los proxys en http://www.lphantes.com/foro/webcache-que-es-y-como-configurarlo-vt3.html

    Por otra parte, el webcache no solo se usa los mods de eMule; Lphant también lo utiliza.

    Saludos.

    Responder

Deja un comentario