Какие потоки вводы/вывода использовать в клиент-серверном приложении (TCP)?

Question

[nadom]

Добрый день.
Создаю клиентское и серверное приложение на Java (TCP протокол).
Однако не могу подобрать какие декораторы потоков ввода/вывода использовать в данном случае.
Сейчас использую ObjectInputStream и ObjectoutputStream соответсвенно, но они не очень удобны.
Подскажите какие лучше использовать, учитывая специфику задачи:
Клиент посылает короткие сообщения на сервер (один объект типа String) в качестве ответа получает короткое или длинное сообщение (один объект типа String или их массив).
Сервер, соответсвенно, наоборот.
В С++ я бы передавал в начале любого сообщения его длину, чтобы получатель знал, сколько раз считывать входной поток. Думаю, на Java есть более высокоуровневое решение.

Answer 1

[nirvimel]

Вам нужны Protobuf, BSON, JSON или Thrift.
И забудьте о ObjectInputStream.

UPD: Сравнительный бенчмарк.

Comments

[nadom]

В принципе я изобретал свой велосипед для этого, о чем, конечно, догадывался (кстати получился не очень плохой велосипед).

Но похоже, что при отправке массива в начале все равно надо отправлять счетчик. Так ?

[nirvimel]

nadom: Одномерные массивы из коробки поддерживаются во всех этих протоколах без дополнительных шаманств со счетчиками. Многомерный массив чаще всего представляется как массив массивов.

[nadom]

т.е. описав сущность я смогу отправить массив объектов этой сущности без лишних забот ?

Большое спасибо, очень помогли.

[nirvimel]

nadom: Не совсем так. Из коробки доступны только примитивные типы и коллекции (массив, карта). Для пользовательских объектов приходится все-таки писать сериализаторы, для разных протоколов и библиотек, их реализующих, это делается по-разному, но в целом все не так уж сложно, например, все может сводится к перечислению полей подлежащих сериализации.

[nadom]

nirvimel:
А какой декоратор потока лучше использовать для передачи различных служебных и прочих комманд если вы говорите забыть о ObjectInputStream ?

[nirvimel]

nadom: Вам нужно совершать удаленные вызовы, передавать параметры и возвращаемое значение? Это называется RPC. На Java для этого есть куча готовых решений, гуглите "java rpc <название протокола>" и выбирайте решение. Я бы мог сказать вам просто "используйте JSON-RPC", например, он действительно решает проблемы, подобные вашей, но это только одно из возможных решений.
Я говорил забыть про ObjectInputStream потому, что нет смысла начинать писать RPC с таких низких уровней. Все эти велосипеды давно изобретены, вам надо только выбрать один под себя. Если начинать писать RPC с уровня потоков, можно и за год не завершить задачу.

[nadom]

Спасибо большое.
Использовал Java RMI + ProtocolBuffers и все стало очень просто организовать.

Answer 2

[Олег Цилюрик]

Я думаю, что ваш вопрос относится не к Java, а к специфике обмена по TCP:
- в TCP нет сообщений, никаких - это поток, ... труба байт, куда в один конец втекает, а из другого вытекает ;-)
- поэтому для передачи сообщений вы должны их как-то сами форматировать
- наиболее широко используются 2 способа: а). передавать в потоке фиксированный ограничитель конца сообщения (так работают большинство протоколов Интернет), обычно это "\n\n" (пустая строка) и б). передача вначале длины, а затем байты тела сообщения (подобно POST в HTTP).
- иногда используют 2 этих способа вместе.

Comments

[nadom]

В принципе интуитивно к этому я пришел раньше, как вы можете прочитать в сообщение.
Тут дело все-таки в специфике Java, так как там большое количесвто оберток для работы с этими потоками.
И я не могу выбрать тот, который будет максимально удобным. Приходить к передачи по байтам все-таки не хочется.