Desconectar y reconectar un socket de datagramas conectado

Question

Iam tratando de crear un servidor iterativo basado en conectores de datagramas (UDP). Se llama a conectar con el primer cliente que se obtiene de la llamada primera recvfrom () (sí sé que esto no es real, la conexión). Después de haber servido a este cliente, desconecto el socket UDP (llamando a conectar con AF_UNSPEC) Entonces llamo recvfrom () para obtener el primer paquete de la siguiente cliente.

Ahora el problema es, que la llamada de recvfrom () en la segunda iteración del bucle vuelve 0. Mis clientes no enviar paquetes vacíos, así que lo que podría estar sucediendo.

Esto es lo que hace Iam (pseudocódigo):

s = socket(PF_INET, SOCK_DGRAM, 0)

bind(s)

for(;;)
{
  recvfrom(s, header, &client_address)  // get first packet from client
  connect(s,client_address)  // connect to this client
  serve_client(s);
  connect(s, AF_UNSPEC); // disconnect, ready to serve next client
}

EDIT: He encontrado el error en el envío de mi cliente accidentalmente un paquete vacío. Ahora mi problema es cómo hacer que el cliente espere a que nos sirvieran en lugar de enviar una solicitud a ninguna parte (servidor está conectado a otro cliente y no sirve cualquier otro cliente todavía).

Answer 1

connect () es realmente completamente innecesario en SOCK_DGRAM.

Llamar a conectar no impide que la recepción de paquetes de otras máquinas , ni se le impida el envío de ellos. Eso sí, no molesta, no es realmente útil.

CORRECCIÓN: sí, parece ser que impide que la recepción de paquetes de otras máquinas. Pero hacer esto en un servidor es un poco tonto, porque cualquier otro cliente se bloquean mientras estabas connect () Ed a uno. También usted todavía necesita coger "paja" que flotan alrededor. Probablemente hay algunas condiciones de carrera asociados con connect () en un socket DGRAM -? Qué ocurre si se llama a conectar y paquetes de otros anfitriones ya está en el buffer

Además, 0 es un valor válido de retorno de recvfrom (), como (sin datos) paquetes vacíos son válidos y pueden existir (de hecho, la gente suele usar ellos). Así no se puede comprobar si algo ha conseguido de esta manera.

Con toda probabilidad, un paquete de cero bytes estaba en la cola ya.

Su protocolo debe ser diseñado para minimizar la posibilidad de un datagrama errante ser mal interpretado; por esta razón me gustaría sugerir que no utiliza datagramas vacías, y utilizar un número mágico lugar.

aplicaciones UDP debe ser capaz de reconocer los paquetes de "paja" y soltándolos; van a subir más pronto o más tarde.

Answer 2

man connect:

...
If the initiating socket is not connection-mode, then connect()
shall set the socket’s peer address, and no connection is made.
For SOCK_DGRAM sockets, the peer address identifies where all
datagrams are sent on subsequent send() functions, and limits
the remote sender for subsequent recv() functions. If address
is a null address for the protocol,  the  socket’s  peer  address
shall be reset.
...

Answer 3

Sólo una corrección en caso de que alguien stumbples a través de este como lo hice. Para desconectar la conexión () debe ser llamado con el miembro de sa_family sockaddr establecido en AF_UNSPEC. No acaba de pasar AF_UNSPEC.