Triangular con Ping [cerrado]

La respuesta es SÍ, pero con muchas advertencias. Permítame reformular la pregunta en una forma más útil:

Utilizando solo paquetes Ethernet, en una red Ethernet, ¿puede determinar la longitud del cable físico de un dispositivo a otro?

Existe un estándar llamado Precision Time Protocol (PTP), que se utiliza para sincronizar los relojes de los dispositivos en una red. El protocolo básico puede lograr una precisión de microsegundos, pero hay maneras de obtener una precisión de hasta 10 segundos de nanosegundos.

Parte de este protocolo requiere una marca de tiempo basada en hardware de los paquetes de Ethernet para poder medir y calcular el "tiempo de vuelo" de un paquete a través de un cable Ethernet. Este tiempo de medición de vuelo se usa para ajustar cualquier desviación del reloj en la red. En nuestro caso, solo nos importa el tiempo de vuelo.

Si bien esto funciona a través de los conmutadores y enrutadores Ethernet, para obtener un tiempo de vuelo preciso, el conmutador necesita ser compatible con PTP y participar en las mediciones. PTP apoya la participación de los conmutadores y enrutadores. Debido a que PTP usa paquetes de multidifusión, no funcionará a través de Internet.

Cada vez más controladores Ethernet admiten PTP (incluso algunas placas madre de PC lo admiten), aunque la compatibilidad del conmutador y del enrutador se está retrasando bastante.

En teoría, PTP puede hacer esto. En la práctica, no sé si puede extraer la hora de los datos de vuelo de este protocolo de sincronización de reloj, pero los datos están ahí. Puede requerir algunas implementaciones de PTP un tanto personalizadas, y definitivamente requiere conmutadores / enrutadores que son raros o no están del todo en el mercado todavía. También estoy masivamente generalizando PTP. Conozco el lado del hardware de PTP, pero hay una gran cantidad de software que no conozco completamente.

Otra alternativa a PTP es usar Ethernet Phy que puede medir la longitud del cable. Resulta que muchos Gigabit Ethernet Phy pueden hacer esto ahora, pero esas características rara vez se exponen más allá del nivel del controlador del dispositivo. Los Phy hacen esto mediante el uso de reflectometría en el dominio del tiempo, y también pueden medir la distancia a la ruptura en un cable defectuoso.

El principal problema con todo esto es que mide la longitud del cable, no la posición física. Si los cables se midieron con precisión y se estiraron en línea recta, eso podría determinar la ubicación física. Pero eso nunca sucede. También requiere que la infraestructura de red esté bajo su control, lo cual probablemente no lo esté.

Por supuesto, lo que describo no es nada como usar los tiempos de ping en Internet para obtener una ubicación física. Estoy de acuerdo con los demás en que esto no va a ser muy útil y, probablemente, no te dará nada más preciso que el Continente en el que estás (si es eso).

Esta no es una pregunta de ingeniería eléctrica, pero la respuesta es No.

Las distancias de enrutamiento de la red a través de Internet tienen poca relación con la ubicación geográfica.

Dos computadoras en la misma ciudad, pero conectadas a Internet a través de diferentes ISP, pueden realizar rutas a través de una ciudad a cientos de millas de distancia.

No, porque el retardo de la respuesta de ping no es una función de la distancia. Es mucho más fuertemente una función de la cantidad de saltos (enrutadores e interruptores) entre las dos máquinas que la distancia física. El retraso de estos enrutadores e interruptores es mucho más largo que los retrasos de propagación a través del cable. También dependen en gran medida de la arquitectura exacta del conmutador o enrutador, la versión del firmware, la carga actual debida a otros paquetes y varios otros parámetros que son impredecibles y no una función de la distancia.

Míralo de otra manera. ¿Cuál sería el retraso de la propagación pura debido a la distancia? La distancia física más lejana sería el otro lado del planeta, que es un viaje de alrededor de 40 Mm. Digamos que la velocidad de propagación de la señal a través de los cables es aproximadamente la mitad de la velocidad de la luz, o aproximadamente 150 Mm / s. Eso significa unos 270 ms de ida y vuelta. Pero, esos saltos implementados con enlaces de microondas serían a la velocidad de la luz, o dos veces más rápido. Si la señal rebotó en un satélite, la velocidad de propagación es la velocidad de la luz, pero la longitud del camino ahora es mucho más larga. La misma demora podría ser fácilmente introducida por algunos enrutadores muy cargados en la ruta.

Otra forma de ver esto es cuál es la distancia del cable que causaría 1 ms de retraso. Una vez más, suponiendo que la velocidad de 150 Mm / s en el cable, 1 ms sería el equivalente a 150 km de ida y vuelta del cable, para una distancia de 75 km. Por lo tanto, solo un mero de error le da un error de 75 km de distancia, pero el retraso en un solo enrutador puede ser más que eso.

Luego está el retraso en el procesamiento para recibir el paquete de ping, verificarlo, generar una respuesta y enviarlo. Eso es muy rápido en una computadora convencional moderna, pero puede ser significativo en un pequeño sistema integrado.

Por ejemplo, acabo de hacer ping a un pequeño sistema con la pila de red ejecutándose en un PIC 18F67J60 desde mi PC. Está a aproximadamente 1 metro de distancia en mi banco, pero los cables son mucho más largos que eso y hay un interruptor entre las dos máquinas. El tiempo de respuesta de ida y vuelta informado por mi PC fue de 4 ms, lo que implicaría una distancia de 300 km si se supone que todo se debió a un retraso de propagación en un cable. En realidad, sé que la mayor parte de ese retraso fue el procesamiento del paquete de ping y el envío de la respuesta en el PIC. Eso fue con el tamaño de carga útil predeterminado, que ni siquiera estoy seguro de qué es. Con 128 "tamaño de búfer" especificado para el comando ping, el tiempo de respuesta es de 11 ms, y con 1024 bytes es de 76 ms.

Incluso si pudiera resolver el problema de dónde se encuentra cada nodo en la ruta, y podría asignar los retrasos de conmutación, la variación en los tiempos de ping lo mataría.

Acabo de hacer cinco pings en mi servidor y obtuve avg = 55ms, stddev 0.896ms

A 1 pie / nS, es equivalente a 55000000 pies del servidor, o 10,000 millas, con una incertidumbre de 170 millas.

¡Estoy bastante seguro de que mi servidor no está saltando cientos de millas entre pings!

Y su método, incluso si funcionara, lo cual no funcionaría (ver la respuesta de jwgr), solo encontraría el ISP del usuario. Hice ping a mi ISP, obtuve 5 ms. Así que sé que estoy dentro de un círculo de 1000 millas alrededor del ISP. Tampoco es muy útil.