Discussion :

[dodo285]

Bonjour,

Je suis actuellement entrain d'écrire un programme permettant de répartir des calculs sur des machines a l'intérieur d'un réseau local (en l'occurrence un cluster de calcul).

Les machines sont sous Debian Testing avec un kernel Linux 3.2.0-3-amd64.

Le programme en question ressemble donc un peu a un serveur web, c'est un modèle client/serveur.
1) Le serveur sélectionne les données a calculer puis se met en attente d'une connexion TCP.
2) Le client initie la connexion TCP avec connect() puis récupère les données a calculer.
3) Le client calcule.
4) Le client initie une seconde connexion TCP pour transférer les résultats et retourne a l'étape 2.

Évidement, tout cela est géré par un petit protocole home-made.(je n'entrerais pas dans les détails)

Comme vous pouvez le voir cette manière de procéder permet aux multiples clients de faire des calculs en parallèle si le temps de calcul est bien plus long que le transfert des données (ce qui est très souvent le cas).


En fait cela marche plutôt bien sauf que pour certains calculs, il arrive que le temps de traitement d'un paquet de données soit si court que le serveur traite plusieurs milliers de connexions TCP a la seconde.

Et là, ça se gate vraiment, le serveur tiens le coup il n'y a pas de probleme, par contre les clients eux terminent sur un retour -1 de l'appel système connect() avec l'erreur EADDRNOTAVAIL.

Et franchement je ne sait pas comment éviter ça!

J'ai essayé de vérifier errno au retour de connect() et si il est égal a EADDRNOTAVAIL d'attendre 1 seconde mais très rapidement, ça repart dans le decort!

Si dessous le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
while (connect(*sock, (struct sockaddr *) addr, sizeof (struct sockaddr_in)) < 0)
	{
		if (errno == EADDRNOTAVAIL)
		{
			perror("connect in request_connexion");
			fprintf(stderr,"sleeping 1 seconde before retrying connect...\n");
			sleep(1);
		}
		else
		{
			perror("connect in request_connexion");
			return(EXIT_FAILURE);
		}
	}

Le problème semble venir du fait que tout les ports disponibles sont pris a un instant donné.

Bref, j'aimerais savoir comment être sur que connect() puisse attribuer une identité a sock ou bien attendre a la fin de la connexion la libération du port par le noyau.


Merci.

[mith06]

Salut,

Je ne suis pas un pro des réseaux.

Le problème semble venir du fait que tout les ports disponibles sont pris a un instant donné.

Qu'est ce qui t'as orienté vers cette conclusion?

Pourquoi utilises-tu 2 connexions différentes pour la réception des consignes de calcul, et le renvoi des résultats?

[dodo285]

Et bien ce qui me fait penser que tout les ports sont pris a un instant donné c'est la variable errno retournée par connect(), EADDRNOTAVAIL:
Lorsque l'on fait un connect(), le noyau attribue un port pour la connection (c'est absolument obligatoire) et vu que c'est une demande de connection, tu peut prendre un port aléatoire(ce qui est le cas par défaut si tu ne fait pas de bind() avant connect().
C'est donc précisément ce que le noyau fait (en fait il fait un bind avec l'option INADDR_ANY).

EADDRNOTAVAIL signifie : Une interface inexistante a été demandée ou bien l'adresse demandée n'était pas locale.

Vu que dans mon cas plusieurs milliers de connections sont faites par secondes, il est tout a fait possible que tout les ports soient occupés a un moment donné car le client transmet des données, puis ferme la socket ce qui ne veut pas dire que le serveur les a reçu!, donc dans ce cas le port reste occupé jusqu'à ce que le serveur ait tout récupérer...

Et donc si mon intuition est bonne, a un moment donné, on peut avoir autant de canaux TCP ouverts que de ports disponibles, il est donc impossible d'établir une nouvelle connection TCP car il n'y a plus de port libre..

Concernant l'utilité de faire deux connections:
-Une avant le calcul
-Une après le calcul.

Cela évite de maintenir des milliers de connections TCP (car potentiellement des clients il peut y en avoir des milliers) et donc avec ce modele, le nombre de clients est potentiellement illimité .
De plus, le serveur fonctionne de manière synchrone (ce qui est bien plus simple) ce qui ne serais pas possible si je maintenais les connections.
Pour finir, maintenir une connection pendant que l'on fait un calcul ne sert a rien.

J'espère avoir été clair.

[Bktero]

J'ai eu un problème similaire avec du code Python, en faisant très rapidement des connexions / déconnexions à un serveur. Cela venait du fait que le port n'est pas libéré tout de suite à la déconnexion. J'ai mis une option particulière au socket pour régler ce problème.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ss = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ss.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

Je lis dans les man pages que C possède une option similaire (de toute façon, les sockets Python sont d'après ce que j'ai lu une surcouche "bête" des sockets C) : http://man.developpez.com/man7/socket.7.php#L5

