Bonjour, 

Je suis entrain de développer un projet sous C#.  Voici ses grands points:

1. Connexion Client/Serveur avec les sockets TCP.

2. Un protocole spécifié a été mis en place pour l'échange des messages (définition des messages échangés, leurs formats ainsi que le Header qui est le même pour tout les messages).

Côté programmation, je ne sais pas comment procéder. J'ai effectué des recherches sur internet, j'ai trouvé que la solution est d'écrire dans le bas niveau des sockets (RAW socket) sauf que après j'ai vu que Windows l'ont supprimé. 

Comment je peux encapsuler et décapsuler mes messages en respectant mon protocole? 

j'ai pensé à fragmenter moi même chaque message après l'avoir reçu via le socket de cette manière:

a. récupérer la taille de la trame qui se trouve dans le header.

b. comparer avec la taille de la trame reçue.

c. si c'est le même, procéder au traitement du message.

d. récupérer le premier champs de la trame qui contient toujours le type du message reçu.

e. traiter le message selon son type.

Est ce que c'est faisable comme ça? est ce que ça ne va pas consommer beaucoup de temps sachant que les échanges doivenet être super rapide?

J'attends vos commentaires et suggestions.

D'avance, Merci.

-
Edité par hajarhiyadi 16 janvier 2018 à 18:02:29

Bonjour,

hajarhiyadi a écrit:

1. Connexion Client/Serveur avec les sockets TCP.

...

Côté programmation, je ne sais pas comment procéder. J'ai effectué des recherches sur internet, j'ai trouvé que la solution est d'écrire dans le bas niveau des sockets (RAW socket) sauf que après j'ai vu que Windows l'ont supprimé. 

Ce que tu dis la est en contradiction!

Tout ce que tu veux faire c'est envoyer via tcp une structure fixe représentant ton header type.
 Pas besoin d'aller dans les raw sockets.

@breizhbugs

Bonjour, merci pour votre réponse. 

pourriez-vous me donner un exemple ou un lien vers une documentation ou un tutoriel?

Est ce qu'il s'agit de la serialisation en binaire? 

juste une information les valeurs des données échangées sur le réseaux doivent être en Big Endian.

-
Edité par hajarhiyadi 17 janvier 2018 à 10:30:54

TCP est un protocole orienté flux, pas message.

C'est donc un très mauvais protocole pour votre besoin, et encore plus si les débits crêtes doivent être importants, UDP serait largement plus adapté, voir RUDP.

Pour ce qui est du Big Endian, un simple sérialisateur qui l'utilise fera l'affaire.

Montrez ce que vous avez déjà fait et ce que vous ne comprenez pas dans l'un des milliers de tutoriels sur le net qui montre comment envoyer des données via des sockets en C#.

bonjour et merci pour votre réponse.

Je n'ai pas de problème avec l'échange les données via les Sockets. Comme vous avez dit, il y a plein de tutoriels là dessus. Je me demandais juste si je veux respecter un format de message (comme j'avais cité), y aura t il des fonctionnalités spécifiques à intégrer.  

bacelar a écrit:

TCP est un protocole orienté flux, pas message.

C'est donc un très mauvais protocole pour votre besoin, et encore plus si les débits crêtes doivent être importants, UDP serait largement plus adapté, voir RUDP.

Pour ce qui est du Big Endian, un simple sérialisateur qui l'utilise fera l'affaire.

Montrez ce que vous avez déjà fait et ce que vous ne comprenez pas dans l'un des milliers de tutoriels sur le net qui montre comment envoyer des données via des sockets en C#.

-
Edité par hajarhiyadi 29 mars 2018 à 14:27:36

Je le répète, TCP est un très mauvais protocole pour implémenter des échanges de messages.

UDP ou RUDP sont bien plus adaptés aux échanges de messages.

Les implémentations de framework de MOM (Message Oriented Middleware) vous montreront des exemples d'utilisations de protocoles et méthodes adaptés à ce type de tâche.

>beaucoup de temps sachant que les échanges doivenet être super rapide?

Vous avez déjà perdu la course juste avec le "three-way handshake" de l'établissement de la connexion TCP.

Si vous voulez aller le plus vite possible, il faut le faire au niveau des drivers réseaux.

Mais, bon, ça rattrapera jamais le boulet du "three-way handshake TCP" et je vous sens moyennement aguerri dans le domaine du développement de drivers réseaux. (sinon ça ferait longtemps que vous auriez abandonné TCP ou donné une raison valable de payer un tel surcoût).

Les réseaux modernes sont une telle jungle que je pense que vous prenez le problème complètement à l'envers.

Généralement, on ne se fixe pas un protocole mais on se met en position de pouvoir choisir le protocole en fonction des contraintes des environnements réseaux où la solution devra être déployée (sécurité, topologie du réseau, dimensionnement des machines, etc...).

C'est toute la logique derrière WCF qui permet de supporter toute une panoplie de format standard de base et de pouvoir l'étendre en y ajoutant des classes d'interception, pour que le code récupérant les messages ne change pas en fonction du protocole utilisé.

En vous acharnant avec vos sockets, vous avez tous les inconvénients et aucun des avantages de chacune des solutions :

- vous devez vous palucher à la main toutes les sérialisations tout en n'ayant des performances pas top.

- vous êtes tanqué dans un protocole même si celui-ci n'est pas adapté à l'environnement réseau, même si la charge utile contenant les données s'en fout du protocole.

- etc...

Faut choisir vos priorités, vraiment.

Si vous voulez vraiment poursuivre dans cette solution de "Socket Utilisateur", je vous conseille d'architecturer correctement votre code pour qu'il respecte le caractère "stack" de "votre protocole".

Votre description montre que vous décrivez en même temps 2 niveaux de protocoles, celui qui s'occupe de la cohérence des données de "trame" avec le header, et celui qui interprète le contenu du PDU du protocole précédent pour en faire une gare de triage.

Mon conseil est de faire des classes distinctes pour ces 2 niveaux de protocoles.

Si vous passez de TCP à UDP ou à HTTP etc..., vous n'aurez qu'à changer la classe de la couche protocolaire inférieure sans avoir à refaire la couche supérieure.

Les mécanismes de serialisation/déserialisation d'objet de .NET permettraient de très facilement implémenter la couche supérieur, voire de facilement migrer vers des représentations plus standard (donc avec des solutions optimisées ad hoc, comme XML, JSON, BXML etc...).