Impossibile assegnare l'indirizzo richiesto - possibili cause?

Question

Ho un programma che consiste in un server master e server slave distribuiti. I server slave inviano aggiornamenti di stato al server e, se il server non ha ricevuto notizie da uno specifico slave in un determinato periodo, contrassegna lo slave come inattivo. Questo sta accadendo in modo coerente.

Dall'analisi dei registri, ho rilevato che lo slave è in grado di inviare solo un aggiornamento di stato al server e quindi non è mai in grado di inviare un altro aggiornamento, sempre in mancanza della chiamata per connettersi() "Impossibile assegnare l'indirizzo richiesto (99)

Stranamente, lo slave è in grado di inviare diversi altri aggiornamenti al server e tutte le connessioni si verificano sulla stessa porta. Sembra che la causa più comune di questo errore sia che le connessioni sono lasciato aperto, ma ho difficoltà a trovare qualcosa lasciato aperto Ci sono altre possibili spiegazioni?

Per chiarire, ecco come mi sto connettendo:

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); 

Questo codice è in una funzione per ottenere una connessione a un altro server e un errore in una di queste 4 chiamate causa la mancata riuscita della funzione.

Answer 1

Forse SO_REUSEADDR aiuta qui? http://www.unixguide.net/network/socketfaq/4.5.shtml

Answer 2

questo è solo un salto nel buio: quando si chiama connettersi senza un vicolo cieco prima, il sistema assegna la porta locale e se si dispone di più thread di collegare e scollegare forse potrebbe cercare di allocare già in un porto uso. il file sorgente del kernel inet_connection_sock.c suggerisce questa condizione. proprio come un esperimento, provare prima a collegarsi a una porta locale, assicurandosi che ogni collegamento/connessione utilizzi un numero di porta locale diverso.

Answer 3

Si è scoperto che il problema era che l'indirizzo era occupato: l'attività era causata da altri problemi nel modo in cui gestiamo le comunicazioni di rete. I tuoi input mi hanno aiutato a capirlo. Grazie.

MODIFICA: per essere specifici, i problemi nella gestione delle nostre comunicazioni di rete erano che questi aggiornamenti di stato sarebbero costantemente re-inviati se il primo non era riuscito. Era solo una questione di tempo prima che tutti gli slave distribuiti provassero a inviare il suo aggiornamento di stato nello stesso momento, il che stava saturando la nostra rete.

Answer 4

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