[Résolu][SFML2.0]Timeout des sockets sur un TcpSelector

[Neckara]

Bonjour,

J'ai un TcpSelector qui gère plusieurs sockets et j'aimerais que lorsqu'un client ne répond plus, le déconnecter.
J'ai regardé la doc mais je n'ai rien trouvé à ce propos.
Le problème c'est que je ne peux pas faire un thread par client pour utiliser un TcpSelector par socket, niveau performance, c'est intenable.

Parcourir régulièrement une liste de socket pour voir ceux qui sont inactif ne me semble pas très optimisé...

Sinon une autre question que je me pose :
Est-ce que parcourir un tableau de socket après un selector.wait() est vraiment plus optimisé que de faire en sorte que le selector.wait construise une liste de socket ayant reçus des données comme dans la 1.6 ?

EDIT : selon la doc,
Le status indique si le socket est déconnecté, est-ce que la déconnexion prend en compte les timeout ? (il ne me semble pas que le protocole TCP le face, enfin d'après ce que j'ai vu en cours)
S'il prend en compte les timeouts, est-il possible de faire varier la durée au bout de laquelle on considère la connexion perdue?

[Laurent]

J'ai un TcpSelector qui gère plusieurs sockets et j'aimerais que lorsqu'un client ne répond plus, le déconnecter.
J'ai regardé la doc mais je n'ai rien trouvé à ce propos.

Qu'est-ce qui coince ?
"ne répond plus" c'est send ou receive qui renvoie sf::Socket::Disconnected, et "déconnecter" c'est disconnect().

Est-ce que parcourir un tableau de socket après un selector.wait() est vraiment plus optimisé que de faire en sorte que le selector.wait construise une liste de socket ayant reçus des données comme dans la 1.6 ?

Oui

[Neckara]

Je me suis mal exprimé.

Le serveur va recevoir des données puis les traiter.

Si le client interromps brutalement la connexion (en dehors d'en send ou receive), par exemple en débranchant sa prise.
Est-ce que niveau serveur je vais recevoir une erreur ou disconnect sur le socket du client (avant de faire un autre send ou receive) ?

[Laurent]

Non tu ne recevras rien. Tant que tu n'essayes pas de lire ou d'écrire sur la socket, impossible de connaître l'état de la connexion.

[Neckara]

Il faudrait donc que toutes les X secondes j'envoie un socket à chaque client pour vérifier s'il est encore en ligne? ça peut être très lourd.

L'autre solution serait de demander au client d'envoyer régulièrement une requête UDP.
Il faudrait donc qu'à chaque début de connexion j'envois au client un pointeur et que le client me renvois ce pointeur pour trouver plus facilement le socket TCP associé. Mais là il faudra parcourir régulièrement le tableau de socket pour voir les timeouts.

[Laurent]

Il y a des techniques pour gérer en live les deconnexions, je ne peux que te conseiller de lire un peu sur le sujet avant de t'aventurer dans des algorithmes persos, ou de tirer des conclusions trop hâtives