Conception application client/server C#

Bonjour,

Je développe actuellement un logiciel assez simple en conception en C#.Il y a un serveur (un panneau de configuration) et des clients (des tableaux de score).
Le panneau de configuration permet de changer le nom des équipes et les score, les clients recoivent un message et met à jour l’affichage, tout ça sur TCP.

J’ai divisé mon logiciel en 4 parties :
1. Client
2. Server
3. Gui Control Panel
4. Gui ScoreBoard

Au niveau de la partie Client (1 et 4), il me faudra donc un Thread qui écoute la ligne en attendant un changement. Qui lancera ce Thread ? La classe Client (avec un pattern observateur/observé pour notifier le GUI) ou le GUI ( pour éviter que la classe Client doive connaitre les détails sur la vue). Une 3e solution ?

Je pose cette question, car il me semble que c'est un "problème" qui doit se poser assez souvent et je voudrais faire ça de façon bien même si en bricolant je devrais y arriver aussi.


Merci d'avance

question pas claire c'est pour ca que tu n'as pas de réponse

Ok, je vais essayer d'être plus clair.

Typiquement dans une application client/server, Il y aura toujours un
thread par application pour "écouter" la ligne de communication. Ce thread doit connaitre le busness et la partie communication (par communication j'entends la classe client ou server)

Ma question est de savoir à qui appartient la responsabilité de ce thread ?
Qui lance ce thread ?

Car selon moi, il y a deux classes plausibles qui pourraient lancer ce thread.

1. Les classes Client et Server qui ne ne sont pas censer connaitre le modèle.
2. Les classes bussness qui ne sont pas censer connaitre le moyen de communication.

Dans le cas 1 ou dans le cas 2, pour lancer le thread "ecoute" on va être obligé de créer une dépendance non souhaitée.

Ma question est en quelque sorte de savoir ou lancer ce thread ? De façon à ne pas créer une dépendance entre le busness et la communication (client/server).

Si je ne suis toujours pas claire, aiguillez moi sur ce qui ne l'est pas :)

Merci

bah c'est toujours pas clair pour moi

si tu as une classe avec des propriétés, tu l'expose via wcf ou .net remoting, les 2 projet ont donc un référence commune généralement via une interface
le serveur au démarrage il ouvre le channel et écoute
les clients au démarrage ils ouvrent un canal vers le serveur

après tu peux toujours faire un classe au milieu qui sert à dire ce que tu veux, dans laquelle le thread du channel va lire puis demander au serveur les données puis les rendre au client via un callback peut etre

Jette un oeil aux classes suivantes, qui possèdent des methodes synchrones ET asynchrones: Socket, TcpListener, TcpClient.

@Pol63

Je comprends mieux ton incompréhension. Après avoir lu un tutorial sur .Net remote, je me rend compte que cette solution était plus adapté à mon problème et plus simple car il ne faut pas traiter toute la partie connexion (établissement, maintiens, ...).

Ce qu'il y a c'est que j'ai une implémentation Client/serveur "pure". Par "pure" je veux désigner une implémentation manipulant des socket et donc sans la notion de références partagées. Il y a notamment un serveur avec un thread qui attend les nouvelles connexions, un thread par connexion accepté et un client avec un thread. Tous c'est thread étant constitué d'une boucle infinie.

D'où ma question sur la responsabilité du thread de la partie client (la classe de l'interface graphique ou la classe client ?) qui écoute la connexion pour mettre à jour l'interface graphique.

Si je ne suis toujours pas assez clair, j'écrirais le nom de mes classes avec leur méthode pour que ça soit plus concret.

@neptune
Ma question ne porte pas sur comment développer une structure client/serveur, cela existe déja (Notament avec des socket. Mais plutôt sur un choix "d'architecture" que je dois prendre.

Citation:

---

Envoyé par neptune

Jette un oeil aux classes suivantes, qui possèdent des methodes synchrones ET asynchrones: Socket, TcpListener, TcpClient.

---

Complications inutiles quand WCF encapsule déjà tout cela.

Citation:

---

Envoyé par AsPrO

Ce qu'il y a c'est que j'ai une implémentation Client/serveur "pure". Par "pure" je veux désigner une implémentation manipulant des socket et donc sans la notion de références partagées.

---

Ne pas confondre "pureté" et "réinventions de l'eau tiède" :D

j'imagine que tu reprends du code existant ensuite créer un thread par client cela ne se fait plus trop dans le framework tu as des classes plus spécialisées pour gérer les pools de threads

Cependant pour répondre à ta question persistante sur le sujet celui qui devrait créer le thread d'écoute, par rapport à l'architecture que tu décris, c'est une classe controler donc un artifice technique, une pure fabrication pour parler (grasp?) pattern, le point d'entrée du programme (main)on peut dire que c'est la méthode principale du controleur principal du programme..Grossomodo c'est lui que le moyen de communication va appeler lors d'une réception sur un port et c'est lui qui va appeler l'ihm pour lui dire de se mettre à jour ou alors l'ihm peut aussi lui demander s'il y a une mise à jour à faire et l'appliquer

Cependant cela dépend vraiment de ton architecture car tu pourrais très bien mettre à jour ton ihm avec wcf..

si tu veux une réponse plus en accord avec ta question, ce n'est pas à la classe de l'interface graphique de gérer ca je pense

m'enfin de nos jours ca ne sert à rien de s'embeter avec les sockets alors que microsoft a déjà tout codé pour nous ...

Vous avez tout à fait raison sur le fait que je "réinvente la roue" (ou l'eau tiède :p) mais je ne connaissais pas wcf (qui sera d'ailleurs mon prochain choix).

De plus c'est une petite application que je dois faire et à laquelle je donne en même temps un petit rôle didactique et ludique (et oui l'aspect réseau m'amuse beaucoup).

Pour répondre à la question, il me faut donc une classe intermédiaire entre l'ihm et la partie connexion qui connaisse les détails de l'un et l'autre ? Comme par exemple le point d'entrée (main) ou une classe controler (un peu comme dans mvc) ?

Merci à vous ;-)

Oui, même s'il existe des possibilités plus haut niveau, je pense que connaitre le fonctionnement (sans forcément le maîtriser) des Sockets n'est pas un bagage perdu pour un développeur.

en même l temps es sockets il n'y a pas grand chose à savoir pour avoir un bagage. C'est une adresse et un port. Tu rajoutes le protocole et c'est fini.

Et la dedans tu as déjà presque le ABC de wfc puisqu'il manque le C.

Hmm, je ne serais pas aussi catégorique que toi. Gérer la mécanique multi-client, broadcasting, le protocol, les échange asynchrones,... C'est assez fun, j'ai utilisé cela sur un projet précédent et apprendre la base fait du bien.

oui la partie la plus compliquée c'est le threading Aspro fait bien d'insister.

Pour faire du wcf c'est suffisant de savoir qu'une socket c'est un port et une adresse. Le broadcasting et le protocole c'est déjà se spécialiser parce que des protocoles il y en a une longue liste.

Le multi client et les appels asynchrones c'est déjà un préoccupation de threading et des choix de conception.

Il y a l'architecture réseau les équipements et logiciels associés pour lesquels je suis moins catégorique puisqu'il faut gérer une authentification passer par des passerelles, routeurs etc..

Sinon une solution c'est de créer un thread qui gére l'ihm en tout cas en cache et notifier le thread de la fenetre par defaut pour les mises à jour.