UDP y TCP

UDP y TCP sin formato no tienen una pantalla propia. Son lo que usas para un dispositivo con su propio protocolo de texto o binario — un proyector, un servidor de medios, un sensor — y aparecen en varios sitios:

Para…	Usa
enviar un datagrama o un mensaje TCP como paso, y esperar la respuesta	los pasos de experimento
guardar un datagrama para enviarlo otra vez, o reproducir uno que capturaste	una señal UDP
enviar un datagrama desde un script	signallab send udp
enviar a muchos hosts a la vez, a una dirección de difusión o a un grupo de multidifusión	la pantalla Difusión
cargar un servidor o un enlace con tráfico	Tormenta
averiguar qué puertos TCP tiene abiertos un host	Escáner
hacer el papel del dispositivo	un emulador de dispositivo UDP o TCP
empeorar la red entre dos extremos	un relé de degradación

OSC es un formato transportado en datagramas UDP; tiene su propia página: OSC.

Cargas útiles

Allí donde escribas una carga útil sin formato, es de uno de dos tipos:

Tipo	Qué se envía	Ejemplo
Texto	Los caracteres como UTF-8, exactamente como se escriben: sin terminador, sin añadir fin de línea. Un protocolo de líneas necesita su fin de línea en el texto.	PING
Bytes en hex	Byte a byte, escritos como pares de dígitos hex. Se permiten espacios, :, - y , entre pares y un 0x delante de ellos.	de ad be ef, DEADBEEF, 0xde,0xad

Un datagrama lleva como máximo 65 507 bytes. Un número impar de dígitos hex, o ninguno, es un error antes de enviar nada.

INFO

UDP no tiene acuse de recibo. "Enviado" significa que el datagrama salió de este equipo, no que algo lo recibiera. Para saber que un dispositivo te oyó, espera su respuesta.

Adónde va

Un destino es una dirección IP y un puerto, o un nombre de host y un puerto: 192.0.2.20:9000, [2001:db8::20]:9000 (una dirección IPv6 va entre corchetes), projector.local:9000. Esto vale para el destino de un paso UDP, un destino OSC, una señal UDP, signallab send udp y signallab send osc, la lista de Difusión, el destino de Tormenta y el host del paso TCP.

Un nombre de host se resuelve cada vez que se usa. Cuando tiene una dirección IPv4, se usa esa — así localhost llega a un servicio que escucha en 127.0.0.1, donde la primera dirección que un sistema lista para él puede ser ::1 — y un nombre que solo tiene direcciones IPv6 se alcanza desde un socket IPv6. Un nombre que no resuelve falla con Cannot resolve …; un destino sin puerto, o que no tiene ninguna de las dos formas, con … is not a valid address. Las direcciones en las que un servicio escucha (las de un monitor, una espera, un emulador) son siempre IP:port.

En experimentos

Paso	Qué hace
Datagrama UDP	Envía su Carga útil como texto a Host:puerto de destino. El destino es IP:port o host:port (arriba), y varios destinos separados por comas reciben cada uno el datagrama. Con esperar una respuesta envía desde Respuesta en (IP:puerto) y espera ahí una respuesta en el mismo paso. Detalles
Esperar UDP	Escucha en Escuchar en (IP:puerto) (IP:port) y espera un datagrama cuya carga útil coincida. Detalles
Mensaje TCP	Se conecta a Host y Puerto, escribe su Carga útil como texto, escucha 250 ms por si hay respuesta y cierra. El paso dice cuántos bytes volvieron, no qué eran. Detalles

La carga útil y el destino de UDP, el host y la carga útil de TCP, y el patrón de una espera aceptan {{templates}}, así que un datagrama puede llevar el id de la ejecución o un valor que extrajo un paso anterior. Consulta Datos y plantillas.

Hacer coincidir un datagrama

Esperar UDP y la respuesta de Datagrama UDP eligen un datagrama por su carga útil:

Carga útil	Acepta un datagrama cuando
Cualquier datagrama	siempre: el primero que llegue
Contiene el texto	su carga útil, leída como texto, contiene el patrón
Coincide con la regex	su carga útil, leída como texto, coincide con la expresión regular
Contiene los bytes (hex)	sus bytes contienen los bytes del patrón, escritos en hex

Lo que coincidió se guarda en la variable del paso (Variable de respuesta, reply salvo que la renombres): text, hex (los primeros 1024 bytes), bytes (el tamaño), from (el IP:port del emisor), ms (cuánto tardó) y match (el texto o los bytes encontrados, o el primer grupo de una expresión regular).

Una espera empieza a escuchar cuando empieza la ejecución, no cuando se llega al paso, así que una respuesta que llega muy rápido no se pierde. Solo toma lo que llegó después del último envío en su camino.

Límites y valores predeterminados

Ajuste	Predeterminado	Rango
Paso TCP: Tiempo de espera (ms) (conectar, escribir y la respuesta juntos)	4000 ms	1–120 000 ms
Tiempo de espera, ms de una espera o una respuesta	2000 ms	1–120 000 ms
Carga útil UDP	—	como máximo 65 507 bytes
Dirección de escucha	—	IP:port con un puerto; el Respuesta en (IP:puerto) de una respuesta puede usar el puerto 0 (cualquier puerto libre)

