Оптимизированный способ сделать RPC в .Net

Question

Я рассматриваю возможность перемещения частей приложения .Net на другие компьютеры. Очевидный способ сделать это - просто использовать WCF с двоичным протоколом tcp, например, в качестве описателя в " Самый простой способ получить быстрый RPC с .NET? ".

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

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

Но это МНОГО работы, так как мы говорим о нескольких сотнях API-команд.

Есть какие-нибудь мысли о том, как лучше всего это осуществить?

Изменить: Для пояснения: сериализация AFAIK в .Net не оптимизирована. Существует относительно высокий штраф за сериализацию и десериализацию объектов, например, при внутреннем использовании Reflection. Это как раз то, чего я хочу избежать, и, следовательно, мой метод прямого сопоставления (аппаратного подключения).

После некоторых поисков я нашел одно приложение, у меня было смутное воспоминание: http://www.protocol -builder.com /

Answer 1

Сокращение общего трафика (что было бы основным преимуществом пользовательского протокола по сравнению с использованием WCF) не окажет большого влияния на задержку. Основной проблемой было бы сведение к минимуму объема данных для «требуемых параметров», поэтому каждый запрос является относительно небольшим. Сериализация по умолчанию в WCF уже достаточно эффективна, особенно при использовании TCP в локальной сети.

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

Лично я бы просто использовал WCF, а не пытался создать собственный протокол. Если, запустив его, вы обнаружите, что у вас есть проблема, вы можете легко абстрагировать транспорт к пользовательскому протоколу в то время и сопоставить его с теми же интерфейсами. Это потребует очень мало дополнительного кода по сравнению с простым созданием собственного стека протоколов и, вероятно, сделает код намного чище (так как пользовательский протокол будет изолирован в едином сопоставлении с «чистым» API). Однако, если вы обнаружите, что транспорт не является узким местом, вы сэкономите себе огромное количество труда и усилий.