Сириализация / десериализация Protobuf-net c # против переполнения стека Linux
Я передаю сообщения между клиентом Windows C # и сервером Linux C ++ через TCP-сокеты. Код C # использует protobuf-net v2, Linux-версию protobuf для Linux. Небольшой тестовый объект, который я передаю, имеет 6 полей (Enum, Int, String). Мне нужна помощь с двумя проблемами:
-
Часть C # не может десериализовать данные, отправленные из Linux, если только поток памяти, используемый в качестве хранилища данных, не инициализирован с помощью двоичного массива в конструкторе. Массив не может быть больше данных, отправленных из Linux (в моем случае 9 байт). Пример кода — byte [] data = new byte [9], скопировать данные из сокета в массив.
MemoryStream myStream = новый MemoryStream (данные), передать myStream в Serializer.Deserialize …
Если я инициализирую MemoryStream без бинарного буфера или с массивом из 1024 байтов, Deserialize создаст пустой объект без обработки данных. -
Когда я пытаюсь сериализовать один и тот же объект с теми же значениями, что и в Linux, то же самое в C #, размер данных составляет 11 байт против 9 в Linux. Я проверил байтовый массив в отладчике, версия C # имеет те же 9 полей, что и данные Linux в индексах 2-11 массива. Индекс 0 равен 8, индекс 1 равен 9. Я могу попытаться обойти проблему, изменив код десериализации Linux, просто нужно знать, всегда ли мне приходится иметь дело с двумя дополнительными полями в начале сообщения. Кроме того, я могу добавить два дополнительных поля к сообщениям, генерируемым в Linux, если это собирается исправить мою десериализацию в C #, просто нужно знать, как генерировать значения для этих двух полей.
Благодарю.
Алекс.
Решение
- Данные Protobuf не являются самоограниченными, просто. Вы можете, однако, создать
MemoryStreamили жеProtoReaderтот принимает большая полезная нагрузка, но ограничена виртуальной длиной. Если вы отправляете несколько сообщений, вам нужно знать длину полезной нагрузки — это неизбежно. Это часто достигается с помощью префикса длины. Я ожидаю, что это приведет к случайным ошибкам — скорее всего, «неверный заголовок поля 0» — и мне интересно, если вы проглотили это исключение - комментировать невозможно без конкретного примера; скорее всего что-то делать со значением по умолчанию поля № 1 (заголовок 8 === «поле 1 варинт»)
Другие решения