В общем, нужно написать сервер, который принимает и обрабатывает запросы от клиента и отсылает результаты обратно. Протокол - собственный.

Какие паттерны для реализаций такого сервера существуют. Возможно какие-то шаблоны для протокола есть?

Пересмотрел несколько вариантов, но уж больно они не серьезные и без описания основных идей.

Буду очень благодарен, если кто-ндь раскроет тему.

Обязательно свой multithreading server?

А что вы можете предложить?  
RMI?

Из КВНа: 
- Ну, так как клеили? в стык или в нахлест?
- В стык. В нахлест от лукавого.

Alexandr87, Нееее, RMI от лукавого.
есть voodoo решение Apache MINA

Platon, 
Спасибо. На первый взгляд ничешный фрейморк. Попробую.

Apache MINA - пользовал год назад, вполне устроил... голосую ЗА!
Кстати, в него сейчас по моему AsyncWeb  влили (Реализация http-сервера поверх MINA).

Кто еще что предложит ?..

AndrewV, меня интересует, AsyncWeb позволяет сохранять сессию, создавать иллюзию постояного соединения, при типе соединения keep-alive = false?

Почему?

Потому, что при передаче данных используется сериализация.

А вы знаете другой способ передачи объектов?

Нууу, не знаю как вы это расцените, но подозреваю, что плохо. Просто свой протокол передачи. В факах пока стоит последней моя статья, там описано, как я работаю с сетью 

Хорошо. Чем свой протокол будет отличаться от сериализации объектов? 

Так, вы как Сократ? Хотите вопросами довести меня до своей истины?
К примеру у меня String из 5 символов в серализуемом виде составит более 30 байтов, не спорю, что при строке в 100килов 30 лишних байтов и не ощутятся, но согласитесь, что в чатах средняя длинна сообщения редко вылазит за 100 символов.
На самом деле редкое общение между компьютерами имеет сложную схему.

Добавлено через 1 минуту и 38 секунд
Хотя, ради справедливости, должен заметить, что в этих делах я слабо компетентен.

Ага. Заодно проверить - не упустил ли я чего 


Давайте посчитаем. Строка из пяти символов - как минимум 2 байта на сигнатуру, 10 байт на символы, 4 байта на их количество. Теперь имя класса - 32 байта на имя класса, 4 байта на его длину. Немного экономим на том, что символы передаются в кодировке utf-8. Итого, строка из пяти символов уместится в 36 байт (с учётом того, что строка состоит из русских символов, а имя класса содержит только латинские). 

Допустим, здесь есть ещё над чем поработать - например, передавать вместо имён классов код для некоторого перечня известных нам финальных классов. Сэкономим по десятку-другому байтов на пакет. Что получим в итоге - скорость? Нет, от этого лишнего десятка байт мало что изменится. Зато потеряем совместимость со стандартным механизмом и время (потребное на написание альтернативы). Увеличим объём кода, наплодим ошибок. 

Так стоит оно того? Тем более, что всего лишь реализовав в DTO интерфейс Externalizable все нежелательные огрехи (вроде записи полного имени класса для стандартных финальных объектов) можно поправить, не отказываясь от готового механизма. Который, кстати, ещё и SSL поддерживает :whistle:

Какие ещё кто припомнит нехорошие черты RMI?

Это сообщение отредактировал(а) w1nd - 3.1.2008, 01:55

Ууух не к добру этот спор ^_^

Предвкушаю, что вы скажете по поводу того, что RMI чисто для Java приложений, вы скажете, что на других языках есть библиотеки по работе с RMI... так что этого я говорить не буду.
Я бесспорно согласен, когда сеть локальная и необходима кластеризация, думаю, разговора нет, RMI упростит задачу, но люди, у многих траффик на пересчет, не оценят такой политики.