La question de mith06 est aussi pertinente : pourquoi faire deux connexions ? Pourquoi ne pas laisser la connexion ouverte ? N'aurais-tu pas un moyen de déterminer si le calcul va être long à la réception des données par le client pour savoir si cela vaut la peine de fermer la connexion ?

EDIT : je vois que tu as répondu entre temps. Si tu veux effectivement ne pas maintenir ouverte des centaines de connections, l'idée de déterminer approximativement le temps de calcul n'est pas forcément bête. Tu éviteras l'overhead lié à la déconnexion / reconnexion qui pourrait être non négligeable par rapport au temps de calcul lui-même.

[dodo285]

Malheureusement on ne peut parfois pas savoir quelle vas être la durée du calcul. (et puis qui peut le plus peut le moins alors autant ne pas maintenir cette connection..).

Donc laisser la connection ouverte est hasardeux.
Pour finir en utilisation optimale, les clients passent le plus clair de leur temps a faire du calcul donc potentiellement il y a autant de connections que de clients.

Pour donner un ordre d'idée, j'utilise actuellement ce programme pour un calcul et les clients ont cumulés environ 400000 heures de calculs (sur des centaines de processeurs évidemment) alors que la transmission des données n'a pris que 1heure 30.

[dodo285]

Merci pour vos réponses.