En el Inspector, el datagrama de un paso UDP aparece con el origen broadcast (o experiment cuando el paso espera una respuesta), y cada datagrama que llega al puerto de una espera con el origen experiment-wait. Un paso TCP aparece como dos tramas tcp con el origen experiment: la carga útil que escribió y, cuando llegó una, la respuesta que leyó. Su entrada en la línea de tiempo dice qué envió y cuán grande fue la respuesta.

Señales

Una señal UDP (sin formato) de la biblioteca es un destino y una carga útil, como texto o bytes en hex. Envíala desde Señales, o con Ctrl+K desde cualquier pantalla. Su destino puede ser un nombre de host.

Cualquier datagrama que el Inspector conservara entero puede convertirse en una: Guardar como señal crea una señal UDP hex, en la carpeta Capturadas, que reproduce esos bytes exactos — al destino de la trama si la trama se envió, a la dirección que la recibió si llegó (en este equipo, cuando esa era todas las direcciones). Una porción TCP no puede: es un trozo de un flujo. Consulta Señales y Inspector.

Una señal UDP de texto se puede añadir a un experimento como paso Datagrama UDP; una hex no, porque el paso envía texto.

Desde la línea de comandos

signallab send udp envía un datagrama:

signallab send udp 127.0.0.1:9000 --text "PING"
signallab send udp 127.0.0.1:9000 --hex "de ad be ef"

✔ sent 4 bytes → 127.0.0.1:9000

Indica exactamente uno de --text y --hex. El destino es IP:port o host:port (arriba). Sale con 0 cuando el datagrama salió, 1 cuando el envío falló, y 2 cuando el destino o el hex no son válidos. No hay send tcp. Consulta Línea de comandos.

Tormenta

Tormenta es una fuente de carga para tus propios servidores y enlaces: un Inundación UDP envía datagramas de un tamaño fijo a una tasa fija, un Inundación de conexiones TCP abre una conexión, escribe la carga útil y cierra, una y otra vez. El caudal se mide en vivo. Consulta Tormenta.

Escáner

Escáner prueba una conexión TCP a cada puerto de un rango y lista los que aceptan, con lo que dice primero el servicio si pides banners. Consulta Escáner.

DANGER

Tormenta y Escáner envían tráfico real a hosts reales. Apúntalos solo a sistemas que sean tuyos o que puedas probar: una tormenta puede saturar un enlace, y ambos pueden activar la detección de intrusiones.

Dispositivos emulados

En la pantalla Emuladores, Signal Lab puede ser el dispositivo:

• un Dispositivo UDP responde a los datagramas según reglas sobre su carga útil — cualquiera, que contenga un texto, que coincida con una expresión regular, que contenga bytes — con una respuesta de texto o hex construida a partir de lo que llegó, al emisor o a otro IP:port, tras un retardo si lo defines;
• un Dispositivo TCP acepta conexiones, parte lo que llega en mensajes con un fin de línea que elijas (LF, CR LF, CR, o cada fragmento según llega), responde a cada uno con el mismo tipo de reglas, puede enviar un saludo cuando un cliente se conecta, y puede cerrar la conexión tras una respuesta.

Ambos pueden funcionar también como paso Emulador durante una ejecución. Consulta Emuladores.

Degradación

El relé de Degradación se sitúa entre un cliente y su destino y degrada lo que pasa: por datagrama sobre UDP (retardo, pérdida, duplicados, reordenación, un límite de ancho de banda) o por flujo sobre TCP (retardo, un límite de ancho de banda, conexiones restablecidas o dejadas semiabiertas). Consulta Degradación y, dentro de un experimento, Fallos.

"Puerto inalcanzable" en Windows

Cuando un datagrama llega a un puerto donde nada escucha, el equipo receptor suele responder con un mensaje ICMP "puerto inalcanzable". Windows informa de esa respuesta en la siguiente recepción del socket emisor, como si la conexión se hubiera restablecido — aunque UDP no tiene conexión.

Signal Lab cuenta con ello. Sus escuchas — el monitor OSC, la escucha de descubrimiento, las esperas y respuestas de los experimentos, los emuladores UDP y OSC, el relé de degradación — lo detectan y siguen escuchando. Un dispositivo que se ha ido no las detiene. Una escucha que de verdad no puede recibir más termina su tarea, y la consola dice por qué.

Problemas

Lo que ves	Causa habitual
… is not a valid address	El destino no tiene puerto, o no es ni IP:port ni host:port.
Cannot resolve …	El nombre de host no resuelve en este equipo.
… refused the connection — nothing is listening on that port (TCP)	Nada escucha en ese puerto, o un firewall lo rechaza.
No answer from … in time (TCP)	El host no responde en absoluto — dirección equivocada, o un firewall que descarta en lugar de rechazar.
Una espera agota el tiempo aunque el dispositivo responda	El dispositivo responde al puerto desde el que vino el datagrama, no al puerto de la espera. Deja que el envío espere él mismo la respuesta con esperar una respuesta: entonces sale desde el puerto al que vuelve la respuesta.
Los datagramas de otros equipos nunca llegan	En Windows, el firewall puede impedirlo: permite Signal Lab cuando la aplicación lo ofrezca. Consulta Solución de problemas.

Cada mensaje de error está en Mensajes de error.