Всем привет. Имеется несколько тысяч TCP-подключений. Проблема в эффективной обработке входящих сообщений. Т.е. хочется делать это, не перебирая в цикле весь массив сокетов и не использовать по каждому потоку на один коннект.
На плюсах использовал мультиплексированный ввод/вывод(epoll/kqueue). Может в джаве есть что-нибудь подобное ? Или есть другие средства ?
ЗЫ. В java работаю недавно (и не от хорошей жизни), поэтому просьба не пинать.

google -> NIO .

Если нетвозможности\влом самому программить нио, то можно использовать Apache Mina

Это сообщение отредактировал(а) SoulKeeper - 4.3.2008, 16:15

Похоже, что NIO - это то что мне надо. В частности "Multiplexed, non-blocking I/O". Может кто-нибудь пользовался ? Буду очень признателен за пример рабочего кода.

Пинать не за что, но интересно, что так?

Собственно, если вкратце, то руководство захотело посмотреть, как будет работать сервер, написанный на сях, если его переписать на java.
От себя добавлю, что первые наработки показали очень хороший результат. Сетевая часть получилась достаточно производительной. Код действительно получается безопасный и стабильный. С волнением жду, что будет при больших critical time вычислениях.
ЗЫ. Сорри за оффтоп. 

Это сообщение отредактировал(а) kometa_75 - 6.3.2008, 11:40

Чесно говоря, есть о чём волноваться.. Когда что-то насильно навязывают без конкретных аргументов и при отсутсвии специалистов, к хорошему это не приводит.
Имхо по сравнению с нативной реализацией сетевых протоколов на ява писать одно удовольствие, правда возможностей по-меньше.
От себя пожелаю удачи и успеха и роста проекта!

В общем интересует тот же вопрос - как сделать риал-тайм сервер, который бы держал несколько тысяч клиентов... Если для 1-2000 ещё можно вешать каждого на отдельный поток и делать в нём read(), то дальше вроде начинаются ограничения ОС на кол-во потоков...

Предположим есть модель клиент-сервер, где потоки данных построены на пакетах - клиент посылает некий кусок данных, в начале которого идёт 4 байта int с указанием длины пакета. По прочтении нужного количества байт формируется клиент-пакет и отдаётся в обработку пулу потоков обработчиков пакетов... Далее асинхронно формируется сервер-пакет и добавляется в очередь для отправки клиенту.

Как реализовать такую модель, подскажите пожалуйста, буду очень благодарен!! Коммерческой необходимости реализации пока нет, но вопрос "как" не даёт покоя уже которую неделю))

Почитал про NIO... Очень мало понял...
Смотрю пример...

ServerSocketChannel это ведь абстрактный класс?.. Каким образом тут его экземпляр создаётся, или я что то совсем упустил?... Или же там есть недокументированные классы, которые расширяют абстрактные из nio и возвращаются именно их экземпляры??.. 

Смотрю ещё пример
Тоже ничего не могу понять - там ведь идет всё тот же бесконечный цикл с перебором (отличие только в том, что перебираются не все, а только свободные)?... Каким образом сигнализируется о том, что в буфер считано нужное количество байт? Ничего похожего на систему событий не заметил...
Объясните плиз как же всё-таки пользоваться этим NIO... Буду очень благодарен (и думаю что не я один), если кто-нибудь напишет нормальным человеческим языком логическую последовательность реализации описанной модели с указанием классов, которые надо использовать и комментариями...

open() возвращает дефолтную имплементацию


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


это реализуется программистом поскольку это уже протокол уровня приложения.

Посмотрите в сторону apache mina, это отличный сетевой фреймворк, вам останется только написать свой протокол и можно запускать в продакшен.

Спасибо за совет! Уже прочитал, как только увидел про него ссылку в этой же теме... Но, увы, не понимая принципа работы того, на чём написан этот фреймворк не вижу возможности его использовать!)


Если я правильно понял, то при чтении даже с канала имеющего данные от пользователя операция будет произведена без блокировки? Но ведь в любом случае, будет задержка на операции с массивом байт, лежащим уже в памяти? Можно ли как то обеспечить обслуживание соединений несколькими потоками? Чтобы на один поток приходилось, к примеру, 10-20 клиентов?..


Но ведь, в любом случае, многопоточным вариантом не обслужить больше 2000 клиентов одновременно? Просто потоков не хватит...) И насколько сильные задержки будут возникать у юзеров при обработке NIO соединений одним потоком, при условии, что все каналы имеют данные (не простаивают).

Блокировка - это простаивание потока на операции чтения. В НИО операция select возвращает список каналов, в которых в данный момент уже есть данные в буфере. В цикле один поток сначала делает select, потом читает из выбранных каналов. Поскольку данные приходят неравномерно, в разных циклах поток может читать из разных каналов.  


В НИО нельзя. Это промежуточный вариант между много- и одно- поточной схемами. Можно поставить много НИО серверов, каждый на 10-20 клиентов.


Ресурсы компьютера в любом случае ограничены. Он должен где-то брать входные данные, открывать-закрывать соединения. В многопоточной схеме каналы также обслуживаются последовательно. Вопрос сравнения эффективности переключения потоков с эффективностью select в одном потоке. А это зависит от природы данных. НИО однозначно эффективен, если данные неравномерные. А если это трансляция футбольного матча в реальном времени, то может и нет.




Пока не сделаете - не узнаете. Каналы обычно простаивают (с точки зрения компьютера и в силу природы интернета) Но это не столь важно. Важно уметь добавлять сервера при увеличении количества клиентов.  

С чего бы нельзя?

Один поток обрабатывает accept. После accept он отдает содинение на обработку другому потоку. Вот тут и можно балансировать, кому сколько отдавать. У меня так прокси написан - один поток на принятие соединений, второй на направление от клиента к серверу, третий - от сервера к клиенту. У каждого свой селектор. Всё прекрасно работает.

Действительно! Вы правы. После accept канал можно зарегистрировать в любом другом селекторе. Можно сделать 100 потоков обслуживающих 100 селекторов, в каждом по 10-20 каналов.  

Да можно-то можно. А смысл их делать больше чем ядер? 

Skipy, поделитесь сорсами прокси пожалуйста. Очень хочется посмотреть.