Discussion :

[ludovic.fernandez]

Bonjour à tous,

J'ai réalisé un petit client/serveur à l'aide de sockets, tout fonctionne cependant je me pose différentes questions pour améliorer mon programme.

1> Doit-on gérer les signaux SIGINT dans le processus client si un Ctrl-C se produit avant l'appel de close() pour que la socket ne subsiste pas ? y'a t'il d'autres signaux à traiter ? SIGKILL ... De même côté serveur ?

Remarque : j'utilise fork() pour gérer la lecture/écriture des clients dans le processus fils, le père gère la connexion.

2> La connexion et/ou l'acceptation est/sont-elle(s) bloquante(s) ? Doit-on utiliser MSG_DONTWAIT ?

Merci par avance, en espèrant être suffisament explicite ...

[Anomaly]

Bonsoir à toi,

1) Non il n'y a pas besoin. Les sockets seront libérées. Par contre les connexions actives passeront à l'état TIME_WAIT, ce qui peut empêcher le relancement immédat du serveur, qui croit que la socket est toujours ouverte. Cependant, on peut régler la socket serveur pour demander à ne pas passer par cet état, cela rend cependant un peu moins fiable la détection des coupures de connexions au niveau client, selon la documentation.

2) Quand on parle de connexion bloquante, cela veut dire que lorsque tu lis une donnée alors que y'en a pas, il se met en attente. Utiliser MSG_WAIT ne change pas ce comportement, mais en revanche évite d'attendre dans des situations où les ressources sont pleines, par exemple, lorsqu'on écrit beaucoup sur une socket que le lecteur ne lit pas ou peu, lorsqu'elle est pleine, send() normalement se met en attente, ou renvoie une erreur si MSG_WAIT est précisé.

Pour passer en socket non bloquante ou virer l'état TIME_WAIT, il faut utiliser setsockopt (je me rappelle plus du nom de l'option à activer désolé )

[ludovic.fernandez]

ok, merci Anomaly donc j'ai un bon petit programme ! reste à faire setsockop avec l'option SO_KEEPALIVE ?!?

on peut régler la socket serveur pour demander à ne pas passer par cet état

Oui, je me souviens maintenant ! C'est SO_REUSEADDR, mais il vaut mieux appeller le portmapper.

[Anomaly]

reste à faire setsockop avec l'option SO_KEEPALIVE ?!?

C'est pour que la socket fasse des tests supplémentaires (pings) afin de s'assurer qu'une connexion est toujours vivante. C'est ça que tu veux ?

Oui, je me souviens maintenant ! C'est SO_REUSEADDR, mais il vaut mieux appeller le portmapper.

Oui c'est cette option en effet, mais euh c'est quoi cet histoire d'appeler le portmapper ?

[ludovic.fernandez]

[C'est pour que la socket fasse des tests supplémentaires (pings) afin de s'assurer qu'une connexion est toujours vivante. C'est ça que tu veux ?

Non, pas vraiment; j'avais compris que cette option servait à faire passer des messages vides, donc d'éviter le problème de bloquage.

mais euh c'est quoi cet histoire d'appeler le portmapper ?

He bien, il me semble que le fait de rendre réutilisable immédiatement le port est source de vulnérabilité puisque n'importe qui peut faire un bind dessus alors que l'appel direct vers le portmapper peut résoudre le problème.

Par contre je ne code pas beaucoup en C/C++, mon niveau est assez faible (je n'utilise que des librairies C en l'occurence), par conséquent, j'ai peut-être rien compris !

[Yabo]

Pour une socket non blocante tu peux utiliser ca aussi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
fd_set socks; 
FD_ZERO(&socks); 
FD_SET(sRecvSock, &socks); //sRecvSock : le socket dont tu attends les infos 
timeval tv = {5, 0}; //5 secondes 
select(0, &socks, NULL, NULL, &tv); //blocking call, 5 secondes 
if  ( FD_ISSET(sRecvSock, &socks) ) 
{ 
//le client a répondu sous 5 secondes 
} 
else 
{ 
//le client n'a pas répondu sous 5 secs 
}