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

Question

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

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

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

<Ч>

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

<Ч>

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

Answer 1

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

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

Answer 2

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

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

Answer 3

В настоящее время практически нет причин писать такой сетевой код с нуля. Такие пакеты, как netty.io , почти всегда дают вам более надежный и гибкий код с меньшим количеством строк кода, чем решение, созданное вручную. будут. Кроме того, с Netty вы можете получить поддержку SSL без осложнения вашей реализации. Такие библиотеки, как netty, также устраняют & Quot; async vs threads & Quot; Этот вопрос почти полностью обеспечивает хорошую производительность и позволяет при необходимости корректировать модель потоков.

Answer 4

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

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

Answer 5

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

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

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