Подтвердить что ты не робот

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

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

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

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


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


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

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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