2010-10-08 3 views
5

Nous construisons une nouvelle application de système d'inspection visuelle. Le système d'inspection actuel doit être C++ pour plusieurs raisons. Pour ce système, nous utiliserons Boost & Qt.Le moyen le plus rapide de communiquer entre C++ et C#

Pour notre interface utilisateur, nous recherchons actuellement l'utilisation de WPF/C# pour les rapports basés sur l'interface utilisateur et SQL. Le facteur de complication que l'interface utilisateur doit exécuter à la fois local sur la même boîte que le système d'inspection C++ ou à distance sur une autre boîte si le système d'inspection n'a pas de moniteur ou de clavier.

Notre préoccupation est de savoir quel est le moyen le plus rapide de transférer des données entre les deux systèmes? Nous examinons actuellement un système à base de socket utilisant des tampons de protocole Google pour la sérialisation. Les tampons de protocole génèreront du code pour C++ et C# (jskeet/dotnet-protobufs).

Est-ce que quelqu'un a des suggestions/expériences?

+0

TCP et protobuf sonne bien. Avez-vous une préoccupation ou une question spécifique? – dtb

+1

[protobuf-net] (http://code.google.com/p/protobuf-net/) semble être l'implémentation de protobuf préférée pour .NET. – dtb

+0

C'est un domaine où je n'ai pas beaucoup d'expérience. Je me demandais s'il y avait de meilleures options. –

Répondre

1

Si vous cherchez vraiment le moyen le plus rapide de communiquer avec votre système d'inspection C++, alors j'implémenterais les deux cas. Une interface locale utilisant des canaux nommés (voir ici Interprocess communication for Windows in C# (.NET 2.0)) et une interface distante utilisant des tampons de protocole Google pour les situations où votre système d'inspection n'a pas de clavier et/ou de moniteur connecté. Ensuite, l'interface utilisateur essaie d'abord d'ouvrir un tube nommé sur la boîte locale et si cela échoue, l'utilisateur doit entrer une adresse distante pour la communication par socket.

espoir qui aide un peu ...

+1

Great Link, merci. Liens suivis sur SO Question 50153 à la classe de liaison de canaux nommés (http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx). Vraiment intéressant, cependant, d'un commentaire sur la page MSDN, il semble qu'il y ait une limite cachée de 16k à 20k par message. Cela peut nous causer un problème car nous avons des blocs de messages qui vont être plus gros que ça. –

0

je regardais zeromq si vous voulez vraiment le plus rapide au moindre coût

Questions connexes