2010-03-04 16 views
7

Soy bastante nuevo en la programación y en la programación de redes esp, así que si es estúpido, no golpee demasiado, por favor, gracias.UDP y sockets, recvfrom() que devuelve -1 y el recurso no está disponible temporalmente

Tengo cliente y servidor que se comunican con diagramas (UDP) en C. el cliente envía 5 msgs y al recibir mensajes, el servidor envía mensajes de vuelta. recibir y enviar mensajes es excelente hasta que el cliente haya terminado de recibir los mensajes. después de que el servidor envíe todos los msgs, termina usando close(). entonces recvfrom() del cliente debería devolver 0, ¿verdad?

suponiendo que recvfrom() debe devolver 0 al cerrar() desde el lado del servidor, devuelve -1 en su lugar, con el error Recurso temporalmente no disponible. ¿Esta referencia de recurso a socket cerrado del servidor? ¿o es por algo completamente diferente como quedarse sin buffer o algo así (que no creo que sea cierto)?

y asumiendo mi suposición era errónea y se devuelve -1 porque el servidor terminado, probablemente debería manejar el error con

if(SOMEMACRO) 
    do something 

pero ¿cómo puedo averiguar qué es SOMEMACRO? Imprimo el error pero dice que la temperatura de los recursos no está disponible y la descripción de recvfrom() no menciona los recursos no disponibles.

por cierto este es un socket sin bloqueo, si eso hace alguna diferencia ya que leí que si se configura O_NONBLOCK y no hay msgs disponibles, se establecería errno en EAGAIN o EWOULDBLOCK. O_NONBLOCK no está configurado pero MSG_DONTWAIT está configurado. ¿son básicamente lo mismo donde O_NONBLOCK es para los descriptores de archivos generales y MSG_DONTWAIT es específico del socket?

Mi cerebro no está funcionando tan bien ahora, si alguien pudiera aclararme y aclarar de qué se trata mi confusión, lo agradecería profundamente. ¡Gracias!

Respuesta

13

UDP es un protocolo sin estado, a diferencia de TCP, que es orientado a la conexión. Su código de recepción no sabrá si el emisor ha cerrado o no su socket, solo sabe si hay datos a la espera de ser leídos o no. De acuerdo con la página del manual de recvfrom en Linux:

Si no hay mensajes disponibles en el zócalo, la reciben llamadas esperar a que llegue un mensaje, a menos que el conector está sin bloqueo (ver fcntl (2)), en cuyo caso se devuelve el valor -1 y la variable externa errno se establece en EAGAIN.

Esto parece ser lo que está sucediendo para usted

Editar: Tenga en cuenta que "los recursos disponibles en estos momentos" y EAGAIN son el mismo error, uno es sólo la descption fácil de usar contra el nombre de definir.Básicamente es solo decirle que está tratando de leer desde el zócalo y no hay datos para leer

+1

Entonces, si está utilizando UDP, ¿recvfrom() alguna vez devolvería 0? ya que nunca se sabe si el par ha realizado un apagado ordenado –

+2

@Fantastic Fourier: UDP realmente puede enviar un datagrama que es solo el IP y los encabezados UDP pero sin carga de datos. Es perfectamente legal y le parecerá una lectura de 0 bytes. – Duck

+0

@Fantastic Fourier: Estrictamente hablando, dado que no hay una "conexión" en UDP, no hay nada que cerrar, ordenado o de otro modo. – Duck

2

Después de haber cerrado el zócalo, aún permanece por algún tiempo. Por lo general, alrededor de dos minutos más o menos. Para evitar esto, use la opción de socket SO_REUSEADDR.

Aquí hay algunas referencias para usted.

http://msdn.microsoft.com/en-us/library/ms740476%28VS.85%29.aspx http://docs.hp.com/en/B2355-90136/ch03s01.html

Y aquí es un ejemplo, desplazarse hacia abajo a la función udp_listen:

http://www.codase.com/search/display?file=L2dlbnRvbzIvdmFyL3RtcC9yZXBvcy9jb2Rhc2UuYy9zbGlycC0xLjAuMTYvd29yay9zbGlycC0xLjAuMTYvc3JjL3VkcC5j&lang=c&off=15730+15796+

Cuestiones relacionadas