sockets - recibir - Servidor vs cliente socket(detalles de bajo nivel)?

sockets en java pdf

Question

Programación general: en un servidor, el método accept () acepta lo que sucede exactamente. A bajo nivel, ¿cómo los sockets de servidor son diferentes de los sockets de los clientes?

Answer 1

Es difícil responder completamente a su pregunta sin especificar un lenguaje de programación. Voy a responder con respecto a Python, porque por lo que sé, la respuesta podría ser representativa.

Si s es un objeto de socket , entonces un servidor primero se vincula a un puerto llamando a s.bind(('''',12345)) . Esto crea un socket en modo servidor. Está preparado para capturar datos en el puerto 12345.

Entonces uno llama a la parte s.listen(10) . Esto arroja el zócalo al modo de servidor. Esto significa que este socket recibe una solicitud de conexión (hasta 10 solicitudes pendientes a la vez).

En el momento en que llegamos a s.accept() , el sistema operativo ya sabe que estamos escuchando en el puerto 12345. s.accept() simplemente dice lo que vamos a hacer con las solicitudes que recibimos. En python, s.accept() devolverá (connection,address) donde la conexión es una conexión a través de otro puerto. En este caso, la connection no es muy diferente del objeto socket que el cliente ha abierto. Es razonablemente simétrico de aquí en adelante.

Answer 2

Si está realmente interesado, le aconsejo que lea TCP / IP Illustrated, Volumen 2 . Si quieres una respuesta menos "in the guts", entonces:

• Los sockets de servidor están vinculados a puntos finales bien conocidos donde un punto final es la tupla (protocolo, dirección, puerto). El punto final está formado por el protocolo especificado en la llamada al sistema socket() y la información de direccionamiento especificada en la llamada al sistema bind() .
• Cuando el servidor llama a la llamada al sistema listen() , la pila de red crea una cola en la que se colocan las conexiones pendientes. Una sugerencia para el tamaño de la cola se da como el parámetro de backlog para listen() .
• El servidor llama a accept() para extraer una nueva conexión de la cola.
• Los sockets de los clientes envían mensajes a los sockets del servidor especificando el punto final del servidor en una llamada para connect() y luego enviar datos usando send() o write() .
• Cuando el cliente llama a connect() , se envía una conexión a la cola del servidor donde se encuentra hasta que el servidor acepta la conexión .

Sin embargo, esta descripción solo es válida para zócalos TCP / IP. El caso UDP es más simple y bastante diferente ya que los sockets UDP no están (necesariamente) conectados.

Answer 3

En primer lugar, los sockets de servidor generalmente están vinculados a nombres bien conocidos (puertos, en este caso) y se establecen con listen() . Ahí es donde ocurre la diferencia real, a medida que los sockets del cliente se establecen con connect() . Llamar a listen() en un socket provoca que la implementación tcp / ip del kernel comience a aceptar conexiones enviadas al nombre (puerto) encuadernado del socket. Esto sucederá ya sea que llame o no a accept() .

accept() simplemente le da a su servidor una forma de acceder e interactuar con los sockets de clientes que se han conectado a su socket de escucha.

Answer 4

En un nivel bajo, los sockets son solo sockets independientemente de si se están utilizando en un servidor o aplicación cliente. La diferencia entre las dos reside en las llamadas al sistema que realiza cada tipo de aplicación.

Los sockets de servidor llamarán a bind() para que se asocie con un puerto. Quieren asociarse con un puerto para que otros programas sepan dónde llegar a ellos. Los sockets de cliente pueden llamar a bind() pero casi nunca lo hacen porque no tiene mucho sentido. Si un socket no llama a bind() el sistema operativo simplemente elegirá un puerto efímero para él, lo cual está bien para los clientes porque están haciendo la llamada; nadie necesita llamarlos.

Los sockets de servidor llaman a listen() . Esto fue explicado bastante bien en las otras respuestas.

Los sockets de servidor llaman a accept() y creo que este es el quid de tu pregunta porque al principio es un poco misterioso. Lo importante de entender es que al llamar a accept() el kernel devolverá un nuevo socket. Ahora está separado del socket de escucha original y es lo que usará su servidor para comunicarse con su (s) par (es).

La clave para entender cómo el socket de escucha continúa escuchando mientras la conexión aceptada está haciendo su trabajo es comprender que las conexiones de tcp dependen de una tupla de 4 (1) dirección local (2) puerto local (3) dirección en el extranjero (4) puerto extranjero. Estos definen una conexión única. Antes de que accept() devolviera el nuevo socket, el kernel usaba estos valores para crear varias estructuras, de modo que, en colaboración con la pila tcp / ip, todo el tráfico con esta tupla irá al socket conectado. Aunque su servidor puede tener mil conexiones con la dirección local 192.168.1.100 puerto 80, la combinación de dirección y puerto del cliente siempre será diferente y, por lo tanto, la tupla es siempre única.