Introducción
Willow Games está listo para una nueva manga. La mesa de resultados necesita interacciones ágiles; la mesa multimedia necesita recibir el audio completo del ensayo. Ambos enlaces funcionan, pero la ruta inicial envía ambos trabajos por uno solo.
Repetirás mediciones breves en un entorno nuevo preparado, elegirás rutas separadas por destino y enviarás el nuevo resultado y el audio completo. Completa primero Mide las necesidades de red de cada tarea del evento o aporta habilidades equivalentes de ping, iperf3 y rutas IPv4 de alcance limitado. No se requiere programación ni codificación multimedia.
Usa Event Client para los comandos y Event Receipts para ver y reproducir el contenido realmente recibido. Solo puedes editar las dos rutas de destino indicadas y tus nuevos envíos. Los 45 minutos son una estimación del autor; los nodos aislados comparten un núcleo y representan rutas virtuales cableadas, no mediciones de proveedores públicos.
Elige según la carga de trabajo indicada
En este paso medirás los enlaces preparados y elegirás uno para cada trabajo. Empieza en Event Client, ya situado en /home/labex/project/event-links. Este laboratorio tiene su propia red y archivos nuevos. Presupone las herramientas de retardo y rendimiento de Mide las necesidades de red de cada tarea del evento, además de lectura básica de rutas por destino; no se conserva ningún archivo ni proceso en ejecución.
Primero observa la función normal que debes conservar. La mesa de resultados ya tiene un registro de calentamiento. curl --noproxy '*' evita los proxies, -fsS falla ante errores HTTP mostrando sus mensajes y --max-time 35 limita la transferencia:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Espera el resultado warmup conservado de 1–1. Cambia a Event Receipts. Las dos tarjetas principales esperan heat-7 y opening-sound.wav; la página no cuenta el calentamiento como un trabajo nuevo completado. Vuelve a Event Client.
La mesa de resultados necesita interacciones breves: elige el enlace con RTT bajo de forma consistente, con una media de muestra claramente inferior al presupuesto de planificación de 80 ms. El equipo multimedia necesita capacidad de subida masiva: elige la ruta cuyo rendimiento del receptor supere holgadamente los 10 Mbps en este escenario preparado. Estos presupuestos amplios orientan tu decisión; no garantizan un servicio de Internet. No ajustes los enlaces para alcanzarlos.
Lee las identidades de enlace proporcionadas y el nuevo resultado. cat muestra cada archivo:
cat links.tsv
cat source/score.json
Los dos destinos de negocio son 10.205.10.10 para resultados y 10.205.10.20 para multimedia, ambos en el puerto HTTP 8080. Al principio ambas rutas /32 usan lane1. Mide el mismo destino multimedia desde este mismo cliente por cada enlace, de una prueba en una. ip route replace cambia solo ese destino; via identifica el siguiente salto y dev la interfaz. ip route get confirma lo que el núcleo selecciona antes de enviar tráfico.
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n usa direcciones numéricas, -c 4 se detiene tras cuatro peticiones y -W 2 limita cada espera a dos segundos. Lee la media y la dispersión del RTT en milisegundos:
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c se conecta al puerto 5201 del receptor preparado; -t 5 ejecuta una prueba TCP de datos de cinco segundos. La dirección predeterminada sube datos del cliente al receptor, igual que el trabajo multimedia. Lee la tasa final de receiver. Mbps significa millones de bits por segundo; divide entre ocho para aproximar los MB/s antes de la sobrecarga.
iperf3 -c 10.205.10.20 -t 5
Espera a que termine. Ahora cambia solo la ruta multimedia y repite:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Restaura la ruta multimedia inicial después del experimento:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Deberías ver un contraste grande: lane1 ronda 11 ms de RTT y 1,9 Mbps; lane2, 180 ms y decenas de Mbps. El descubrimiento inicial de vecinos y la planificación pueden afectar a una muestra. Si un resultado es cercano o la prueba dice que el servidor está ocupado, deja terminar la prueba finita, confirma la ruta y repite la misma muestra de forma secuencial. No superpongas pruebas ni cambies la regulación del tráfico. Un informe impreso no sustituye el tráfico real, y los bytes de iperf no entregan ninguna de las nuevas tareas de negocio.
Cambia solo las rutas de destino
En este paso convertirás la decisión basada en las mediciones y la carga de trabajo en dos rutas concretas. Empieza en Event Client. Lane1 ofrece el RTT bajo que necesita la pequeña interacción del marcador. Lane2 ofrece la capacidad de subida que necesita el archivo grande de prueba de sonido. Ambos enlaces deben seguir utilizables.
Lee la tabla completa antes de editar:
ip route show
Conserva la ruta predeterminada del curso y el destino de referencia 10.205.10.30. Solo puedes reemplazar las rutas 10.205.10.10/32 y 10.205.10.20/32. /32 significa exactamente una dirección IPv4; una ruta de red más amplia afectaría a otros destinos. La red de la plataforma queda fuera de esta tarea.
Establece explícitamente la ruta del marcador usando la forma ya aprendida con replace, via y dev:
ip route replace 10.205.10.10/32 via 10.205.1.1 dev lane1
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
Comprueba cada selección real del núcleo:
ip route get 10.205.10.10
ip route get 10.205.10.20
Espera tráfico del marcador por 10.205.1.1 dev lane1 src 10.205.1.2 y multimedia por 10.205.2.1 dev lane2 src 10.205.2.2. Si una selección es incorrecta, repite solo su comando replace completo con el siguiente salto e interfaz correctos. No vacíes la tabla ni cambies la ruta predeterminada.
Conserva la ruta de referencia independiente mediante una petición real:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Espera la respuesta original warmup, 1–1, preserved. Este ejercicio separa el tráfico por dos direcciones de destino distintas. No distingue aplicaciones que comparten una dirección de destino, no configura enrutamiento por políticas, no combina enlaces ni selecciona un ISP público.
Entrega nuevos resultados y archivos multimedia
En este paso entregarás el nuevo trabajo por las rutas elegidas y compararás el audio completo recibido. Empieza en Event Client. El nuevo resultado es el partido heat-7, local 3, visitante 1. La nueva tarea multimedia es opening-sound.wav, un tono sintético original de 48 segundos para probar el sonido del ensayo. Sus bytes PCM WAV mono válidos ya están preparados; no los codifiques ni edites.
Lee el resultado proporcionado antes de enviarlo:
cat source/score.json
Los nombres y valores de cadena JSON usan comillas dobles; los resultados son números. -H proporciona el tipo de contenido JSON y --data-binary @source/score.json lee el archivo exacto y realiza POST. La cadena -w añade los segundos transcurridos después del recibo: \n crea un salto de línea y %{time_total} es el tiempo total de curl. Incluye el establecimiento de la conexión, no solo el RTT.
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/score.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Espera el partido y los resultados correctos, local_ip de 10.205.10.10 y peer_ip de 10.205.1.2. El peer es el origen que observó realmente el receptor. El recibo demuestra esta entrega; no es una predicción de la ruta actual.
-T sube el archivo indicado mediante PUT al servicio multimedia. Puede tardar varios segundos; espera el resultado:
curl --noproxy '*' -fsS --max-time 35 -T source/opening-sound.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/opening-sound.wav
Espera el nuevo nombre, el número de bytes, el resumen de contenido, local_ip de 10.205.10.20 y peer_ip de 10.205.2.2. Una respuesta correcta para el archivo de demostración no completaría esta tarea.
Un POST con el mismo ID de partido reemplaza ese partido; un PUT con el mismo nombre multimedia reemplaza esa tarea. Si entregaste por la ruta equivocada, corrígela y vuelve a enviar la misma tarea. Cambiar la ruta tras una entrega no cambia su antiguo recibo. Nunca edites el almacén de recibos ni los archivos originales para simular un resultado.
Lee los receptores de forma independiente mediante GET:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/receipts
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.20:8080/receipts
Descarga el audio recibido en lugar de copiar el origen local. -o guarda la respuesta, cmp compara cada byte y sha256sum muestra un resumen de cada archivo indicado:
curl --noproxy '*' -fsS --max-time 35 -o received/opening-sound.wav http://10.205.10.20:8080/media/opening-sound.wav
cmp source/opening-sound.wav received/opening-sound.wav
sha256sum source/opening-sound.wav received/opening-sound.wav
Espera que cmp no muestre nada y que ambas cadenas de resumen coincidan. Un archivo vacío o con contenido diferente no coincidirá con el audio preparado. Cambiar el nombre de un archivo no modifica sus bytes ni su hash. Si la comparación falla, lee el recibo multimedia, repite el PUT del origen intacto al destino correcto, descarga de nuevo y compara.
Cambia a Event Receipts, selecciona Refresh receipts y busca heat-7 con 3 : 1, el nuevo nombre de audio y los orígenes de conexión diferentes. Reproduce el control Received event audio y usa Download received audio para obtener los bytes del receptor. El navegador puede estar silenciado o no tener dispositivo de sonido; la duración del control y el avance de la reproducción confirman igualmente que decodifica el WAV recibido. Inicia la reproducción de forma explícita; la página no la inicia automáticamente.
En la vista final siguiente, compara los dos valores Connection from junto al nuevo resultado y el audio recibido. El control de audio muestra la duración realmente decodificada y permite elegir una posición de reproducción.
Si curl no puede conectarse (código 7) o agota el plazo (código 28), vuelve a Event Client y comprueba de nuevo el resultado de ip route get correspondiente y la URL exacta. Un rechazo HTTP (código 22) es distinto: compara la ruta exacta del endpoint y el archivo JSON o cuerpo proporcionado. La opción -f omite el cuerpo de respuesta de error HTTP; no ajustes la red para corregir un error de formato del negocio. La actualización de la página solo lee receptores y no completa trabajo ausente.
Vuelve a Event Client y confirma otra vez la referencia conservada:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Has entregado dos cargas distintas por rutas adecuadas conservando ambos enlaces, los bytes originales, la regulación preparada, los datos de referencia y las rutas ajenas. La evaluación lee los registros de negocio y los hechos nativos de red existentes antes de sus sondeos GET limitados; nunca publica resultados, sube archivos ni repara una ruta.
Resumen
Elegiste rutas según la carga de trabajo, cambiaste solo dos rutas de destino y entregaste un nuevo resultado y audio completo reproducible. Los orígenes de conexión del receptor prueban por dónde llegaron esas entregas; cambiar una ruta después no puede reescribirlos. También conservaste la referencia existente y ambos enlaces preparados.
