Comments 19
Планируется статья с HelloWorld?
В следующей статье я напишу как написать свое первое приложение под RedDwarf. В заключении
>> Правда, на практике бывали случаи, когда падение сервера было вызвано лавинообразным размножением задач
Ощущение, что оракловскую esb писали те же люди, которые приложили руку к персистансу тут ><
По теме: интересно, жду HelloWorld.
Ощущение, что оракловскую esb писали те же люди, которые приложили руку к персистансу тут ><
По теме: интересно, жду HelloWorld.
> все игровые объекты должны реализовывать интерфейс ManagedObject
> Ссылка на такой объект должна храниться не в явном виде, а внутри специального объекта – ManagedReference
Ааа!!! Sun прекрати разрабатывать прикладные фреймфорки. Больше не надо. Хватит. Просто остановись. Вы отлично делаете виртуальные машины, оси и процессоры, занимайтесь ими, пажалуйста!
> Ссылка на такой объект должна храниться не в явном виде, а внутри специального объекта – ManagedReference
Ааа!!! Sun прекрати разрабатывать прикладные фреймфорки. Больше не надо. Хватит. Просто остановись. Вы отлично делаете виртуальные машины, оси и процессоры, занимайтесь ими, пажалуйста!
Ура! Я только подумал о разборе Java на предмет написания сервера для игры и тут такая информация. Большое спасибо. Теперь голосую за следующую статью.
UFO just landed and posted this here
> Реализация каналов такова, что этот механизм работает значительно быстрее нежели обход всех подписчиков в цикле и отсылка сообщения каждому из них.
это что за реализация такая? :)
это что за реализация такая? :)
Отсылка сообщений через каналы реализована на более низком уровне, чем это доступно через API. Если делать массовые рассылки стандартным механизмом — это просто повлечет большие накладные расходы на загрузку и блокировку объектов и т.д. Строго говоря, такая реализация каналов решает лишь проблемы, созданные самой архитектурой RedDwarf.
А, теперь понятно. А то сложилось впечатление, что там какая-то магия.
Наткнулся сегодня на статью с описанием техники, о которой подумал, когда прочитал Вашу заметку о быстрых очередях с множеством подписчиков. Дублирую сюда, мало ли, вдруг Вам тоже интересно будет: evgeny-lazin.blogspot.com/2011/10/disruptor.html
И еще я про базу+100мс ограничение+отсутствие синхронизаций не очень понял: получается, все сохраняемое между запросами состояние хранится в базе? Каждый удар мечом по противнику = апдейт в эту базу?
Да, более того, один удар мечом по противнику = много апдейтов, несколько новых транзакций (в том числе для внутренних событий, связанных с постановкой задач в очередь и рассылку ответных сообщений). Но база данных встроенная (по сути — это просто хранилище key-value), и достаточно шустрая, чтобы этого не замечать.
Гы. Интересно. Практически 10 лет занимаюсь разработкой игровых серверов на Java, а об этом проекте не слышал. Насколько я понял, вся платформа крутится вокруг персистентной Software Transactional Memory. Причем реализует она ее не в лучшей форме — через искусственные объекты и ManagedReference. Другие фреймворки (напр. Multiverse) прозрачно используют для этого bytecode enhancing. Все остальное — плюшки типа коннекшнов и каналов, которые без реализуются отденьго. Реальная инфраструктура игрового сервера несколько сложнее, чем предоставляет эта платформа. По моему опыту наиболее подходящей для игрового сервера является модель акторов, а использование STM здесь мне кажется лишним.
О проекте DarkStar хорошо написано в книге Идеальная архитекрута
Читаю и понимаю, что это не применимо к сколько-нибудь большому онлайн-проекту… Сериализовать задачи и потом вытаскивать их из базы и выполнять? У меня на сервере при 200 игроках на карте находится 5000 предметов и 7000 животных (не считая всего остального), это уже 12200 задач, которые должны выполняться 20 раз в секунду, т.е. 244 тысячи транзакций в секунду… Да ни одна база этого не выдержит.
А вы на каком-то реальном проекте его используете или чисто в академических целях посмотрели?
Sign up to leave a comment.
RedDwarf — cерверная платформа для разработки онлайн-игр на Java