В общем, задали в универе написать некое подобие MMORPG. Мало того, что никто не имеет понятия, как вообще делаются онлайн игры, так и в жабке все профаны. Но не в этом дело. Преподы советуют использовать RMI. Отсюда возникает вопрос: оправдано ли это? Всегда считал, что RMI замена SOAP. Но на SOAP'е игровые серевера не пишут. Куча запросов к серверу приведет к порождению такой же кучи потоков, синхронизирация тяжелее, клиентов не поброадкастишь.
Хотелось бы услышать ваше мнение.


P.S. А если у кого-нить есть что-нибудь про программирование онлайн игр, то поделитесь ссылочкой. Буду премного благодарен.

Я думаю, что RMI тут вполне оправдан. 
1) Он простой. Его легко использовать.
2) В отличии от WebServices (SOAP) позволяет организовать callback.

Второе, ИМХО, это самое важное преимущество.

Добавлено через 48 секунд
самое важное для этой задачи...   

Присоединюсь к обсуждению.

А по тяжести? не слишком ли тяжело будет? если брать во внимание не университетский проект, а какой-нибудь средненький некоммерческий проект.

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

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

Где-то тут на форуме заметил фразу, что RMI-клиента можно сделать будет только на Java.


Это сообщение отредактировал(а) Platon - 24.5.2007, 15:57

есть мнение, что если RMI-IIOP сделать, то можно не только Java-вой подключаться, правда тут некоторые возможности RMI теряются... Но нужно ли подключать не java клиентов? ...
Вот еще в догонку сравнение CORBA и WS. Интересная статья.

Впрочем, вопрос организации серверов меня тоже весьма волнует. Мне тоже интересно знать, как лучше все это сделать. Такие характеристики как простота разработки/надежность/функциональность/производительность обычно уступают по показателям друг другу от технологии к технологии... и в этом наверное одна из главных проблем.

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

Звучит обнадеживающе, я рад, что еще не устарел.

Не почуствовал какой-то сложности при письме кода, может по неопытности, может по удачно найденному подходу, немного больше кода чем сериализация. Но зато душа радуется, от того, что все байты у тебя идут по делу, ты все контролируешь.

От нескольких игроков слышал, что порой они отказывались от игр из-за того что они слишком много кушают трафика, и готовы играть в игры попроще, но более экономные.

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

Преимущество сокетов состоит в скорости и маштабируемости. При спользовании RMI каждый раз идет создание нового коннекта, на каждый вызов создается свой поток, и объекты постоянно сериализуются. При работе в локальной сети с малым количеством клиентов, это не проблема, а вот для интернет сервера у которого тысячи клиентов - это уже проблематично.

Remote Method Invocation (RMI) - стандартная java-технология удаленных вызовов, нужные классы входят в JRE. RMI может работать поверх двух протоколов: JRMP (использовался раньше, по-моему, до версии 1.3 jdk) и IIOP. JRMP - чисто rmi-ный протокол, а вот IIOP - это протокол технологии CORBA.
RMI/JRMP  предлагает несколько довольно приятных фич, зато RMI/IIOP позволяет использовать для java-сервера в качестве клиента не только java-приложение.
Это, как говориться, For Your Information )

А что касается выбора протокола, то сначала стоит задуматься, каков будет сервер... BobiKK, ты планируешь самостоятельно писать сервер? Или, может, воспользоваться технологией J2EE и написать только серверные компоненты с использованием существующего контейнера? Что преподы хотят?

В любом случае, когда речь заходит о многопользовательском приложении в internet, стоит учитывать, что есть файерволы и пр. Лучше использовать стандартный http, он отлично будет ходить из корпоративных локалок со злобными админами )) Поверх http можешь пустить любой протокол, тот же rmi (хотя http-tunelling штука геморройная), но чаще всего это будет web-services из-за богатого набора уже написанных библиотек. К тому же, web-services поддерживают семантику  document style.

Мораль: если проект будет коммерческим, тут надо всерьез подумать ) А если это курсовая, то используй rmi. Почему rmi? Потому что из всех альтернатив ты затратишь минимум времени для написания максимально примитивного сервера, и останется больше времени попить пивка )))))

Добавлено через 2 минуты и 13 секунд

пишут. взять ту же Second Life.

Не совсем коммерческий, но расчитанный на серьезные цели.
Какие критерии стоит учесть?

     Выскажусь немного по поводу HTTP.
Как мне всегда казалось, протокол HTTP (HyperText Transport Protocol) изначально создавался для клиент-северных систем работающих по принципу клиент запросил - сервер дал. Т.е. клиенту нужна страница, он делает запрос с некими параметрами, а в ответ получает страницу, содержание которой, возможно, зависит от переданных параметров. Это все. Цель подобной системы - получение web-страниц о чем впрочем и говорит название протокола. ИМХО, не больше. HTTP-сервер не может быть инициатором передачи данных, он ведомый, он только отвечает. 

    А что нужно для игры? Или например для собственного чата или instance messaging-a?
Необходимо что бы данные отправлялись just in time (тогда, когда это действительно необходимо).  Клиенту есть что сказать серверу? Отлично, клиент отправляет серверу данные. Серверу есть что сказать клиенту? Великолепно, сервер отправляет клиенту данные. Никто никого не долбит запросами типа: "ну что, обновились данные?". Трафик экономится.

   Так что же позволяет нам WS построенные поверх HTTP? 
