Discussion :

[tlibert]

Bonjour à tous,

Je suis à la recherche de conseils et d'aide pour le développement d'une petite application en c#.
Voici une rapide description :
L'appli se compose en fait de deux éléments : un serveur (winform ou service) et un client (service).
Le principe est le suivant (très simple) : Le client se lance et se met en mode écoute sur un port déterminé via un(e) socket.
Le serveur se connecte au client, un dialogue basique commence du style :
Serveur : bonjour
Client : bonjour, bye

Vraiment très basique...
Ensuite le serveur ferme la communication avec le client lors de la réception du "bonjour, bye" et le client se remet en mode écoute.

Pour l'instant, j'arrive bien à faire communiquer les deux, mais j'ai toujours un plantage lorsque je ferme le client ou le serveur.

Question : c'est le serveur ou le client qui doit fermer la communication ?
Quelqu'un a-t'il un tuyau ?

Information importante : je travaille en mode "asynchrone" pour les sockets.

Dernière chose : j'aimerais que mon serveur soit multi-thread pour pouvoir communiquer avec plusieurs clients simultanément. Petite précision : les clients ne communiquent pas entre eux, c'est toujours un dialogue serveur vers client.

Merci beaucoup de votre aide et de vos conseils !

Si nécessaire, je peux publier le code.

[theMonz31]

Bonjour

1ère erreur selon moi... Ce n'est pas au serveur de ce connecté au client mais au client de se connecter au serveur. Ca, c'est plutot "immuable" dans ce genre d'architecture.

LE serveur écoute sur un port, et ce sont les clients qui viennent si connecter.
Ensuite, pour l'aspect multithread, tu peux trouver pleins d'exemples sur le net.

Ensuite, en dehors des sockets, tu pourrais aussi regarder du coté du Remoting ou de Corba (IIOP.Net) qui permette également de faire des choses interessantes.

Et à defaut des sockets, tu peux aussi te pencher sur les classes TCPListener, TCPClient

The Monz, Toulouse

[tlibert]

Bonjour theMonz31,

Merci pour ta réponse. Je vais peut-être reformuler un descriptif de mon appli.

Partie A:
Un service (appelons-le BROL) est installé sur des ordinateurs.
Une fois que le pc démarre, BROL démarre aussi et se met en attente de connection.

Partie B :
Une appli winform ou un service (appelons-le BIG_BROTHER) est installé sur un ordinateur central (ou serveur).
Une fois l'appli lancée, BIG_BROTHER va se connecter à un BROL et commencer une simple discussion.
BROL répond "ok, bye", BIG_BROTHER ferme la connection avec BROL.
BROL se remet en mode écoute.
BIG_BROTHER se connecte à un autre BROL et ainsi de suite.

Dans un schéma classique, un serveur se met en attente de connection de clients. Plusieurs clients se connectent alors à un et un seul serveur et le dialogue client-serveur à lieu.

Mon appli est plutôt : BROL (le serveur) se met en attente et n'accepte qu'une seule connection d'un BIG_BROTHER (le client) et ce même client peut se connecter à plusieurs serveurs en même temps.

Est-ce plus clair ?
Comment vois-tu la chose ?

Merci

[theMonz31]

rien n'empeche un client d'etre aussi serveur

Cela dit, je ferais un TCPListener dans BROL... avec un compteur de nombre
de connexion, et dès que j'en ai une de validé, je refuse toutes les autres demandes de connexion...

Après, les deux peuvent parler ensemble

ET du coté BIG_BROTHER, j'implémenterais "plusieurs" Thread contenant un TCPClient...

Après, faut gérer une liste de BROL pour que BB soit capable de créer tous les thread qui conviennent

Voila comment je verrais la chose

Bref, en moins d'une journée, ca doit être plié

The Monz, Toulouse

[pot2yaourt]

Juste à titre d'information, j'aurais aimé savoir pourquoi tu conseilles d'utiliser les classes TCPxxx ou Remoting plutôt que les Sockets ? Quels sont leurs avantages ?

[theMonz31]

je trouve la communication avec TCPClient et TCPListener plus simple à réaliser qu'avec les sockets... qui sont un peu plus souple puisqu'on peut faire de l'UDP ou du TCP

Cela dit, ce sont des classes qui surcouchent les sockets , donc, ya rien non plus d'exceptionnel dedans

sinon, un article par rapport à ce qu'il veut faire le gars

TCP threaded server

ou celui la :

Chat Server in C#

The Monz, Toulouse