La baliza y el equipo, con el reloj corregido

La baliza repite casi siempre el mismo intercambio: el equipo envía lo mismo y el servidor contesta con una respuesta corta, «nada nuevo». Cuando una respuesta es mucho mayor que las demás, el servidor entregó algo a ese equipo. Es el único momento en que la baliza deja ver que hubo una orden o un material nuevo, y por eso su hora es de las más valiosas del caso: es el punto desde el que mirar lo que hizo el equipo.

Lo que no dice es qué se entregó ni quién lo pidió. Dice que a esa hora el servidor tenía algo y el equipo lo recibió.

La red solo ve direcciones y puertos. El equipo, en cambio, guarda una tabla de conexiones con el proceso dueño de cada una, identificado por su pid. Esa tabla se copia cuando todavía está el equipo encendido y la conexión abierta; apagarlo o aislarlo antes de copiarla puede perder la fila.

Cruzar la dirección de destino de la baliza con esa tabla es la forma más directa de poner nombre al programa. El pid que aparezca es el que luego se busca en el registro de procesos.

Para cruzar la red con el equipo hay que saber cuánto se equivoca el reloj del equipo, y se mide con un ancla: un hecho que dejó huella en los dos lados. El servidor lo anotó en UTC con un reloj bueno y el equipo en su hora local con el suyo. Se pasa la hora del servidor a la zona del equipo y se resta la que anotó el equipo: lo que sobra son segundos de error.

Dos anclas que den el mismo número dan confianza. Si dan distinto, el reloj se movió entre una y otra y hay que ser prudente con todo lo que caiga entre las dos.

Con el error medido, se corrigen las horas del equipo (si va atrasado, se suma) y se pasan a UTC. Las del equipo y las de la baliza ya se pueden poner en la misma línea. La pregunta es qué ocurrió en el equipo justo después de la respuesta grande: un proceso que nace segundos más tarde y que es hijo del proceso dueño de la conexión sostiene que lo recibido se ejecutó.

Cuidado con el atajo. Si no se corrige el reloj, un evento puede parecer casi simultáneo a la respuesta por pura casualidad, y estar antes que ella: lo que ocurre antes de una orden no puede ser su efecto.

El cruce da un hecho sólido: a esa hora la red vio llegar algo al equipo y, segundos después, un proceso hijo del que mantiene el canal empezó a ejecutarse. Es coherente con que el equipo ejecutara lo recibido. No dice quién envió la orden, desde dónde ni con qué intención, y no se puede construir una historia mayor encima. Y el reloj mal puesto no invalida el cruce: se mide, se corrige y se declara en el informe.