¿Cómo un puerto "escucha", tira o empuja?

Cuando escribe un código para escuchar desde un puerto, como 80 por ejemplo, ¿qué sucede debajo del capó? ¿El método que utiliza el sistema operativo para escuchar es pull o push? En otras palabras, ¿el sistema operativo comprueba ese puerto cada x milisegundos, por ejemplo?

Simplemente no entiendo. Cuanto más lo pienso, más me parece que no puede ser otra cosa que tirar.

Quiero decir, incluso si el sistema operativo establece una función de devolución de llamada, todavía algo debería entender que ha llegado nueva información para llamar a esa función de devolución de llamada. Ese algo aún debería usar pull para comprender la llegada de los nuevos datos.

¿Cómo escucha un puerto?

Teóricamente, esto depende de los detalles del sistema operativo y el hardware de la red. En la práctica, los sistemas operativos y el hardware convencionales utilizan un modelo de inserción basado en interrupciones para la interacción entre el hardware y el sistema operativo (y todo el software controlado por el sistema operativo).

Básicamente, una interrupción es un mecanismo de muy, muy bajo nivel a través del cual el hardware periférico puede indicarle a la CPU que hay un evento que debe manejarse (como un paquete de red que llegó, una tecla presionada, etc.). La CPU reacciona a esto suspendiendo lo que estaba haciendo en ese momento y ejecutando un controlador de interrupción.

El manejo de interrupciones generalmente lo realiza el sistema operativo o al menos lo inicia el sistema operativo y se entrega a un código de aplicación más específico que se ha registrado como interesado en un tipo particular de evento.

OK, no soy un ingeniero de hardware de Ethernet, pero creo que puedo responder a tu pregunta. Cuando escribe código para escuchar desde un puerto, sucede lo siguiente:

• El código de su aplicación bloquea / duerme / "selecciona" / sondea hasta que el sistema operativo señala que ha llegado un paquete (con algunos bits en el encabezado IP que indican que el paquete está asociado con ese "puerto" particular y, por lo tanto, con su aplicación que está escuchando en ese puerto)
• El sistema operativo generalmente no sondea (en arquitecturas x86 / PC) para nuevos paquetes, simplemente se ejecuta alegremente hasta que recibe una interrupción del hardware de la red Ethernet (transmitida por el controlador de red Ethernet, la interfaz del sistema operativo / hardware).
• El hardware de la red Ethernet en sí mismo debajo de las cubiertas generalmente contiene un controlador Ethernet y algunos "buffers de recepción", también conocidos como "buffers de paquetes". El controlador de red Ethernet administrará los detalles de notar que un búfer está lleno y se debe notificar al sistema operativo; No estoy totalmente claro si esto es típicamente push o pull dentro del hardware de Ethernet, pero sospecho que es impulsado por interrupción, o algún registro en el chip se establece cuando un búfer está listo. Pero, ¿qué establece los amortiguadores?
• Incluso una porción de nivel inferior del hardware de Ethernet llena los búferes (o paquetes DMA directamente en la memoria principal). Una lógica de muy bajo nivel reconoce realmente las oscilaciones en el voltaje (o la señalización óptica) y las traduce como "bits" y coloca los resultados en las memorias intermedias receptoras de paquetes (y quizás establece valores de registro dentro del hardware de Ethernet). (Nota al margen: antes de las tarjetas de interfaz de red, cuando las personas usaban conexiones de puerto serie / paralelo, un solo byte entrante podría generar una interrupción de hardware (IRQ) al sistema operativo; consulte el párrafo cuatro de http://zone.ni.com/devzone / cda / tut / p / id / 4052 )
• ¿Cómo sabe ese hardware de nivel más bajo lo que constituye un "bit"? Bueno, Ethernet , al menos la mayoría de los más antiguos / comunes, usa Manchester Coding para decodificar oscilaciones de voltaje como bits. ¿Qué implica eso? Bueno, como menciona esa página, existe una suposición subyacente de que cada bit se transmite en un tiempo fijo, una señal de reloj implícita. (Esta es la razón por la cual las velocidades de Ethernet en los estándares se fijan en 10Mb / s, 100Mb / s, 1000Mb / s, etc., y no son completamente variables; ambos lados de la conexión de Ethernet deben estar de acuerdo con la velocidad de transmisión a través de la configuración o algún mecanismo inicial de comunicación cuando el cable Ethernet está enchufado. Hay un circuito de reloj real en el hardware a ambos lados del cable que admite esas una o más de esas frecuencias. A veces, la frecuencia de este reloj se llama frecuencia o frecuencia de señalización). llámelo muestreo, no sondeo / extracción,

Entonces, su intuición de que se produce un "tirón" es, en el nivel de hardware más bajo, tal vez correcto ... el circuito Ethernet "tira" de cuál es el nivel de voltaje en ciertos intervalos. (Pero el término "jalar" puede ser francamente incorrecto si se habla al nivel del sistema operativo). Por supuesto, si comienza a hablar sobre los niveles de voltaje y exactamente cómo se desencadenan las cosas, ni la física eléctrica ni la óptica usarán los términos "empuje" "o" pull "para describir campos eléctricos y potenciales, pero supongamos que todos somos programadores, no físicos aquí. :-)

El código que escucha un puerto solo espera un mensaje de la red.

Cada vez que el chip Ethernet recibe un mensaje, se genera una interrupción. El núcleo maneja esta interrupción y reenvía el mensaje al controlador de red. Ese mensaje pasa por la pila TCP / IP y se filtra o se pasa al código que escucha el puerto.

El hardware de Ethernet será el que sondeará el cable físico (o inalámbrico). Cuando tiene una razón 'suficientemente buena', interrumpirá el procesador. El procesador calculará nuestro controlador adecuado que manejará la interrupción. El controlador de interrupciones manejará el evento (datos de lectura / escritura). El controlador también le indicará al sistema operativo que active cualquier subproceso en espera.