Discussion :

[onet]

Hello,

On est en pleine réalisation d'un projet en C++. Le problème, c'est que mon collègue et moi ne sommes pas d'accords sur un point: "Envoyer des informations sur le réseau". pour résumer, on a une programme en C++ sous Debian. Et on doit "discuter" avec une application en C# sous WinXP (Win 7 par la suite).

Pour cela, on doit envoyer des messages, de plusieurs natures (des commandes, des erreurs, des informations) et en recevoir (des identifiant, des tests à effectuer, des retours, etc...).

Mon collègue souhaite qu'on développent notre propre "trame", et envoyer les informations en binaire (définition d'un header, des paramètres, envois, etc...). Personnellement, je souhaite passer par une version un peu plus "évoluée", et envoyer les informations au niveau objet, soit par xml, soit par sérialisation, mais finalement envoyer une trame "texte", et pouvoir la retransformer directement lors de la récéption

Lequel a raison? lequel a tort? Quelle est selon vous la meilleure solution pour envoyer des informations via réseau ethernet entre une appli C++ et C# ?

Merci.
Onet

[ram-0000]

Mon avis :

• Le binaire risque de faire des trames plus courtes (gain de bande passante) et aussi moins facile à comprendre en cas d'interception (est ce que cet aspect est important pour vous)
• Le texte fait un protocole plus facile à debogguer et aussi à émuler (lors des phases de test). J'aime bien le format XML car cela fait un protocole très facile à faire évoluer.

[onet]

SAlut,

merci pour ta réponse, alors:

Le binaire risque de faire des trames plus courtes (gain de bande passante) et aussi moins facile à comprendre en cas d'interception (est ce que cet aspect est important pour vous)

Il s'agit d'un réseau privé, entre un Debian et un win inclus dans la meme "machine", sans aucuns accès de l'extérieur (la machine en elle même est accessible via un autre réseau, connectée exclusivement sur la Win.). Donc pas d'interception à "protéger" à ce niveau la. De plus, il ne s'agit pas de données sensibles, mais uniquement des messages et des commandes. Coté bande passante, on a/aura une réseau en 100Mbps interne. Et au vu des données qui transite, je ne vois pas de gain de bande passante spécifiques

Le texte fait un protocole plus facile à debogguer et aussi à émuler (lors des phases de test). J'aime bien le format XML car cela fait un protocole très facile à faire évoluer.

Je suis du meme avis, et c'est ce que j'essaye de faire passer comme message.

Onet

[Mac LAK]

Lequel a raison? lequel a tort?

Les deux, en fait, tout dépend de quel côté on regarde...
Côté C++, l'envoi binaire est très nettement plus simple qu'un envoi texte, et tu peux contrôler à 100% l'alignement des structures.
Côté C#, l'alignement peut poser des soucis, et pas des moindres... La gestion de l'XML est par contre nettement simplifiée par rapport au C++.
L'envoi binaire épargne la BP et le temps CPU, mais limite très fortement l'interconnexion des machines et/ou la portabilité / évolutivité.
L'envoi texte, c'est exactement le contraire : excellente portabilité/évolutivité, mais plus coûteuse en BP et charge CPU.

Vu le contexte, ce serait donc toi qui aurait raison... Mais il serait très facile de trouver un cas d'utilisation / déploiement où ce serait ton collègue.

Quelle est selon vous la meilleure solution pour envoyer des informations via réseau ethernet entre une appli C++ et C# ?

Pour du contrôle/commande ou équivalent, ce que tu cherches apparemment à faire, je passerais directement par une interface de type CORBA pour ma part...

A ce sujet, je te conseille notamment d'aller jeter un œil sur la librairie ICE : portable, multi-langage, facile d'utilisation et ça te décharge à 100% des problèmes de réseau. Côté code, ça se résume peu ou prou à quelque chose d'aussi simple que des accesseurs...

Côté avantages : utilisation simple, pas de gestion directe du réseau, les envois sur le réseau sont économiques sans devoir se peler à la main les encodages/décodages/adaptations entre langages et plate-formes.
Côté inconvénients : une dépendance de plus pour ton programme, et une phase de configuration du réseau inévitable pour permettre aux endpoints ICE de se "trouver".