Resumen

  • RFC 2013 definió cuatro Counter32 de solo lectura para la entidad UDP completa: datagramas entregados a usuarios UDP, recibidos sin aplicación en el puerto de destino, no entregados por otros errores y enviados desde la entidad.
  • udpTable identificaba un escucha actual únicamente por dirección IPv4 local y puerto local. No incluía dirección o puerto remotos, proceso, instancia reutilizada del socket ni identidad de un datagrama.
  • RFC 4113 añadió tipos de dirección, extremos local y remoto, un discriminador de instancia y el proceso del sistema operativo. La identidad mejoró, pero el procesamiento de la aplicación y el resultado siguieron necesitando pruebas aparte.

El panel sumaba disposiciones, no episodios

Los cuatro escalares de RFC 2013 tenían denominadores concretos. udpInDatagrams acumulaba datagramas entregados a usuarios UDP. udpNoPorts acumulaba los recibidos para los que no había aplicación en el puerto de destino. udpInErrors reunía los que no podían entregarse por cualquier otra razón. udpOutDatagrams contaba los enviados desde la entidad.

Ese reparto permite distinguir resultados dentro del motor UDP. Sin embargo, todos son totales de la entidad. No están indexados por endpoint, no retienen al par remoto, no nombran un proceso, no marcan la hora y no vinculan una entrada con una salida. Una subida simultánea en dos gráficas es compatible con muchas historias y no selecciona una sola.

RFC 1902 impone otra precaución. Counter32 aumenta hasta 2^32−1 y vuelve a cero; no tiene valor inicial definido; una lectura aislada carece, en general, de contenido informativo; una reinicialización puede interrumpir la serie. Interpretar una diferencia exige dos muestras y continuidad. La diferencia obtenida sigue sin decir qué puerto o programa la produjo.

El índice terminaba en el lado local

udpTable contenía endpoints en los que una aplicación local aceptaba datagramas. Su índice era udpLocalAddress más udpLocalPort. La dirección 0.0.0.0 representaba la voluntad de escuchar en cualquier interfaz local; el número de puerto podía ir de 0 a 65535.

La fila respondía una pregunta de inventario: ¿qué coordenada IPv4 local representaba el agente como escucha en ese instante? No respondía quién estaba al otro lado. Tampoco decía qué proceso poseía el socket, si varios sockets reutilizaban la misma tupla, cuándo apareció la fila o cuántos datagramas correspondían a ella.

La frase “aceptando datagramas” no debe convertirse en “la aplicación completó la operación”. La presencia del escucha no demuestra que el programa leyera un datagrama concreto, entendiera su contenido, autorizara una petición o cambiara un estado. Mucho menos prueba que una respuesta salió, llegó o resolvió la necesidad del usuario.

La entrega a un usuario UDP era una frontera intermedia

El texto de udpInDatagrams sí afirma algo más fuerte que la mera llegada a una interfaz: entrega a usuarios UDP. Es una evidencia real de la capa de transporte. Reducirla a “se vio un paquete” perdería información. Promoverla a “la aplicación tuvo éxito” añadiría información inexistente.

El contador no sabe si el proceso retiró los bytes del búfer, si el formato fue válido o si hubo una acción. udpNoPorts sabe que faltaba una aplicación de destino para esos datagramas, pero no conserva su emisor. udpInErrors agrega todas las demás causas. udpOutDatagrams termina en el envío desde la entidad; no da fe de recepción remota.

Así, una conversación requiere una unión externa: identidad del datagrama o evento, estado del endpoint, ciclo del proceso, recibo de la aplicación y observación del resultado.

RFC 4113 amplió la superficie de atribución

RFC 4113 sustituyó a RFC 2013 en 2005. Mantuvo los cuatro contadores básicos y deprecó la tabla antigua por dos motivos diferentes: solo cubría IPv4 y no podía describir endpoints UDP “conectados”. El primer motivo no es la tesis de este artículo. El segundo muestra que el índice local no bastaba para describir la conducta del endpoint.

udpEndpointTable podía representar un escucha con remoto comodín o un endpoint limitado a una dirección y puerto remotos. Su índice incluía tipo, valor y puerto locales; tipo, valor y puerto remotos; y udpEndpointInstance. La instancia distinguía procesos múltiples sobre una misma tupla en casos de reutilización. udpEndpointProcess comunicaba el identificador de proceso, o cero, y permitía correlacionarlo con MIB de recursos o aplicaciones.

Esto responde mejor “¿qué endpoint y qué proceso?”. No convierte UDP en transporte fiable ni cada fila en conversación. Un PID puede faltar o reutilizarse. Un remoto configurado es una restricción del socket, no prueba de que un datagrama específico se intercambió. La tabla tampoco certifica análisis, autorización, respuesta o efecto de servicio.

La información adicional incluso aumenta el riesgo de lectura. RFC 4113 advirtió que los índices revelaban puertos abiertos. La tabla no era un interruptor como el objeto TCP de RFC 2012, pero observarla seguía requiriendo control de acceso.

Una conclusión válida conserva la unidad observada

RFC 2013 no fracasó por ser pequeño. El error sería usarlo como si hubiera registrado más de lo que definió. “El contador de toda la entidad aumentó entre dos muestras continuas” es defendible. “Este servicio recibió esta solicitud” necesita una unión adicional. “La aplicación la procesó” necesita un recibo de la aplicación. “El usuario obtuvo el resultado” necesita una medida de servicio.

Un puerto es una coordenada local. Un contador es un total con un denominador. Una conversación es una secuencia atribuida. RFC 4113 hizo explícitas más coordenadas de la secuencia, sin escribir el desenlace por decreto.

Fuentes

Límites de la evidencia

Las fuentes prueban el linaje documental, las definiciones de objetos, la semántica de los contadores y el modelo sucesor. No prueban implementación de un proveedor, despliegue, configuración actual, defecto, incidente, SLA, tráfico medido ni resultado de aplicación.