1

Я недавно смотрел protobuf-net и буферы протокола, и пока это кажется впечатляющим. То, что мне интересно, это служебная сторона вещей. Если я понял право на документацию Google, вы можете объявлять службы в файлах .proto. Мои вопросы:protobuf-net или службы буфера протокола с C# на python и другие lang

  1. Эта служба поддержки реализована в protobuf-net или другом dotnet protobuf lib?
  2. Является ли сервисная поддержка полностью перекрестным языком, например, буферами протоколов?
  3. Насколько сложно создавать клиенты на другом конце на основе декларации, объявленной в файле .proto?

в основном я рассматриваю создание служб таким образом полотна или TCP на основе с использованием Protobuf, если это возможно, чтобы уменьшить накладные расходы при обработке больших объемов и Protobuf кажется идеальным, как мои клиенты обычно реализуют в смеси языков, таких как Python, Java, C++ и dotnet. Я действительно хочу что-то, что было бы легко как для них, так и для меня интегрироваться в их приложение, и, поскольку я планирую использовать protobuf внутри, надеюсь, будет легко интегрироваться на моей стороне.

[править] Просто некоторая дополнительная информации code.google.com/apis/protocolbuffers/docs/proto.html#services То есть тип службы я говорил о но я не уверен, что Langs действительно поддерживает его и что вы действительно получаете от объявления в файле .proto.

+0

Как сказал Джон - ни один RPC-стек не является «официальным» в protobuf, поэтому protobuf-net в настоящее время не имеет какой-либо конкретной кросс-платформенной спецификации для реализации –

+0

, так что это код.google.com/apis/protocolbuffers/docs/proto.html#services unoffical? Думал, что это была документация google – Seer

+0

, у меня нет документализованного стека RPC для реализации –

ответ

3

Если вы посмотрите на страницу Third Party Add Ons, вы найдете множество отдельных реализаций RPC. Тем не менее, я не верю, что Google выпустила реализацию RPC, и я не уверен, что в третьей партии есть какие-то «стандартизированные». Вам действительно нужно выбрать механизм RPC, который вам понравился, и вероятно, немного потрудиться, чтобы реализовать его там, где он еще не существует.

(. Отказ от ответственности: Я работаю в Google и собственный проект Protobuf-CSharp-порта Однако, я не пишу это «от имени» от Google Это только мое личное мнение.).

+0

, можете ли вы объяснить, что «служба» вместо «сообщения» в информации protobuf на http://code.google.com/apis/protocolbuffers/docs/ proto.html # services Это, по-видимому, указывает на то, что для некоторых языков есть один. Вопрос в том, что я догадываюсь о том, какие языки, как перекрестный язык, и если есть реализация сервера/клиента dotnet и какие языки также реализуют совместимые клиенты. – Seer

+0

Часть декларации службы является кросс-платформенной, и, надеюсь, большинство реализаций ее реализуют, но вам нужно специфический RPC-механизм для его подключения. На этой странице: «Затем компилятор протокола генерирует абстрактный интерфейс под названием SearchService и соответствующую« заглушку ». Завершает все вызовы RpcChannel, который, в свою очередь, является абстрактным интерфейсом, который вы должны определить сами по себе RPC ". –

+0

О, теперь все имеет смысл! Затем каждому клиенту необходимо будет внедрить клиент RPC, который будет скомпилирован с этим отдельным сервером, поскольку, поскольку для сервера RPC нет стандарта, для клиента не будет стандартного для клиента и, следовательно, не будет возможности генерировать кросс-язык клиента в полученных библиотеках и генераторы кода. Есть ли простая реализация RPC-клиента/сервера с перекрестным языком, которая будет работать с protobuf, или это, вероятно, мне нужно будет построить по крайней мере часть ее, если я хочу, чтобы это был многоязычный язык? – Seer