¿Alguien sabe cómo funciona el capado de ONO?

Pues mira, es una mezcla entre priorización y capado, es verdad que según la hora del dia descargaras como maximo a 30kb/s o a w00kb/s, o sea que priorizan según la hora del dia pero también establecen un maximo de caudal por usuario, esto esplica qeu sea una mezcla entre piorización y capado.

En segundo lugar ONO hace esto porqeu le da la gana ya que su red no tiene la suficiente capacidad como para ofrecer la velocidad prometida a todos los clientes y tiene n que recurreir a priorizar (capar) el P2P.

 ¿Alguien sabe cómo funciona el capado de ONO? 

Bien, funciona bien, de hecho, creo que es lo único en ONO que funciona bien.

Ojala pusieran el mismo empeño en hacer funcionar el SAT o la velocidad contratada de la gente :-)

¿Nadie?
Pretendía que alguien con conocimientos dejara claro el aspecto técnico del capado en un lenguaje comprensible para los profanos, bueno sin pasarse tampoco.
Venga que alguien tiene que saber algo.

Es que no tiene ningún misterio, guarda los paquetes antes de enviarlos lo suficiente como para que no pueda dar una velocidad superior a la limitada y listo.

La información por internet viaja en bloques de N bytes que se llaman 'paquetes' (no es un flujo continuo). ONO transporta esos paquetes por su red hasta que salen a internet y viceversa.
Capar conexiones, en el sentido de Bajar velocidad es simplemente eliminar paquetes, esto es, por ejemplo de cada 1000 paquetes elimino 900 y así reduzco una velocidad de conexión de 200kb a 20kb. Así se "pierde" la información en la red de ONO y los ordenadores la tienen que volverla a enviar..si lo hacen muy rápido ONO vuelve a eliminar paquetes..Al final llega a un punto en el que los dos ordenadores en una conexión envían información a 20kbs y ONO ya no necesita eliminarlos.
¿queda claro? es como si en una autopista que tiene un atasco las autoridades deciden destruir coches hasta que el tráfico sea fluido.

Eso es una manera,
Otra, mucha veces explicada en este foro, es el reset del cable modem que simplemente obliga a los programas P2P a volver a establecer las conexiones y eso lleva tiempo y mientras tanto no transmiten tráfico pesado.

Priorizar
Simplemente si un equipo especializado en filtrar tráfico de la red de ONO detecta que hay tráfico P2P, lo elimina.. si es tráfico Web lo deja pasar, así de simple.

¿Por qué ono capa conexiones?
Pues simplemente para que su red de transpornte no se sature.
porque si esto ocurriese, los usuarios no podría navegar ni consutar su email... y claro es más barato comprar un aparatito que elimine tráfico P2P que ampliar su red con nuevos routers, mayor velocidad de conexión a internet, más fibras...etc.

Ahora te cuento mi teoría:
Antes ONO capaba el todo el P2P, ahora solo lo hace cuando
lo necesita o cuando hay mucha demanda de tráfico web..
Por ejemplo yo uso uTorrent como programa P2P y es imposible bajar nada entre las 20h y las 00h, la conexión es lenta y cada 30 min aprox me resetean el cable-modem..
Si embargo a partir de las 00h va de fábula.. llego a descargar a 200-300KBytes/s...

habria que mirar el fuente del emule, y no hay ganas, pero supongo que lo que hacen los routers de ono es filtrar paquetes emule torrent etc...,

Lo que no sé es si esto pasa en cada router o solo en los que conectan otras ciertos mas cercanos a la troncal. Por que si no fuera en todos, y me bajo algo de mi vecino, al ser conexion p2p no se supone que solo enrutaria por el primer router y me tendria k ir al máximo (su upload)? si alguien sabe esto último....

supongo que kry lo que hizo es modificar los paquetes del emule, de manera que los routers no sepan lo que envian, hasta que descubren que envian y se acabó el truco.

Allá por marzo - abril fue cuando kry consiguió burlar las defensas de Ono en sus nodos pero este problema venía de antes. Como ya te han dicho, los datos por Internet se envían en paquetes, conjuntos de bytes que llevan una cabecera donde dice de quien es, para quien, puertos, etc...

Primero "ellos" pusieron nodos intermedios que priorizaban (daban mayor prioridad) a los paquetes que no fueran a los puertos 4662 (TCP) y 4762 (UDP, creo que son estos) por lo que hacían que se perdieran los que sí que fueran en una gran medida. Con esto eliminaban saturación y dejaban que la navegación web funcionara sin problemas. Se supone que cuando estás delante del ordenador te gustaría que la navegación fuera fluida y lo de la mula que se baje cuando quiera.

Entonces llegó lo de poner puertos "mágicos" donde los nodos pasaban de eliminar los paquetes, que era algo tan sencillo como cambiar los puertos a otros que no fueran los estándar. De hecho ahora, cuando pones un emule nuevo, los puertos son aleatorios. Esos puertos son los que hay que abrir en el router (quien lo tenga).

Dentro de los datos de estos paquetes va la información que transmiten. Es posible mirar lo que va y decidir si esto es una página web, una imagen, un vídeo, etc... y parece ser (no soy ningún experto) que el emule metía información de control que los nodos podían ver. Entonces metieron esta información en el "capado" y volvieron a ponerse por delante, podían descartar paquetes de la mula que no iban a puertos estándar.

Y fue cuando apareció la "ofuscación de protocolo", que parece ser que consistía en "ocultar" los datos del paquete para que los nodos no pudieran decidir en tiempo real si eran de un P2P o no. Volvía a funcionar la máquina.

Pero se dieron cuenta que los paquetes del emule ocupaban lo mismo casi siempre, por lo que empezaron a filtrar paquetes que ocuparan X bytes. Nuevamente pánico en la comunidad.

Fue en ese momento cuando en el foro oficial de emule-project uno de sus programadores (y principal valedor de la versión de Linux Amule, que a ver cuando sacan una versión estable y así me quito el de windows con wine) kry propuso una modificación que estaba pendiente de ser implementada en la versión oficial, que hacía que los paquetes ocuparan un tamaño variable.

A esta versión modificada se la llamó 0.47k en honor a kry, aunque él dejó claro que era algo pendiente en la siguiente versión oficial que solamente había añadido a la que estaba en funcionamiento. También quiso dejar claro que Ono NO había conseguido saltarse la ofuscación de protocolo porque sus nodos NO podían descifrar el contenido de los paquetes en tiempo real, sólo era cuestión de tamaño.

Bien, pues nos encontramos ahora con que no sé cómo pero han vuelto a meter un nuevo nivel de priorización mucho más agresivo que parece que les funciona pero que toma como P2P cosas que no son, como FTP cifrado (cuando la entidad emisora del certificado es el propio servidor), por lo que supongo que esta vez no les está yendo tan bien como en anteriores oasiones.

Ya se ha puesto en funcionamiento la resistencia rebelde y parece ser que lo siguiente es ofuscar las comunicaciones UDP, aunque no creo que solucione la nueva versión del capado (que podríamos llamar ¿3.0?) pero así es como están las cosas... de momento.

Espero no haberme metido en temas muy técnicos porque tampoco soy ningún especialista y no me he visto el código fuente.

Ale