IPC: WM_COPYDATA + сериализация / десериализация - PullRequest
0 голосов
/ 29 июля 2010

В настоящее время я работаю над 2 приложениями .NET, которые должны взаимодействовать друг с другом. Была выбрана простая система обмена сообщениями Windows, и в данный момент это работает прекрасно. Данные, которые отправляются в сообщениях, представляют собой простую строку, но теперь я создал класс сообщений, который содержит команду (enum) и член data (string), а затем и другие возможные члены.

Когда я отправляю экземпляр такого класса сообщений, он сериализуется в байты, а затем преобразуется в строку base64. Затем он отправляется с помощью Windows SendMessage (). С другой стороны я делаю наоборот. В итоге исходный объект восстанавливается и становится доступным в другом приложении.

Хотя этот механизм работает, мне было интересно, безопасно ли это делать. Действительно, есть некоторые издержки, строка base64 намного длиннее, чем исходное строковое решение (но мне пришлось бы разобрать эту строку вручную, чтобы получить часть команд и данных) Существует ли максимальный размер сообщений, которые можно отправить с помощью SendMessage?

Кроме того, я бы предпочел держаться подальше от .NET для удаленного взаимодействия для этого проекта и использовать решение SendMessage.

Есть идеи? Может, вместо этого использовать JSON для ограничения накладных расходов?

Спасибо.

Пика

Ответы [ 3 ]

1 голос
/ 29 июля 2010

Используйте XDMessaging (http://xdmessaging.codeplex.com/), который поддерживает WM_COPYDATA, именованные каналы и обмен сообщениями IOStream - обеспечивая очень гибкое, надежное и проверенное решение, вместо того, чтобы что-то делать самостоятельно.

Как насчет использования двоичной сериализации в вашем классе (http://msdn.microsoft.com/en-us/library/4abbf6k0(v=VS.71).aspx) с XDMessaging? Это было бы довольно компактно и очень легко реализовать.

0 голосов
/ 29 июля 2010

Я бы действительно рекомендовал использовать более современный, масштабируемый подход. Например, вы могли бы легко использовать именованные каналы для связи и просто использовать стандартную функциональность потока вместо того, чтобы пытаться отправлять сообщения, которые должны быть закодированы.

(Лично я бы, вероятно, использовал WCF , поскольку у него было бы много преимуществ, в том числе возможность бесплатной работы на разных машинах ...)

0 голосов
/ 29 июля 2010

Если вам просто нужно отправлять сообщения, посмотрите на архитектуру шины сообщений, такую ​​как Rhino Service Bus или NServiceBus .Они обеспечат относительно простую и намного более надежную реализацию обмена сообщениями.

...