Discussion :

[KingAzenith]

Bonjour,
Je souhaite créer deux application: une application "server" et une application "client", les deux en C#.
Je voudrais que le client puisse envoyer à l'application server un identifiant suivi d'une phrase et que le serveur puisse récupérer ces données et vérifier si l'identifiant est valide si oui, envoyer une réponse à la phrase au client.
Cela semble être simple mais je n'y connais rien en architecture client-server (je me plonge dans un nouveau bassin)...
Merci à ceux qui prendront le temps de répondre.

[ZenZiTone]

Des exemples, c'est pas ce qui manque sur le net... Pour faciliter tes recherches, utilise le terme "socket", tu devrais trouver pas mal de littérature.

Sur MSDN ils te proposent ça :
client - https://docs.microsoft.com/fr-fr/dot...socket-example
serveur - https://docs.microsoft.com/fr-fr/dot...socket-example

[KingAzenith]

Merci, j'aimerai aussi savoir comment ça fonctionne, comment tester ce type d'application (en local si possible), comment la débogger, et comment et où la déployer...

[ZenZiTone]

Le sujet de la communication client/serveur est très vaste, donc difficile d'en dire plus sur un forum...

Voici un autre lien un peu plus générale : https://docs.microsoft.com/fr-fr/dot...amming/sockets

Pour le reste, il faut faire des recherches point par point pour bien appréhender le sujet.. Normalement tu devrais trouvé toutes les informations dans le lien ci-dessus. Par contre ça fait beaucoup de lecture

Si tu as des questions sur des points précis, n'hésite pas. Mais avant ça, n'hésite pas a prendre du temps pour te documenter sur le sujet.

[vanquish]

Si l'application ne fait QUE ce que vous décrivez (un simple aller/retour), les socket sont parfait.
Mais pour aller plus loin, perso, j'utiliserais un web-service pour la partie serveur (herbergé sous IIS) ; web-service que viendra interroger l'appli cliente.
Ca va permettre de récupérer tout un tas de mécanismes offert par asp.net et IIS et le protocole HTTP(S)

[Pol63]

le dialogue réseau se fait d'un client vers un serveur
pour identifier le serveur le client doit connaitre son nom (genre pc_machin) ou son adresse ip (v4 ou v6)
un nom étant résolu en adresse ip (si tout se passe bien ^^)
il faut aussi préciser un port (de 0 à 65k)

il faut aussi choisir un protocole, tcp et udp sont les 2 plus courants (mais il y e en a d'autres, voir des surcouches de protocoles)
udp est une connexion non connecté (désolé ^^)
les paquets (ensemble d'octets) sont envoyé mais ne sont pas garantis d'arriver dans l'ordre, ou même d'arriver
par contre ce protocole est légèrement plus rapide, donc c'est bien pour du streaming, pour du dialogue sérieux on utilise tcp

le principe du tcp c'est que le serveur écoute sur un port puis attend les demandes de connexion
il doit aussi préciser sur quel ip il accepte les connexion, car un pc peut avoir plusieurs adresses ip
un port d'écoute ne peut etre ouvert que par un programme à la fois
le client demande une connexion ver un hôte par son nom/ip + port, le serveur accepte, une fois que c'est fait les 2 peuvent s'envoyer des octets
x clients peuvent se connecter à un serveur, même depuis la même machine

pour faire des tests en local c'est tout à fait possible, un réseau fonctionne aussi en local
comme dit précédemment un pc peut avoir plusieurs ip et c'est souvent le cas (une adresse ipv4 + 1 ipv6 par exemple)
de plus Windows (et surement les autres aussi) ont une adresse dit de loopback qui retombe sur lui même, 127.0.0.1 (et ::1 en ipv6), c'est 2 ips seront résolues par le nom localhost
on peut donc se connecter à sa propre adresse ip soit avec localhost,

127.0.0.1, son ip de réseau local (ipconfig peut te la donner) ou même ::1 si on a activé l'ipv6


concernant .net :

il y a des classes sockets qui gèrent ça (protocoles, connexion, envoie d'octets …)
mais elles sont complexes à utiliser

après en plus haut niveau et orienté TCP il y a tcplistener (côté serveur) et tcpclient (pour une connexion) qui sont beaucoup plus simples mais qui demandent néanmoins de connaitre un peu le réseau, à savoir que qu'un paquet ne peut pas dépasser x ko (8ko par défaut je crois) donc si on envoit plus c'est découpé et le receveur recoit le "message" en plusieurs fois
et que même si ce que veut envoyer ne dépasse pas ca peut etre découpé
sur du socket pur on utilise donc une norme de dialogue qui peut etre "maison", le plus souvent soit une entete de message de taille fixe qui décrit la longueur du message, ou encore un caractère de fin de trame (pour savoir qu'on a reçu un message et qu'on peut maintenant le traiter)
NB : tout peut se transformer en octets, bitconverter.getbytes(..) pour un type simple, system.text.Encoding.x.getbytes(str) pour un string, sérialisation xml ou binaire pour une classe

encore plus haut niveau il y a WCF qui permet de créer des webservices (sur du tcp ou autre), ca peut etre assez chiant à comprendre au début et à mettre en place, mais ca permet de s'affranchir de coder la gestion des messages (découpage, traitement, réponse …)
ici on expose une méthode ou une fonction en .net côté serveur, le client appelle cette méthode en utilisant le code wcf comme il appelerait une méthode locale (avec les éventuels paramètres), wcf s'occupe du transport réseau, et si c'est une fonction le client reçoit la réponse, on a donc pas l'impression de faire du réseau et c'est très pratique


bonne chance ...

[KingAzenith]

Merci de vos réponses

Pour résumer ce dont j'ai besoin...
Client: Envoie au serveur une chaîne: "123456;Bonjour!"
Serveur: Découpe la chaîne (id="123456" et msg="Bonjour!")
Si l'id est bon, répondre au client: "Coucou!"
sinon ignorer

Quel protocole est-il préférable que j'utilise? Et que mettre dans le code?
Je ne comprends pas les codes d'exemples de Microsoft pour les sockets asynchrones pour clients et serveurs... Quelqu'un peut m'expliquer à quoi servent chaque ligne?

[Pol63]

socket est le techno de base, mais bien trop complexe
utilises plutot tcplistener et tcpclient pour lesquels tu trouveras des exemples beaucoup plus simples (genre client.connect("localhost", 20000))
ca utilises la classe socket (qui sert à plusieurs protocoles) en faisant abstraction de plein de choses (en ne laissant d'utile que ce qui est nécessaire en tcp)