На самом деле, с вами спорить страшно, но спрошу одно: почему же многие программисты отвергают услуги Редакторов форм, ведь это так удобно! Наверно, потому, что им комфортно контролировать весь процесс, то, что получится на выходе, и наверно, не надо зависеть от конкретного редактора.
И мы помним правило, что универсальность всегда идет в минус оптимальности.
Скажем так: в случае с Apache MINA: если мне нужна сериализация, я ее могу получить, и также я могу писать свой протокол, если мне нужен SSL я его подключаю, если мне нужен другой метод кодирования, я его подключаю, если мне надо ужать данные, я подключа. фильтр сжатия, и всё это может быть в бесконечной цепочке фильтров, но в случае с RMI я уже не могу спуститься до уровня своего протокола, не могу регулировать степень защищенности и прочих настроек, которые зашила в себе технология RMI.

Да ничего не скажу. Не-java приложения меня не интересуют  Если заинтересуют - сделаю внешний мост.


Из-за 2-5% выигрыша? 


Я вам не скажу за всю Одессу, сами понимаете. Скажу только за себя и известных мне коллег - всё не так, как вы расписали. Редактор форм я не использую по иным причинам - они создают отвратительный, неподдерживаемый код и не могут утилизировать все возможности swing-компонент. Вот и всё. Зависимость от конкретного редактора мне совершенно не страшна, равно как и мнимое "отсутствие контроля" 


Ничего не имею против. Хотите свой протокол (вместо RMI) - реализуйте. Я не имею целью обсудить, какие средства предоставляет RMI, для того чтобы получить в результате совсем иной протокол. Я не пойму, чем повинен RMI?

А чё, обычные сервисы не подойдут?

ну, на самом деле я думаю тут пахнет в побольше процентами (конечно ничем не подкрепленно).

Спасибо вам за то, что вы постоянно разрушаете закоренелые стереотипы. Но, я, пока, останусь при своем выборе.

Добавлено через 14 минут и 38 секунд

Не спорю, что это изречение голословно, но все же народ к RMI так относится 

Это сообщение отредактировал(а) Platon - 3.1.2008, 10:32

Подвожу свои итоги: для соединения клиент сервер однозначно использую Apache MINA, для внутреннего взаимодействия серверных машин между собой, конечно неплохо использовать RMI

Строить обмен между компьютерами на сериализованных обьектах удобно, если ассортимент обьектов велик, а интенсивность обмена невысока. Если ассортимент узок, но высокая интенсивность, то становится выгоден свой протокол. Например, 10 сообщений, но каждое передается по несколько миллионов за день. Каждому клиенту. Тогда экономия нескольких байтов имеет смысл. 

Оффтоп: RMI был задуман как технология, максимально упрощающая сетевое программирование. Программисту не требуется знать слова "сокет". Однако в свое время мне было проще разобраться с сокетами. Возможно по этой причине я и не использовал RMI. 



В нетбинсе вполне нормально получается. А все возможности свинга трудно знать, если сталкиваться с ним эпизодически.

Это сообщение отредактировал(а) COVD - 3.1.2008, 22:24

Чего-то набрел я на эту уже старую тему и вспомнилось мне. Потому не спора ради, а просто так.



RMI (Remote Method Invocation) - это имитация вызова метода. "Дай обьект". И этот обьект возвращается одним куском. Даже если обьект - коллекция. Очевидно, сначала вся коллекция формируется на передающей стороне (размещается в памяти), потом вся коллекция пересылается спрашивающему (размещается в памяти) и только после этого спрашивающий получает ссылку на готовый обьект. 

Совершенно по-другому работает ResultSet, который можно было бы назвать RI , т.е. Remote Iterator.  Там элементы коллекции становятся доступны на приемной стороне по мере их готовности. Нет необходимости размещать в памяти всю коллекцию.

Сделать коммуникацию "a la ResultSet" можно и в RMI, но, на мой взгляд, ненатурально получится. Но далеко не везде эти нюансы актуальны.  

У меня сомнения относительно коммуникации "a la ResultSet" вообще. Что это за вид коммуникаций такой? При использовании RMI передаётся не куча объектов одним куском и не куски объекта. Передаётся всё любое - как/что напишете, так/то и будет. Хотите передавать коллекцию целиком - пожалста. Хотите удалённый итератор (или тот же ResultSet) - пожалста. Где "особенности" коммуникации, в упор не вижу.

