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

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

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

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

Обязательно свой 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.