Scruter un tableau de sockets de service

Citation:

---

Envoyé par Emmanuel Delahaye

Comment tu gères les sockets et les saisies utilisateur sous Windows avec select() ?

---

Alors, je ne dit pas que je ne fait pas du multi-threading. Et là, c'est effectivement le cas le plus typique: un thread IHM et un thread pour les échanges. Mais dans ce second thread, toutes les sockets avec un select.

Citation:

---

Envoyé par Médinoc

Un client qui demande un mot de passe n'a généralement pas besoin de recevoir des données du serveur en même temps, donc pas de select() à ce moment-là.
Typiquement, on doit pouvoir faire un client FTP sous Windows uniquement avec select().
Edit: Bien sûr, pour un client de t'chat, là ça coince.

C'est plus compliqué pour un serveur, si l'on veut pouvoir lui taper des ordres (comme "quitter", par exemple).

---

;)

ça ramène à ce que je dis (de temps en temps ;)) depuis un bon bout de temps : toute la m.r.e vient des sockets asycnhrones sous Windows et du fait qu'ils ne sont pas vraiment une couche indépendante juste au-dessus de la couche de transport, mais une couche nécessitant la messagerie Windows (donc un Window Handle)..

Citation:

---

Envoyé par souviron34

toute la m.r.e vient des sockets asycnhrones sous Windows et du fait qu'ils ne sont pas vraiment une couche indépendante juste au-dessus de la couche de transport, mais une couche nécessitant la messagerie Windows (donc un Window Handle)..

---

1. Déjà, ils ne sont pas asynchrones quand tu t'en sers avec select(). Donc la m***e ne vient pas de là, elle vient du fait que les sockets ne soient compatibles qu'avec eux-mêmes sous Windows (et donc, du fait que select() ne marche que sur les sockets).
2. Et comme c'est de la vraie programmation événementielle et non pas de la programmation interruptible, bosser en sockets asynchrones sous Windows est beaucoup moins prise de tête que sous *n*x.
   
   • Le fait que ça nécessite d'être attaché à une fenêtre plutôt que d'être consultable directement depuis la boucle de message du thread a ses avantages et ses inconvénients. Typiquement, ça a l'avantage de marcher même dans une sous-boucle de messages (boîte de dialogue modale, redimensionnement de fenêtre, menu...).

Citation:

---

Envoyé par souviron34

;)

ça ramène à ce que je dis (de temps en temps ;)) depuis un bon bout de temps : toute la m.r.e vient des sockets asycnhrones sous Windows <...>

---

Les sockets Windows (winsock2) sont comme les sockets BSD/POSIX : synchrones par défaut (accept(), connect(), send(), recv(), sendto() et recvfrom() sont bloquants). Personnellement, sous Windows, j'essaye de rester le plus POSIX possible. Je n'utilise pas le mécanisme asynchrone et c'est pour ça que je préfère utiliser les threads (chacun son boulot, synchronisation auto-démerdante, rien à coder...).

Maintenant, si je devais faire des applications GUI, j'utiliserais peut être des mécanismes plus évènementiels comme select(), WaitForSingleObjetc() ou WaitForMultipleObject()... Pour le moment, j'évite...

http://emmanuel-delahaye.developpez.com/reseaux.htm

Ce qui m'agace avec Windows, c'est que stdin ne soit pas pris en compte par select()... C'est tout. je n'ai rien à dire sur Winsock2. Pour moi, il n'y a pas de différence flagrante avec les sockets POSIX (à part l'init WSA...() ... simple détail)