java.net против java.nio

Question

В какой момент лучше перейти с java.net на java.nio? .net (не сущность Microsoft) проще для понимания и более знакома, в то время как nio масштабируема и поставляется с некоторыми изящными функциями.

В частности, мне нужно сделать выбор в этой ситуации: у нас есть один центр управления, управляющий оборудованием на нескольких удаленных площадках (каждый сайт с одним компьютером, управляющим несколькими аппаратными блоками (трансивер, TNC и ротатор)). Моя идея состояла в том, чтобы написать на каждом компьютере приложение для сервера, которое будет выполнять роль шлюза от центра управления к оборудованию радиосвязи, с одним разъемом для каждого устройства. Насколько я понимаю, NIO предназначен для одного сервера, для многих клиентов, но я думаю, что это один клиент, много серверов.

Полагаю, третий вариант - использовать MINA, но я не уверен, что это слишком много для простой проблемы.

---

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

---

На самом деле, поскольку удаленные машины служат только для взаимодействия с другим оборудованием, будут ли RMI или IDL / CORBA лучшим решением? На самом деле, я просто хочу иметь возможность отправлять команды и получать телеметрию от оборудования, и мне не нужно создавать какой-то протокол прикладного уровня для этого.

Answer 1

Избегайте NIO, если у вас нет веских причин использовать его. Это не очень весело и может быть не так полезно, как вы думаете . Вы можете улучшить масштабируемость, когда будете иметь дело с десятками тысяч соединений, но при меньших значениях вы, вероятно, получите лучшую пропускную способность с блокировкой ввода-вывода. Как всегда, прежде чем делать что-то, о чем вы могли бы пожалеть, сделайте свои собственные измерения.

Еще кое-что нужно учитывать: если вы хотите использовать SSL, NIO делает его крайне болезненным.

Answer 2

Масштабируемость, вероятно, повлияет на ваш выбор пакета. Для java.net потребуется один поток на сокет. Кодирование будет значительно проще. java.nio гораздо эффективнее, но может быть сложным для программирования.

Я бы спросил себя, сколько соединений вы ожидаете обработать. Если это относительно немного (скажем, <100), я бы пошел с java.net. </p>

Answer 3

Почти нет причин писать этот вид сетевого кода с нуля. Такие пакеты, как netty.io , почти всегда дают вам более надежный и гибкий код с меньшим количеством строк кода, чем решение, созданное вручную. Кроме того, с Netty вы можете получить поддержку SSL без осложнения вашей реализации. Библиотеки, такие как netty, также почти полностью устраняют вопрос «async vs threads», дают вам хорошую производительность и, тем не менее, позволяют настраивать модель потоков по мере необходимости.

Answer 4

Учитывая небольшое количество подключенных соединений, java.net звучит как правильное решение.

Другие авторы говорили об использовании XML-RPC. Это хороший выбор, если объемы отправляемых данных невелики, однако у меня был плохой опыт работы с протоколами на основе XML при написании межпроцессных коммуникаций, которые передают большие объемы данных (например, большие запросы / ответы или частые небольшие объемы данные). Стоимость синтаксического анализа XML, как правило, на несколько порядков выше, чем для более оптимизированных форматов проводов (например, ASN.1).

Для приложений с низким уровнем громкости простота XML-RPC должна перевешивать затраты на производительность. Для передачи больших объемов данных может быть лучше использовать более эффективный проводной протокол.

Answer 5

Количество соединений, о которых вы говорите, говорит мне, что вы должны использовать java.net. На самом деле, нет причин усложнять вашу задачу с неблокирующим вводом / выводом. (Если ваши удаленные системы не обладают достаточной мощностью, но тогда почему вы используете на них Java?)

Взгляните на пакет Apache XML-RPC . Он прост в использовании, полностью скрывает от вас сетевой материал и работает над старым добрым HTTP. Не нужно беспокоиться о проблемах с протоколом ... все это будет выглядеть как вызовы методов с обоих концов.