Socket multithread & select

Version imprimable

20/11/2006, 17h02
crealinks

Socket multithread & select

Bonjour

Je dois développer une appli en C client-serveur.

Je souhaite utiliser les selects, mais le principe de fonctionnement ne met pas encore très clair.

D'apres les docs et ce que j'en ai compris, l'idée du select est de vérifier si le descripteur du fichier/socket est pret pour la lecture/ecriture.

Dans mon cas, j'ecoute sur deux ports différents et donc j'ai ouvert deux socket, que j'ai "ajouté" au fd_set via la macro FD_SET. Je me met en attente sur le select. Un foi le select passé avec succé, j'utilise FD_ISSET sur le fs_set en lecture. Tout va bien.

Maintenant que j'ai une connexion cliente ? j'en fais quoi ? j'imagine qu'il faut que je " l'ajoute " à ce select pour, lui aussi, vérifier la lecture/ecriture ?

Dans tout les cas, même si ce serveur peu gérer plusieurs clients, il ne peut le faire que séquentiellement ?

Dois je en déduire que la solution est de passer par des threads ?

Est il possible, une foi le client connecté, le thread crée avec en paramètre le socket, de re-créer un select sur ce socket seulement ? et on aurai bien du parallélisme ?

J'avoue que je suis un peu perdu. Les exemples dispo sur le net qui mette en avant les select sont ultra légé.

Si vous pouviez juste m'éclairer un peu :oops:
20/11/2006, 21h06
granquet

Citation:

Envoyé par crealinks

Dans tout les cas, même si ce serveur peu gérer plusieurs clients, il ne peut le faire que séquentiellement ?

a moins d'etre sur une arch multi processeurs ... je vois pas bien la difference entre select et du "1 thread par client".

tu peux utiliser select dans ta boucle principale et spawn des threads qui s'occupent de tes nouveaux clients.

site que j'aime bien: http://beej.us/guide/bgnet/output/ht...ed.html#select
21/11/2006, 07h32
crealinks

Je pense que j'ai compris le fonctionnement du socket. et je persiste dans mon idée : le select ne permet pas de faire le meme parallélisme que les threads. Donc ouai, je vais faire deux thread pour les serveurs, puis 1 thread par client. ok. Maintenant ma question est la suivante :
admettons que le réseau est lent, et que le client ne m'envoie pas tout ce qu'il à me dire d'un cout... il faudra que je fasse plusieurs read ? donc typiquement, je suis succeptible de commencer à recevoir un message (structure à travers le socket) mais attendre la fin indéfiniement (ou pas), ou jusqu'a ce que read me retourne -1 ?
22/11/2006, 21h36
granquet

Citation:

Envoyé par crealinks

je persiste dans mon idée : le select ne permet pas de faire le meme parallélisme que les threads.

je me trompe peut etre. mais a mon sens ... multiplexage ou threads sur un systeme avec un seul processeur, ça reviens EXACTEMENT a la meme chose.
juste que c'est plus compliqué avec des threads :aie:

Citation:

donc typiquement, je suis succeptible de commencer à recevoir un message (structure à travers le socket) mais attendre la fin indéfiniement (ou pas), ou jusqu'a ce que read me retourne -1 ?

ben ... non (en bloc).
tu fait ton recv (pas besoin d'utiliser read ici, recv vas tres bien), il vas te retourner une certaine taille.
si y t'en manque (faut definir comment tu gere ça avec un petit protocole), tu continue a recv pour completer ...
recv bloque quand il n'y'as rien a lire (c'est pour ça qu'on utilise des threads ou du multiplexage), elle (la fonction) ne retourne pas -1.

essaye de faire des questions plus courtes et plus precises :aie: