No se puede asignar la dirección solicitada: ¿causas posibles?

Question

Tengo un programa que consta de un servidor maestro y servidores esclavos distribuidos. Los servidores esclavos envían actualizaciones de estado al servidor, y si el servidor no ha tenido noticias de un esclavo específico en un período fijo, marca al esclavo como inactivo. Esto está sucediendo consistentemente.

Al inspeccionar los registros, he encontrado que el esclavo solo puede enviar una actualización de estado al servidor, y nunca puede enviar otra actualización, siempre fallando en la llamada de connect() "No se puede asignar la dirección solicitada (99).

Por extraño que parezca, el esclavo puede enviar varias otras actualizaciones al servidor, y todas las conexiones están sucediendo en el mismo puerto. Parece que la causa más común de esta falla es que las conexiones son dejado abierto, pero estoy teniendo problemas para encontrar algo que quede abierto. ¿Hay otras posibles explicaciones?

Para aclarar, así es como me estoy conectando:

struct sockaddr *sa; // parameter 
size_t   sa_size; //parameter 
int    i = 1; 
int    stream; 

stream = socket(AF_INET,SOCK_STREAM,0); 
setsockopt(stream,SOL_SOCKET,SO_REUSEADDR,&i,sizeof(i)); 
bindresvport(stream,NULL); 
connect(stream,sa,sa_size); 

Este código está en una función para obtener una conexión a otro servidor, y una falla en cualquiera de esas 4 llamadas hace que la función falle.

Answer 1

Quizás SO_REUSEADDR ayude aquí? http://www.unixguide.net/network/socketfaq/4.5.shtml

Answer 2

esto es sólo un tiro en la oscuridad: cuando se llama a conectarse sin un aprieto en primer lugar, el sistema asigna el puerto local, y si usted tiene múltiples hilos de conexión y desconexión que podría tratar de asignar un puerto que ya están en utilizar. el archivo fuente del kernel inet_connection_sock.c alude a esta condición. de la misma manera que en un experimento, intente realizar un enlace a un puerto local primero, asegurándose de que cada enlace/conexión utiliza un número de puerto local diferente.

Answer 3

Resultó que el problema en realidad era que la dirección estaba ocupada; el ajetreo estaba causado por otros problemas en la forma en que manejamos las comunicaciones de red. Tus aportes me han ayudado a resolver esto. Gracias.

EDIT: Para ser específicos, los problemas en el manejo de nuestras comunicaciones de red fueron que estas actualizaciones de estado serían reenviadas constantemente si la primera fallara. Era solo cuestión de tiempo hasta que todos los esclavos distribuidos intentaran enviar su actualización de estado al mismo tiempo, lo que saturaba demasiado nuestra red.

Answer 4

sysctl -w net.ipv4.tcp_timestamps=1 
sysctl -w net.ipv4.tcp_tw_recycle=1