Discussion :

[spiale]

Bonjour à tous,

Je fais un code serveur TCP. Il fonctionne bien ;-)
Par contre j'ai du mal à comprendre le fonctionnement de la fonction "listen(s,i)"
Elle est censée renvoyer un message d'erreur suand le nombre de connexion entrant est > i.

Le code en cause :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
        if(listen(sock,2) != 0)
	{
		fprintf(stderr,"%s listen %s", argv[0], strerror(errno));
		return 1;
	}
	while(1)
	{
		struct sockaddr_in client; 
		socklen_t len = sizeof(client);
		int sock_pipe; 
		int ret, nb_question;
		sock_pipe = accept(sock, (struct sockaddr *) &client, &len);

Question 1 :
Pourquoi positionner la fonction avant la boucle comportant accept()? l'erreur n'est plus gérée une fois la fonction exécutée?

Question 2 :
Que veux dire, dans le man : "... le client reçoit une erreur indiquant ECONNREFUSED, ou, si le protocole sous-jacent supporte les retransmissions, la requête peut être ignorée afin qu'un nouvel essai réussisse. " ?
Celà signifie t-il que si le nombre de connexion et >i alors le client essai plusieurs fois jusqu'à être accepté dans la file d'attente?

Merci d'avance pour vos réponses

[Obsidian]

Bonsoir,

Bonjour à tous,

Je fais un code serveur TCP. Il fonctionne bien ;-)
Par contre j'ai du mal à comprendre le fonctionnement de la fonction "listen(s,i)"
Elle est censée renvoyer un message d'erreur suand le nombre de connexion entrant est > i.

C'est le client qui reçoit un message d'erreur si la file est pleine. Ça veut simplement dire que si tu spécifies une longueur maximum à la file d'attente, le système lui-même renverra un message correspondant en gros à « toutes nos lignes sont actuellement occupées » à l'homologue sans que le programme lui-même en ait conscience.

Question 1 :
Pourquoi positionner la fonction avant la boucle comportant accept()? l'erreur n'est plus gérée une fois la fonction exécutée?

Parce que listen() sert simplement à mettre le socket concerné en mode « écoute ». La fonction ressort donc immédiatement, en principe, que ce soit avec un code d'erreur ou de succès.

Question 2 :
Que veux dire, dans le man : "... le client reçoit une erreur indiquant ECONNREFUSED, ou, si le protocole sous-jacent supporte les retransmissions, la requête peut être ignorée afin qu'un nouvel essai réussisse. " ?
Celà signifie t-il que si le nombre de connexion et >i alors le client essai plusieurs fois jusqu'à être accepté dans la file d'attente?

Ça veut dire que « c'est une éventualité » dans le cas où le protocole utilisé permet de faire ces choses-là et que, donc, il est possible que le système choisisse alors de se comporter comme si le paquet avait été perdu. Mais c'est très théorique et je ne vois pas, personnellement, à quel cas de figure particulier cet exemple fait référence.

[spiale]

Bonjour,

Merci beaucoup pour ces précision Obsidian.

Je viens de tester 4 connexions clients simultanées, avec un listen(s,2) dans le code serveur.
Le client n'affiche pas de retour erreur, il se met en attente et envoie les messages quand le serveur est dispo.
Le code serveur est simple sans processus fils.

Une explication?

Merci, encore.

[wiztricks]

Salut,

Je viens de tester 4 connexions clients simultanées, avec un listen(s,2) dans le code serveur.
Le client n'affiche pas de retour erreur, il se met en attente et envoie les messages quand le serveur est dispo.
Le code serveur est simple sans processus fils.

Lorsque le nombre de connexion dépasse la limite, les requêtes clients "attendent" d'être traitées ou partent en timeout (après quelques minutes).
Mais avec de la patience, vous devriez pouvoir tester facilement cela.

- W

[Obsidian]

Je viens de tester 4 connexions clients simultanées, avec un listen(s,2) dans le code serveur.
Le client n'affiche pas de retour erreur, il se met en attente et envoie les messages quand le serveur est dispo.
Le code serveur est simple sans processus fils.

On a vu que c'était un comportement qui pouvait se produire.

Lorsque le nombre de connexion dépasse la limite, les requêtes clients "attendent" d'être traitées ou partent en timeout (après quelques minutes). Mais avec de la patience, vous devriez pouvoir tester facilement cela.- W

Justement : c'est à cela que le paramètre backlog est censé servir.

Une explication?

Ça va dépendre essentiellement à la fois du protocole que tu utilises et du système d'exploitation sous lequel ton programme fonctionne, car l'attitude à adopter va être laissée en partie à la discrétion de ce système et de l'implémentation de son réseau. Dans les notes de la man page Linux, par exemple, on lit :

Le comportement de backlog a été modifié sur les sockets TCP dans Linux 2.2. Il s'agit à présent de la longueur de la file d'attente pour les socket totalement établies en
attente d'acceptation, plutôt que les requêtes de connexion incomplètes. La longueur maximale de la file d'attente des connexions incomplètes peut être configurée avec
/proc/sys/net/ipv4/tcp_max_syn_backlog. Lorsque les syncookies sont activés, il n'y a pas de longueur maximale et la configuration est ignorée. Consultez tcp(7) pour plus de
détails.

Si l'argument backlog est plus grand que la valeur indiquée dans le fichier /proc/sys/net/core/somaxconn, il est tronqué à cette valeur ; la valeur par défaut dans ce
fichier est 128. Dans les noyaux précédant 2.4.25, cette limite était une valeur fixe, SOMAXCONN, qui valait également 128.

[ram-0000]

Pour tester le fonctionnement du backlog, je pense qu'il faut faire un programme spécifique qui fait listen() mais jamais accept() en sortie de listen() ainsi, le backlog va se remplir.

Normalement avec un backlog de 2, tu vas pouvoir initier 2 connexions client (initier seulement puisqu'il n'y a pas de accept). La 3eme devrait se faire jeter immédiatement (les 2 autres vont se faire jeter plus tard avec un timeout (2 ou 3 minutes)