2011-08-14 7 views
2

Я работаю над простым клиент-серверным приложением, которое использует сокеты для всех коммуникаций. Коммуникации основаны на пакетах и ​​концепция пакетов реализуется с использованием набора классов и /ObjectOutputStream обертки для потоков сокетов.Плюсы и минусы для использования ObjectInputStream/ObjectOutputStream для реализации сетевых «пакетов» в Java?

Удивление, если этот подход имеет недостатки по сравнению с полностью текстовым протоколом (например, IRC) или «очень двоичным» материалом, где я явно работаю с байтами.

Давайте проигнорируем здесь проблемы с трафиком («qwerty» против «qwerty» + 1 Кбайт метаданных) и учитывайте только надежность и ремонтопригодность.

Как вы думаете?

ответ

5

Лично я обнаружил, что двоичная сериализация, встроенная в Java, очень болезненна. Это ludicrously легко закончить с несовместимостью версий, даже если вы ничего не изменили ожидайте, чтобы вызвать проблемы.

Это не проблема, если:

  • Вы можете гарантировать, что ваши клиенты/серверы будут все работает точно так же версию кода.
  • Вам никогда не нужно читать данные, написанные предыдущей версией.

Возможно, это ваша ситуация - но лично я предпочитаю формат сериализации, который позволяет мне быть более гибким с версией. Теперь это не требует, чтобы он был либо двоичным, либо текстовым. Вы можете использовать JSON, Protocol Buffers, Thrift или любое количество других опций. Каждый из них будет иметь отдельные плюсы и минусы, но каждый из них, вероятно, будет разработан с более простой совместимостью версий, чем с Java.

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

Что касается выбора между текстовыми и двоичными формами - за и против разумно очевидно. Текст больше, но легче диагностировать, что происходит, просто просматривая сетевые трассы. Конечно, вы должны убедиться, что используете ту же кодировку с обеих сторон.

О, и конечно же, если вы хотите общаться с клиентом/сервером без Java, вы будете иметь трудное время, если вы уже использовали родной сериализации в Java :)

+1

+1: Большинство бинарных форматов меньше текстовых форматов, однако сериализация текста может быть меньше, чем сериализация Java (поскольку более поздняя версия довольно неэффективна). –

2

It.sa боль поддерживать обратную сопоставимость с сериализованными объектами, а клиенты без java не могут разговаривать с вашим сервисом. Сериализованные объекты также невелики по отношению к сериализованному размеру.

Вместо этого я бы использовал что-то вроде буферов протоколов.