Discussion :

[LastSpear]

Bonjour à tous,

Actuelement, un camarade et moi meme dévelopont pour un projet tutorer, une API de calcul distribuer en C. Cette dernière utilise donc les sockets C ainsi que la fonction select(). Or nous aimerions migrer select() vers poll() (pour eviter la limite de FD_SETSIZE). Seulement nous venons de remarquer que nous avons aucun tests dans de notre code existant dans le cas d'exception socket detecter par select(). Or nous voudrions affectuer la migration après avoir testé cette fine mais importante partie du code.

Voici le prototype de select() sur lequel je base ma question:

Code :

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

int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

Ainsi nous utilisons la totalité des parametres de select(), dont <exceptfds> pour pouvoir tracker les sockets qui auraient eu des problèmes. Mais notre projet étant encore dans sa genèse (5 semaines developement en parrallel des cours et autre projets, 10000 lignes de code), nous n'avons pas encore assister à une exception socket. Donc nous voudrions les provoquer dans nos tests pour etre sur d'atteindre 100% des assertions présentes dans le code.

Pour tester nottre code des differents protocols déjà implementé, nous avons pour abitude d'établir dans un même processus une connection TCP vers lui meme, avec souvent un multi-threading.

• Creations d'un socket d'ecoute server sur le port 0 pour eviter les batailles de ports lors du parralellisme des tests (`make tests -j8`)
• Recuperations du port d'ecoute affecté par l'OS
• Ouverture de connection TCP sur notre socket server (connect(), accept() & cie ...)
• Fermeture du socket d'ecoute server
• Test de notre protocol souvent en multi-thread (plus facile à debuguer)

Donc l'idée serait qu'une foit la connection TCP établie, faire une manipulation m'étant encore inconnue sur un socket TCP pour que le socket TCP `d'en face` ressoit une exception, detecté par le select() afin de pouvoir tester le code associé a cette evenement.

La question est: Connaissez vous cette misterieuse manipulation qui puisse etre multi-platforme (OSX et Linux au moins) et permetant de generer l'exception sur le socket "d'en face" ?

Merci beaucoup de votre lecture (malgrer mon orthographe je le sais) ainsi que de vos futur réponses éventuelles.

[imperio]

Les seules erreurs que je connais sur une socket sont :
- deconnexion
- erreur de lecture / ecriture

Je n'ai jamais eu a utiliser la structure pour gerer les erreurs avec select. Peut-etre est-ce une mauvaise habitude, pour le moment ca ne m'a jamais pose de probleme. Si jamais un client se deconnecte, select dira que de nouvelles donnees sont arrivees donc un recv dessus te renverra une erreur te disant qu'en gros la socket n'est plus connectee. Une bonne utilisation de select t'empechera d'avoir des problemes d'ecriture parce que cette fonction te permet de voir si tu peux ecrire ou non sur cette socket (te permettant notamment d'eviter de bloquer inutilement ton programme).

Donc a part ca, je ne pense pas que l'utilisation de cette structure d'erreur soit pertinente mais je peux me tromper... En tout cas je n'en ai jamais eu l'utilite jusqu'a present.

[LastSpear]

J'ai peut etre du mal comprendre car je ne trouve pas l'erreur correspondante pour "la socket n'est plus connectee" dans la documentation de recv() . Si le socket de l'autre coter fait un close(), recv() renvoit bien 0. Mais je ne trouve pas dans le cas ou un cable aurait été aracher. La seul piste est lors de l'envoi avec send() renvoyant EPIPE, mais si le buffer d'envoi est deja plein, select() ne metrera jamais le file descriptor dans son parametre <writefds>.

[imperio]

Justement, si la socket est deconnectee, au lieu de se mettre en attente, recv va renvoyer 0 tout de suite. C'est d'ailleurs comme ca qu'on sait si le client est deconnecte ou pas. Si tu appelles send sur une socket deconnectee, sur unix tu obtiendras le signal SIGPIPE et sur windows je crois que ton programme plante mais je ne suis pas sur. Du coup, cette erreur n'est pas possible en utilisant select.

[LastSpear]

Mmmmh d'acore d'acore. Merci beaucoup !

[skeud]

Je sais que le thread est résolu, mais une question m'est venu, lorsque l'on débranche le cable, c'est équivalent à un close de l'autre coté?

[imperio]

J'ai envie de dire essaie et tu verras mais pour t'eviter cette perte de temps : oui, la socket est consideree comme deconnectee de l'autre cote (pas sur le pc qui n'a plus internet par contre je crois).

[Obsidian]

Je sais que le thread est résolu, mais une question m'est venu, lorsque l'on débranche le cable, c'est équivalent à un close de l'autre coté?

Pas forcément (ce qui peut être un bien comme un mal). Le principe du TCP en particulier est « d'émuler » une liaison privée point-à-point full-duplex telles qu'on pourrait l'obtenir avec un port série et/ou une communication téléphonique, mais en s'appuyant sur un protocole sous-jacent, en principe IP, qui lui est un protocole à paquets, détachés les uns des autres. Le fait de débrancher le câble ne va donc pas du tout mettre fin à la connexion automatiquement, si aucune donnée n'est transmise pendant l'intervalle (ce qui peut te permettre de le rebrancher).

Si l'équipement de transmission est équipé d'un détecteur de rupture et que ton système est configuré pour, c'est effectivement le système qui va prendre cela en charge et émettre un SIGPIPE sous UNIX comme dit plus haut. Mais là, c'est un événement extérieur au TCP et à la gestion du socket. Il faut se souvenir également que tu peux ouvrir une connexion TCP via Internet jusqu'à l'autre bout du monde et que tu ne pourras donc pas avoir de regard sur l'état de l'infrastructure du chemin entier. Par ailleurs, Internet est conçu pour être résilient, donc certains nœuds peuvent très bien mettre tes paquets temporairement en attente le temps de configurer une nouvelle route si jamais l'une d'entre elles venait à tomber par terre.

Par contre, en tout état de cause, une route coupée sans la possibilité d'en choisir une autre devrait en toute rigueur correspondre à un « host unreachable ». De là, il est possible que tu reçoives un message ICMP lors de l'émission de l'un de tes paquets et que cette erreur, elle, soit prise en charge par le système en fermant la connexion associée.