Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > Java: Работа с сетью > MINA DemuxTest |
Автор: Platon 16.10.2007, 20:48 | ||||||
Здравствуйте, уважаемые. Решил наконец опробовать Apache Mina и не стал мелочиться, сразу стал эксперементировать с демуксами, выглядит очень заманчиво!!! Но простой тест потерпел фиаско.
Тут 2 проблемы, как правильно оформить логгер, выдает сообщения о необходимости инициализации:
и почему сервер так и не выводит "Hello"? |
Автор: Platon 16.10.2007, 21:40 |
Невнимательно читал, на сайте есть http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/sumup/, так что пока можете не помогать *CONFUSED* |
Автор: Platon 17.10.2007, 10:41 | ||||||||||||||||||||||||||||
Ну, что ж, уважаемые. Сочту за честь поделиться накопленным за 2 дня опытом в сфере Apache MINA Demuxing Предыстория: Эпиграф: "Яви мне чудо!" Началось это давно, когда я решил написать тестовую систему задачек для школьников и студентов. Взялся с ходу накатал сервер, клиент, даже архитектура была приятной, легко расширяемый протокол сервера, но 1 НО, проблема с потоками, я сделал простенькую схему 1 соединение - 1 поток. Нет, не думайте, что я лузер, и моя система полетела, нет она работала нормально, даже 500 клиентов легко держала, но меня угрызали сомнения: "Все равно не по умному сделал, расход ресурсов большой, да и 500-1000 потоков - это какое-то больное приложение". Сел делать опять же свою сетевую архитектуру. Все, теперь были worker'ы в пуле, все путем, все красиво, но так и ни разу не откомпилировав, ни разу не запустив, обратился я к его величеству "Google", с 1 только вопросом: "О, Великий Google ты знаешь всех и вся, скажи маюсь ли я дурью?", Google немного подумал, и выдал мне свой немногословный вердикт: "Маешься", любезно указав на сайт http://mina.apache.org просвещенный от беседы с гуру, я направился в святая святых - сайт проекта MINA, и нашел я там своё умиротворение. Причины: В MINA есть много всяких разных протоколов, которые подходят для рядовых задач(типа протокола текстовых строк или серриализации), но я привык экономить на спичках, поэтому решил выбрать самый экономный(на траффике) и гибкий протокол а именно некий Demux Т.к. на сайте еще не было ни одной статьи по MINA (чему я был очень удивлен), я взял смелось возложить на себя такую ответственность и размочить нулевой счет. Действие: Я не собираюсь давать основы MINA, они довольно толково описаны на сайте http://mina.apache.org/documentation.html, повторяюсь, я лишь делюсь полученным за 2 дня опытом. Итак, Demux - это гибкий и экономящий траффик механизм, сразу скажу, что далеко не самый простой, если не сказать самый сложный, но как говорится - "Скупой платит дважды". Введем такие классы как
и
и
Начнем с сервера:
Стандартная структура строительства сервера.
Здесь мы инициализируем demux фабрику и регистрируем всех обработчиков входных данных В моем случае сделан просто 1, но можно сделать и 2 (CounerDecoder и HelloDecoder) и зарегистрировать их по очереди
Я сделал 1 обработчик для простоты. Еще 1 отличающий момент - это обработчик сообщений:
Как мы видим здесь к каждому сообщению (причем оно уже высокоуровневое, это очень приятно) мы приписываем свой обработчик, т.е. CountHandler обрабатывает все сообщения типа CountMessage. а HelloHandler обрабатывает все сообщения типа HelloMessage. Подведем итоги: В экземпляр класса DemuxingProtocolCodecFactory мы регистрируем обработчика низкоуровневых сообщений (буквально поток байтов), который ддолжен выдавать нам высокоуровневое сообщение в виде POJO В экземпляре DemuxingIoHandler мы связываем тип сообщения с его обработчиком. (Не попробовал случай когда 1 сообщению привязаны 2 обработчика или наоборот, и думаю не стоит) Слудующий обработчик низкоуровневых сообщений
Метод decodable сообщает нам есть ли возможность прочитать данным обработчиком текущий поток данных. Во всех чтения из буфера необходимо убедиться, что данные в нем есть и их хватит на проведение операции. Если у нас не хватает данных, мы сообщаем MessageDecoderResult.NEED_DATA. В нашем случае мы допускаем сообщения с типом счетного сообщения или сообщения приветствия. Где и как мы генерируем тип будет видно дальше по тексту в классе MyEncoder в методе decode мы мы непосредственно декодируем полученные в наше управление данные. извлекаем тип и по типу восстанавливаем POJO объекты, причем мы видим, что если сначала мы смотрели как бы нам хватило 4 байт чтобы узнать тип, то тепеь в каждой ветке условия мы проверяем свой индивидуальный размер, для CountMessage это 8 ибо 2 int столько весят, с сообщением сложнее, я пока не знаю как декодировать строку, поэтому сделал ее фиксированной длинны, 5 потому что "hello" в UTF-8 весит столько, но "Привет" весит 12. С декодированием (самой сложной частью) разобрались, теперь беремся за клиента
Тоже стандартная конструкция, которую я выдрал из мана. Здесь опять пишем
Абсолютно ничего не поменялось по сравнению с сервером, разве что только мы создаем кодировщик из высокоуровневых сообщений в низкоуровневые. Собственно и всё, здесь не предусмотренно никаких входных данных, поэтому мы с чистой совестью можем создать просто demux обработчик, не связывая в нем никаких обработчиков
Теперь MyEncoder
Тут интересность состоит в private static final Set<Class<?>> TYPES. В этой коллекции содержатся все типы классов (не знаю как это правильно сказать), которые подлежат обработке именно этим обработчиком. encode просто делает свое дело, нам надо просто диффиринцировать мух от котлет, чем мы и занимаемся, проверяя тип объекта. Далее мы видим, то что упоминалось ранее: тип мы записываем 1-м в сообщении, затем все данные по очереди, при чем ОБЯЗАТЕЛЬНО в том порядке в котором они будут считываться, или если по-русски, то наоборот. Осталась самая простая мелочь, которую мы не рассмотрели на сервере - это обработчики высокоуровневых сообщений.
и
Как мы видим, тут все просто. Мы принимаем высокоуровневое сообщение и делаем с ним что захотим с приятной возможностью отписывать в session прямо тут же. |
Автор: batigoal 17.10.2007, 11:57 |
Однозначно в FAQ. |
Автор: Platon 17.10.2007, 12:34 |
Спасибо за отзыв. Я просто не могу понять, почему по MINA на этом форуме только 1 захудалая темка? Неужели людям приятней копошиться с NIO, и делать инвалидные приложения? Тут, конечно 2 вопроса остаются: 1. У меня логгеры так и не работают, выдают варнинги. 2. Как предложите по уму передавать строки? Простой вариант делать в начале метку длинны строки, но тоже неприятно. |
Автор: COVD 17.10.2007, 16:27 | ||
А что, многие копошатся с НИО? Я думаю MINA относится к специфическим разделам серверного программирования, поэтому и не обсуждается широко. НИО все еще относительно новая технология и относительно низкого уровня. Реализация http серверов на nio как раз сейчас происходит. А большинство программистов осваивают готовые решения J2EE. Так сказать, согласно лозунгам, быстро и на высоком профессиональном уровне удовлетворяют потребности индустрии. Кроме того, понять и оценить то, что они там в MINA (COMET еще есть на апаче, тоже интересная штука) сваяли, можно только попробовав своими руками. Наверняка много чего другого в интернете (благодаря вашей ссылке я вышел на FIX , но некогда разбираться). Приходится делать "инвалидную", но работающую программу, а потом уже с пониманием дела находить и адаптировать готовое решение. Вы сделали полезное начинание и надеюсь продолжите делиться своим опытом. Все же основную концепцию тоже неплохо было бы осветить на пальцах для ликбеза, но понятно, это требует времени. Реплика относительно обработчика низкоуровневых сообщений (другое не смотрел). Как я понял, если в буфере не хватает данных для восстановления сообщения, то возвращается код NEED_DATA. А надо бы данные из буфера забрать. Буфер имеет фиксированную длину. Если длина сообщения превышает длину буфера, то вы никогда не прочитаете это сообщение. А если будете забирать сколько есть, так и размер буфера не будет важен. Вообще непонятно, зачем какой-то код возвращать надо. Забрали из своего буфера все что есть и спасибо. |
Автор: Platon 17.10.2007, 17:12 |
COVD, по реплике кину реплику. На самом деле я с прицелом отметил, что ByteBuffer не NIO а MINA, т.е. он как раз и занимается забором всех принятых с сокета данных. Тем самым, MINA освобождает нас от такой работы, как создание механизма хранения принятых данных по сессиям. |
Автор: COVD 17.10.2007, 17:24 |
Замечательная услуга. А я купился на название ByteBuffer. Теперь разглядел, что пакет другой. |
Автор: Platon 17.10.2007, 17:26 |
А как осветить основы? Перевести стартовые туториалы с сайта MINA? |
Автор: COVD 17.10.2007, 18:36 | ||||
Наверное, я горячусь. Я бы сетевые игры тоже отнес к специфическим. А мэйнстрим - это все, что на application server крутится. HTML-XML туда сюда гоняется. Кстати, одна из вечных проблем - преодоление файерволов и прочего, так называемый http туннелинг. Понятно, что это не касается соединяющихся по http, потому он такой и популярный. Фактически, клиент всегда должен иметь в качестве запасного варианта возможность соединиться по http. Интересно, как эта проблема решается в MINA. Понятно, они там вроде пишут что любые протоколы. Но наверное это не делается автоматически? Интересовались ли вы этим вопросом? Добавлено через 9 минут и 13 секунд
А фиг его знает. Переводить не надо, а лучше своими словами. Я вот примерно имею представление, а пошел смотреть их презентацию по вашей ссылке и с ходу мало что понял. Картинки красивые. У всех ![]() |
Автор: Platon 17.10.2007, 19:39 |
Честно сказать, мое плотное знакомство с MINA длится ровно 2 дня *CONFUSED* (кстати почему нет этого смайлика?) До этого я только ходил вокруг и облизывался. Сам лично еще не одного проекта, даже учебного, не сделал. |
Автор: COVD 17.10.2007, 20:00 | ||
![]() |
Автор: Platon 18.10.2007, 00:31 |
Посмотрел про HTTP, мде, так просто то и не получится. |
Автор: goodday1941 11.11.2007, 23:44 |
очень интерестное апи! но тут возникли проблемки при тестировании. Как реализовать двустороннюю связь между клиентом и сервером? я то в принципе ее реализовал, но так получаеться что у меня юзается по два порта на клиенте и на сервере, один на прием второй на передачу (что не есть гуд, в случае работы с сокетами обходился одним портом с каждой стороны)... так вот как организовать работу с помощью одного порта с каждой стороны (с какого порта принимаю на тот и отправляю)? |
Автор: goodday1941 13.11.2007, 18:24 |
я так понял никто с этим вопросом не разбирался :( ладно буду сам копать, результаты раскопок выложу когда чего-то накопаю ![]() |
Автор: goodday1941 14.11.2007, 16:05 | ||||||||||||||
И так, представляю вашему вниманию весьма бесполезную программу, которая делает следующее: 1. Клиент соединяется с сервером. 2. Клиент отправляет 1000 объектов серверу. Сервер, в свою очередь, приняв объект, отсылает всем существующим соединениям данный объект. 3. Клиент разрывает соединение. Для всего этого понадобиться три библиотеки: mina-core-1.1.4.jar (собственно сам http://mina.apache.org/), slf4j-api-1.4.3.jar, slf4j-simple-1.4.3.jar(библиотеки которые нужны для работы логгера в MINA http://www.slf4j.org/). И так, собственно, сам сервера Server.java:
Слушатель сессии на сервере ServerHandler.java:
Теперь клиентская часть Client.java:
Далее, вспомогательный класс, в который вынесено соединение с сервером, отправка сообщений и разрыв соединения с сервером ClientSupport.java:
И слушатель сессии на клиенте ClientHandler.java:
Тестовый обьект TestObject.java:
Вроде как не сложно для понимания разобраться в том, что делает код. Что бы нормально протестировать, предлагаю вам после запуска сервера, запустить клиента который просто соединяется с сервером, для этого закомментируйте строки
в классе Client.java, далее запускаете второго клиента уже с раскомментированым кодом в Client.java. Наблюдаем, что выдает логгер в стектрейс. В общем, подключив фантазию можно получить что-то похожее на JMS (:. PS. Все написанное основывается на примере с сайта MINA http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/chat/ |
Автор: Platon 15.11.2007, 12:27 |
Честно сказать не понял к чему это? |
Автор: goodday1941 15.11.2007, 18:17 |
а чего тут не понятного.. начну с истоков... в общем в проекте над которым сейчас работаю система передачи сообщений между клиентами и сервером реализована на сокетах, что временами глючит... собсно недавно задался решить эту проблемку, а тут как раз твои размышления над MINE случайно увидел... но твой пример мне явно не подходил, так как у тебя реализована передача только в одну сторону (а такое меня явно не устраивает, да и вообще вряд ли кого то устроит), а так же в реальных приложениях обычно нужно передавать обьекты... задал вопрос по этому поводу, на который никто не ответил, в результате сам раскопал пример, и на его основе сделал свой пример, при этом попытался его максимально упростить, что бы было ясно что к чему... вроде все ![]() |
Автор: Platon 16.11.2007, 13:02 |
Кстати, раньше я не задавался этим вопросом, но после того, как моя статья - теперь достояние общественности, почему она лежит не в факах "сети", а в "общих вопросах"? |