Ik heb een programma dat bestaat uit een master-server en gedistribueerde slavenservers. De Slave-servers verzenden statusupdates naar de server en als de server niet van een specifieke slaaf in een vaste periode heeft gehoord, markeert het de slaaf als naar beneden. Dit gebeurt consequent.
Vanuit het inspecteren van logboeken heb ik gevonden dat de slaaf alleen in staat is om één statusupdate naar de server te verzenden, en dan is dan nooit in staat om een andere update te verzenden, altijd niet op de oproep om te verbinden () “kan het gevraagde adres niet toewijzen ( 99).
Vreemd genoeg is de slaaf in staat om verschillende andere updates naar de server te sturen, en alle aansluitingen gebeuren op dezelfde poort. Het lijkt erop dat de meest voorkomende oorzaak van deze mislukking is dat verbindingen open blijven, maar ik heb problemen met het vinden van iets dat open is. Zijn er andere mogelijke verklaringen?
Om te verduidelijken, hier is hoe ik aan het verbinden is:
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);
Deze code is in een functie om een verbinding met een andere server te verkrijgen en een fout op een van die 4 oproepen zorgt ervoor dat de functie faalt.
Antwoord 1, Autoriteit 100%
Misschien helpt So_ReusEaddr hier?
http://www.unixguide.net/network/SocketFAQ/4.5.SHTML
Antwoord 2, Autoriteit 118%
Het bleek dat het probleem echt was dat het adres bezet was – de drukte werd veroorzaakt door een aantal andere problemen in de manier waarop we omgaan met netwerkcommunicatie. Uw input heeft me geholpen dit te achterhalen. Dank je.
BEWERK:om specifiek te zijn, de problemen bij het afhandelen van onze netwerkcommunicatie waren dat deze statusupdates constant opnieuw zouden worden verzonden als de eerste mislukt. Het was slechts een kwestie van tijd voordat elke gedistribueerde slaaf tegelijkertijd zijn statusupdate probeerde te verzenden, waardoor ons netwerk oververzadigd raakte.
Antwoord 3, autoriteit 45%
dit is slechts een schot in het duister: wanneer u eerst connect zonder een binding aanroept, wijst het systeem uw lokale poort toe, en als u meerdere threads hebt die verbinding maken en de verbinding verbreken, kan het mogelijk proberen een poort toe te wijzen die al in gebruik is. het kernelbronbestand inet_connection_sock.c verwijst naar deze voorwaarde. probeer als experiment eerst een binding met een lokale poort uit te voeren en zorg ervoor dat elke binding/verbinding een ander lokaal poortnummer gebruikt.
Antwoord 4, autoriteit 18%
Ok, mijn probleem was niet de poort, maar het bindingsadres. Mijn server heeft een intern adres (10.0.0.4) en een extern adres (52.175.223.XX). Toen ik probeerde verbinding te maken met:
$sock = @stream_socket_server('tcp://52.175.223.XX:123', $errNo, $errStr, STREAM_SERVER_BIND|STREAM_SERVER_LISTEN);
Het is mislukt omdat de lokale socket 10.0.0.4 was en niet de externe 52.175.223.XX. U kunt de lokaal beschikbare interfaces afrekenen met sudo ifconfig.
Antwoord 5
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_tw_recycle=1