Только запросы клиента. По такому принципу прекрасно строится простой RPC - сделал вызов, получил ответ. Это значит, что бы клиенту вовремя получить изменённые данные нужно сервер постоянно опрашивать, а это просто мега нагрузка на сеть и на сервер.

   Как же быть?   
Выход очевиден: callback - клиент регистрируется на сервере и когда последнему необходимо, то он может начать взаимодействие с клиентом. Получается, что клиента (в том смысле, в каком говорилось ранее) по сути нет... есть 2 сервера. Но клиентский сервер достаточно лёгок по сравнению с общим для всех клиентов бизнес-сервером. 

[IMHO]
    По поводу HTTP-тунелинга.
... Насколько я понимаю http-тунелинг это маскирование одного протокола под http. Или, говоря проше, использование основного протокола поверх http. HTTP в данном случае как бы для транспорта идёт. Вот при таком раскладе, я одного не могу понять: зачем закрывать порты и использовать http-тунелинг? Ответ наверное будет таким: это обеспечение  безопасности. Возможно... но как по мне, использовать HyperText Transport Protocol (!) для организации RPC лишь только по тому, что некоторые админы закрываю порты - это извращение. ИМХО, это как надеть боксёрские перчатки и при этом жаловаться, что мол носки одевать не удобно. ... а ведь люди еще обходные пути придумывают, тунелинги всякие...
[/IMHO]

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

P.S.: Хотя я слышал, что если используя HTTP не закрывать соединение после пришедшего запроса, то так же можно организовать callback. Слышать я конечно слышал, но примеров не видел, тем более высокоуровневых библиотек позволяющих построить подобное взаимодействие. Еще видел пару статей об WS-callback, но насколько я понял, это просто возможность асинхронного вызова метода сервиса, а не регистрация клиента для длительного взаимодействия.

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

Вот и дилемма. Соединение в сторону клиента нельзя, сервер долбить запросами нельзя.... Как тогда быть?

P.S. Думаю, что клиент с сервером взаимодействуют при одном открытом соединении. Т.е. соединение открывается и не закрывает пока программа не завершится. При этом постоянная передача данных не идет, хотя обе стороны могут уведомлять друг друга от различных событиях. (Но я могу ошибаться).

Соединение в сторону клиента бывает просто невозможно создать. По причине, на которую указал выше ekr (корпоративные локалки и злобные админы). Остается "долбить" сервер http запросами. Но здесь есть некоторые возможности для маневра. 

Во-первых, периодически сервер и клиент должны обмениваться пингом (heartbeat, пульс) даже если им нечего друг другу сказать. Это единственный надежный способ проверить, что соединение с противоположной стороной не умерло. Разумеется, это актуально, если соединение рассматривается как постоянное, т.е. есть какие-то ресурсы, привязанные к соединению и которые желательно немедленно освободить в случае его разрыва.

Во-вторых, зависит от характера обмена. Если основной поток данных идет с сервера на клиент, то клиент посылает запрос "давай данные" и сервер посылает данные сколь угодно долго. Таким образом запрос на данные с сервера может происходить не часто. А вот на сервер так посылать данные не получается. Согласно http запрос post отправляется целиком, т.е. нельзя отсылать данные на сервер по мере необходимости в одном запросе. Это связано с тем, что сначала отправляется размер данных и потом уже сами данные. Стандартные http клиенты так и работают. Поэтому если клиент должен часто отправлять информацию на сервер, то каждая новая порция данных должна оформляться в виде нового запроса. Однако и это не так страшно, потому что физически соединение может быть использовано повторно, т.е. оно не обязательно всякий раз убивается, но это зависит от промежуточных серверов, через которые осуществляется соединение.

Стандартный подход, на мой взгляд, состоит в том, что приложение сначала пытается соединиться с сервером по tcp протоколу. В случае неудачи переходит на http (тунеллинг. Если интенсивность обмена мала, то для упрощения можно ограничиться только http). Такой же подход реализован в RMI. Казалось бы, это очень привлекательно, что транспортный слой RMI берет на себя все заботы. Однако, насколько я знаю, для этого надо предоставить сервлет и, соответственно, контейнер (Томсат), т.е. это не встроено в RMI. Поэтому у меня некоторые сомнения относительно удобства RMI в этом контексте и такого опыта нет.  



С серверами обычно никаких проблем не бывает, потому что можно поставить сервера и соединение нужной мощности. Проблемы с клиентами. Они все разные. Чем выше и изощренней требования к клиентской части, тем меньше клиентов. Шлифовать то, что облегчает жизнь клиентскому компьютеру, очень даже полезно. Большинство же технологий придуманы для ускорения девелопмента. И часто именно клиент расплачивается за это ресурсами своего компьютера. 


Это сообщение отредактировал(а) COVD - 29.5.2007, 20:12

Хотелось бы побольше об этом узнать, на сколько клиенту приходится расплачиваться?



Делал лабораторную работу по RMI, ничего лишнего не надо было.
Вот батник запуска сервера


Вот клиента:

Если у клиента медленная линия или ограничения по трафику, то наверное пересылка голых байтов предпочтительнее xml-файлов. Когда линия не справляется возникают паузы и обрывы связи.
Если у клиента недостаточно памяти или слишком много приложений запущено, то же самое. Претензии будут к провайдеру сервиса, которому деньги платятся.     

Модератор: Разделил тему на две. Про игру "девятку" создана новая тема здесь.