Discussion :

[Khan34]

Bonjour,

J'ai un serveur et plusieurs clients qui communiquent par sockets. La méthode d'implémentation est la méthode 1 thread + select.
Mon problème est le suivant:
- Il y a des cas où le serveur doit émettre un message à un client et celui-ci doit lui répondre avec un ACK. Cependant, la réponse peut ne pas se faire immédiatement, selon le traitement qui est en cours côté client. Mais le serveur ne peut pas se permettre d'attendre la réponse du client, car étant donné qu'il s'agit d'une implémentation 1 Thread + select, cela bloquerait toutes les communications avec les autres clients. Je cherche donc le meilleur moyen d'attendre une réponse de façon asynchrone côté serveur, et de gérer un timeout en cas de non-réponse. Et ce, pour tous les clients connectés, ce qui implique (ou pas) un timer pour chaque message émis aux clients.

En bricolant un peu, je pense qu'il y a plusieurs méthodes, mais ayant peu d'expériences, je me demandais si qqn d'entre vous aurait déjà géré un tel cas.

Julien.

[Neckara]

Bonjour,

Si c'est des ACK du protocole TCP tu n'as pas à t'en chargé, c'est une couche réseau inférieur qui s'en occupe.

Pour des timeout je vois 2 solutions :
- utiliser boost qui a une utilisation bien plus pratique pour les socket et les timeout (Qt le fait aussi).
- mettre un timeout au select (si il est atteint, supprimer tous les socket) sinon on regarde le temps avec un autre temps enregistré de sorte que tous les 2 secondes (valeur arbitraire) on regarde si tous les sockets ont déjà envoyé un message (en gros un tableau de booléen qui tu met à false toutes les deux secondes et que tu met à true dès qu'un message arrive).

[Khan34]

En ce qui concerne le ACK, je parle bien d'un ACK émis par le client pour informer le serveur que le traitement correspondant à la commande s'est bien déroulé.

Après, étant en environnement temps réel / systèmes embarqués, avec une limitation de mémoire, je ne peux pas utiliser boost.

Je vais partir sur ta dernière solution.

Julien.

[jouana]

Je ne vois pas le problème.

Select a pour but de te dire si une action c'est faite sur un fd, soit tu vas lire sur le socket que si select te dit qu'il y a qlq chose à lire.

Si read renvoie -1 alors tu as une déco.

Le select est la normalement pour faire de l'écoute non bloquante sur plusieurs fd (socket), c'est justement pour évite de faire un thread par connexion.

[Khan34]

Certes, le select à un timeout pour être non bloquant. Mais ce timeout est unique. Par exemple:

J'ai le serveur S et deux clients C1 et C2.
- C1 se connecte à S.
- S lui envoi un message, et doit recevoir un ACK de C1 dans un temps max défini (-> démarrage timer ?).
- C2 se connecte à S.
- S lui envoi un message, et doit recevoir un ACK de C2 dans un temps max défini (-> démarrage timer ?).

Plusieurs cas:
- C1 ne répond pas d'ACK.
- C1 répond avant C2.
- C2 répond avant C1.
- C2 ne répond pas d'ACK.

J'imagine bien une thread supplémentaire qui gère les timers (ou le timer) et qui déclenche le select en cas de timer expiré. Mais voila, je me demandais si qqn avait déjà utilisé certaines méthodes pour gérer cela.

Est-ce plus clair ?

Julien.

[jouana]

Je suis pas vraiment sur de comprendre donc ont va reprendre point par point une exécution select.

En gros tu as un struct avec ton socket et un timer que tu lis sur le socket timer = 0;

Tu as ensuite trois timer un pour avant select, un pour après la soustraction des 2 te donne le tps passé.
Le 3eme c'est le timeout de ton select = le tps le plus court que tu attend.

Ensuite le timer attaché a ton socket += la soustraction des 2 autres.

et le troisieme et égale a temps max - le timer attaché à ton socket le plus haut.

si timer attaché au socket >= tps max alors timeout

Et quand tu lis un socket alors tu remet le timer à zéro

je te rappel que tu lis un socket que si il est isset de mémoire.

Voila en esperant être clair