Bktero, j'utilise déjà l'option dont tu parle, et cela n'y change rien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
if ((*sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
	perror("socket in request_connexion");
	return(EXIT_FAILURE);
}
if((setsockopt(*sock, SOL_SOCKET, SO_REUSEADDR, &reuse_addr, sizeof(int))) < 0)
{
	perror("setsockopt");
	return(EXIT_FAILURE);
}
while (connect(*sock, (struct sockaddr *) addr, sizeof (struct sockaddr_in)) < 0)
{
	if (errno == EADDRNOTAVAIL)
	{
		perror("connect in request_connexion");
		fprintf(stderr,"sleeping 1 seconde before retrying connect...\n");
		sleep(1);
	}
	else
	{
		perror("connect in request_connexion");
		return(EXIT_FAILURE);
	}
}

J'insiste cependant sur la fait que ce n'est pas le serveur qui pose probleme, mais bien les clients.
J'ajoute également une précision: les tests a haute fréquence ont été fait sur une seule machine en utilisant la boucle locale.

[mith06]

OK,

En regardant d'un peux plus prés le protocole TCP, il y a dans les trames un port destination et un port source. Le port source est choisi par le noyau, et est codé sur 16 bits => 65536 connexions possibles sur le même port destination (port du serveur).
Il y est possible que le noyau réduise encore se nombre.

Cette limitation est inhérente à la conception du protocole TCP, tu n'y peux rien à part attendre qu'un port se libère...

Tes clients tournent-il sur la même machine? (quand je dis machine je pense système exploitation (quand je dis système d'exploitation je ne veux pas dire version mais bien physiquement le même système ))

ATTENTION: Je dis ça comme ça vien... je suis sure que les serveurs Google acceptent plus 65536 connexions.

[dodo285]

Merci a toi mith06.

C'est précisément ce que je cherche a faire: attendre la libération d'un port, mais surtout ne pas exploser tout les ports disponibles sur la machine.. (car ça peut mettre un bordel pas croyable).

Ce qu'il faut savoir aussi c'est que dans mon boulot, plusieurs dizaines de personnes peuvent utiliser la même machine.
Donc il faut absolument éviter de faire tomber un serveur...

Au final, la solution idéale je pense, ce serais de pouvoir attendre la libération du port précédemment utilisé par le client.
Du coup là il serait impossible de prendre tout les ports de la machine.
Mais je ne sait pas comment implémenter ça.

PS: comme dit précédemment, les tests haute fréquence ont été fait sur une seule machine Linux Debian Testing en utilisant comme interface la boucle locale.

[mith06]

Quand l'appel a connect echoue, au lieu de re-faire un connect , ferme le socket et recrée en un nouveau pour voir.

Peut-être la création d'un nouveau socket force le système a reprendre un nouveau port.

[dodo285]

Mer ci encore Mith06,

C'est connect() qui attribue un port a la socket.
De plus si il n'y a pas ce problème de port, a chaque connexion je détrui la socket.

Il faut donc chercher dans une autre direction.

[Bktero]

C'est vrai que j'utilise cette option dans le cas du serveur socket....

Je viens de lire cet article, il m'a semblé intéressant : http://www.toptip.ca/2010/02/linux-e...dress-not.html Le nombre de ports disponibles pour l'assignation automatique est limité, ton problème vient peut-être de là. Tu dis faire tes tests sur une seule machine avec la boucle locale ? Donc tous tes clients sont sur le même PC physique ?

[dodo285]

Tout les clients sont sur le même serveur physique pour ce test.

Mais ce n'est pas obligatoire, le truc c'est que j'aimerais bien que cela marche dans tout les cas:
-A haute cadence ou pas.
-Avec plusieurs machines ou pas.

Il est très clair que répartir des calculs lorsqu'ils sont courts ne sert strictement a rien, cependant il est extrêmement courant que les calculs lancés avec ce programme soient quadratiques.

Du coup on peut avoir des temps de calculs énormes (de l'ordre de plusieurs jours) mélangé avec des temps de calculs qui sont extrêmement court (quelques microsecondes).

De ce fait le programme doit être le plus souple possible.. (perdre des calculs courts ce n'est pas grave mais perdre 1000 calculs de 1 semaine ça commence a être embêtant).

[dodo285]

Toujours personne?

Personnellement je n'ai pas trouvé de solution a ce problème.

[Bktero]

As-tu essayé ce qui est expliqué dans mon lien ? Il faudrait déjà savoir d'où vient le problème actuel avant d'envisager une solution globale.

[dodo285]

Ben oui j'ai essayé mais le problème reste et en plus je ne peut pas modifier ces paramètres sur toutes les machines de calcul : il faut être root!
Je peut uniquement le faire sur ma machine dédiée..
D'ailleurs, la plage d'adresses sous Debian est déjà bien grande : 32768 61000.

J'ai aussi fait des tests avec l'option so_linger mais rien n'y fait.. (apparemment il y a un temps de latence entre la libération des ports et la fin de la connexion tcp).

Bref, ça me fait des noeuds au cerveau.

Le truc c'est que si ça se trouve il est impossible de vérifier si un port est pris. (hors mis le fait d'essayer de le reprendre explicitement avec bind() mais du coup il est alors ré-attribué..).

[gangsoleil]

Bonjour,

Pour moi, tu n'utilises pas assez d'options des sockets.

SOREUSEADDR est bien, mais pas suffisant : il en faut d'autres. Tu peux t'interesser a SO_LINGER si je me souviens bien, ainsi qu'a reduire le temps que les sockets passeront en timewait.
Selon le type de cluster que tu utilises, et le mode de connexion qu'il a, tu peux aussi regarder les options de bypass de certaines couches reseau.

Enfin, tu dis que ca ne sert a rien de garder une connexion ouverte, car pendant que tu calcules, tu ne fais rien de la connexion. C'est vrai, mais tu "oublies" le temps que tu mets a etablir la connexion, qui n'est pas negligeable si tu passes ton temps a en ouvrir.
Je pense que la piste des connexions qui restent ouvertes (une par client ? a voir) n'est pas si mauvaise que tu sembles le croire.

Enfin bien sur, il te reste toujours la possibilite de ne pas passer sur de l'IP, en utilisant de l'infiniband par exemple (assez souvent present dans les clusters).

[gangsoleil]

Le truc c'est que si ça se trouve il est impossible de vérifier si un port est pris. (hors mis le fait d'essayer de le reprendre explicitement avec bind() mais du coup il est alors ré-attribué..).

A distance : Tu envoies directement le second paquet d'initialisation de la connexion, en TCP. Si le port est pris, le systeme te renverra un paquet disant qu'il n'a pas recu le premier paquet [pour que tu le re-emettes]. Tu sais alors si le port est utilise ou non.

En local... j'avoue ne m'etre jamais pose la question, car le plus souvent, je cherche a utiliser le port, donc le fait d'essayer avec bind n'est pas un soucis.

[dodo285]

Merci gangsoleil,

Après avoir bien regardé, j'ai l'impression que le probleme que je rencontre est inhérent au protocole TCP.

En effet, le time_wait est obligatoire et couramment fixé a 60 secondes...

Ce qui fait que a priori, il est impossible que les clients puissent faire plus de 471 connexions par seconde sur une machine..... (nombre de ports dynamique divisé par 60).

Donc si je veut faire une appli qui bombarde au niveau des échanges, il faut implémenter un serveur asynchrone avec un suivi d'événements sur un descripteur epoll...

[gangsoleil]

Merci gangsoleil,

Après avoir bien regardé, j'ai l'impression que le probleme que je rencontre est inhérent au protocole TCP.

En effet, le time_wait est obligatoire et couramment fixé a 60 secondes...

Oui, le passage par cet etat est obligatoire, mais tu peux aussi le fixer a une valeur beaucoup plus faible.

Windows : http://msdn.microsoft.com/en-us/library/aa560610.aspx (chercher TcpTimedWaitDelay)
Linux : http://serverfault.com/questions/233...at/23529#23529 (enfin, certains linux, pour les autres, il faut chercher l'equivalent de ce fichier)

[dodo285]

Il est tout a fait vrais que l'on peut changer le time_wait delay.

Par contre c'est un paramètre du noyau et cela influence tout les processus du système.
De plus il faut être root pour modifier les paramètres noyau.

Bref, je peut pas me permettre d'influencer les autres processus du système car ils ne m'appartiennent pas forcément, d'ailleurs je peut même pas le faire sur pas mal de serveurs car je n'ai pas les droits root.

Du coup pas de solution simple.... il va falloir faire de la programmation asynchrone et maintenir les connections pendant tout le calcul..