Это сообщение отредактировал(а) w1nd - 18.8.2008, 14:47

И как это будет выглядеть на RMI? Наверное, надо реализовать метод next(). При каждом к нему обращении будет посылаться запрос на удаленный компьютер, который в ответ вернет очередную порцию данных (строку из таблицы). Это я и назвал "a la ResultSet". Или есть другой способ? 

P.S. Вот поиск дал org.apache.jackrabbit.rmi.remote.RemoteIterator - апачевская пристройка "to control the amount of buffering used to increase performance". Наверное, в сановском RMI этого нет.  


Это сообщение отредактировал(а) COVD - 21.8.2008, 17:56

Вообще-то "a la ResultSet" - это блоками, а не штуками. Но вы описали что-то похожее на правду; так где же "особенности"?



А что, этого нельзя реализовать? Почему это вдруг должно быть в RMI, тогда уж стоит искать что-то вроде RMIJDBC. Хинт: эта фишка тем или иным образом реализована в любом сервере приложений, где есть EJB.

"штуками" - выдает потребителю (как честный итератор), а подгружаются данные - "блоками".  JDBC использует буферизацию, а в классическом RMI ей вроде и нет места. В этом и различие. Очевидно, поэтому и вынуждены создавать конструкции вокруг RMI, когда хотят приблизиться к JDBC по эффективности пересылки коллекций.



Реализуют, как видим, на основе RMI. Потому, что RMI - это "наше все" и не нужно лезть в сокеты? Но "фишка", реализующая обмен данными между компьютерами с буферизацией ( подобно JDBC ) на основе RMI - это уже не RMI в чистом виде, про который пишут в учебниках.  Это "фишка", которую возможно проще и эффективнее было бы делать на сокетах, если бы не необходимость соблюдать стандарты J2EE. Это мое предположение.   

RMI вообще не реализует передачи коллекций или чего-нибудь ещё. RMI предоставляет механизм, на базе которого можно реализовать и что-то "a la ResultSet", и что-то более тупое, для передачи коллекции целиком. 


Не "не нужно лезть в сокеты", а "нет смысла лезть в сокеты". Я вот всех тут третирую, пытаясь понять, где же причины, которые могут побудить отказаться от rmi для внутренних коммуникация и лезть в сокеты. Эффективность? Нет, пока не было примеров. 

И невозможно (некорректно) сравнивать RMI с JDBC, потому что это технологии разных порядков. Более подходящее сравнение - RMI и сокеты. И RMI в "чистом виде" не бывает в принципе, RMI - это база для реализации своей какой-то логики.

Это сообщение отредактировал(а) w1nd - 22.8.2008, 19:33

для внутренних коммуникаций, пожалуй, это хороший вариант. Как раз предстоит подобное, и в срочном порядке собираюсь освежить память по RMI

Я имею в виду коммуникации java <-> java. Для всех прочих использование rmi представляется несколько... затруднительным 

а в чем особенность внутренних коммуникаций? Наверное, решающее здесь - однородность софтвера ( все на java ).



Я тоже пытаюсь понять, что мне мешало использовать RMI. И прихожу к выводу, что, возможно,  это "человеческий" фактор. Мне RMI не представлялся технологией одного уровня с сокетами. Скорее, наоборот, как готовое решение. Ведь RMI предлагает общаться с удаленным компьютером так-же, как и с локальными обьектами. Уж куда проще - все для удобства программиста. Вызов метода, типичная схема запрос-ответ. Но как только что-то не устраивает, то почему-то первая мысль - начать строить на сокетах, а не использовать в качестве кирпичиков RMI, как это сделали в том же jackrabbit, создав целую собственную библиотеку на его основе. Наверное, это действительно вопрос владения той или иной технологией.  

кхе, я вообще-то, под словами внутренние коммуникации подразумевал кое-что другое, т.е. несколько машин объединены в высокоскоростную (локальную) сеть.

я так и предполагал . Но даже xml гоняют через интернет, и все вроде прекрасно. Наверное, тут надо еще учитывать интенсивность потока данных. 

Ага и гуманность разработчиков.