Создание движка сервера (L2)

[n3k0nation]

ATracer, собственно нетти, как ни крути не подходит, как и мина - в мине проблемы в буферах, у нетти собственно в производительности.

Если уже говорим про модульность и абстрактность, то было бы хорошо разделить проект на несколько модулей (предположительно: сеть, работа с базой, геймплей, "игра"), которые можно разделить еще на множества подмодулей, каждый основной модуль, можно связать с другим посредством рефлектион, что даст некоторую гибкость и возможность горячей замены, а для скорости можно использовать тот же фаст рефлектион. Хотя можно предположить и другой вариант - написание своего classloader'а, который будет отслеживать в изменения загруженных модулей/библиотек.

[ATracer]

c удовольствием почитал бы про сравнительную характеристику производимости netty с nio l2. Есть конкретные (даже микро) тесты? Планирую в будущем написать свой или может кто уже занимался?
а про модули "(предположительно: сеть, работа с базой, геймплей, "игра")" это и ежу понятно что не все в одном месте

[pitch]

Пишите в пм (icq || skype), можно попробовать объеденить усилия.

[DeForMator]

Напиши свою ICQ пожалуйста в ПМ.

[Aquanox]

Сообщение от ATracer

как вариант:

DI/AOP - guice,

почему бы не Spring использовать в качестве контейнера? Чего такого особенного ты в нем нашел.

Некоторое время работал с Guice 2.0, но всеже остался на Spring'e .

Модульность приложения можно поддерживать (на крайний случай) разделяя файл контекста на части соответствующие модулям.

Добавлено через 6 минут

Сообщение от ASevenfold

Хотя можно предположить и другой вариант - написание своего classloader'а, который будет отслеживать в изменения загруженных модулей/библиотек.

Зачем перезагружать такие большие объекты в рантайме? Для этого должны производится полные перезагрузки. По возможности необходимо максимально снизить количество контента который может быть перезагружен во время работы сервера. (Исключение - тестовые и dev-сборки, но ни в коем случае не production-версии)

Добавлено через 9 минут

Сообщение от ASevenfold

Если уже говорим про модульность и абстрактность, то было бы хорошо разделить проект на несколько модулей (предположительно: сеть, работа с базой, геймплей, "игра")

Network Layer
Database Layer
Game API
Extension/Module API

Весь игровой контент наращивать на API как это сделано на оригинале: в сервере только базовая логика и запуск игровых событий, вся остальная составляющая (воздействие с игровыми объектами) должно быть скриптовое.

[w4ter]

еще JMX для управления и мониторинга за серваком и JNI для подрубки нативки . Хех. Ну а серьёзно, Spring + JMX хорошо идут, и мемори лики отследишь, что людям Спринг не нравится - хз. Готов присоединиться, пишите в пм.

[pitch]

Если юзать спринг, то по большому счету 50% кода уже написано . Управление жизненным циклом проекта, инит и дестрой бинов, спринг дао (orm или jdbc), spring oxm (xstream или jaxb), RMI или JMS взаимодействие, WS и тп... Кароче не нужно заморачиваться с великами ). Вопрос в быстродействии. Насклько быстро спринг достанет bean из контекста, чем вызов MyClass.getInstance()

[w4ter]

Ну если в быстродействии, то гугл быстрее спринг.

#C Клиентов
S : Сервисные синглтоны
C : Вызов методаdoPerfom
I : Создание экземпляров класса
T : Среднее время закрепления структуры в бины (мс)
M : Время стартапа модуля (мс)

#C S C I T M
spring 1 y y 13 34 601
guice 1 y y 13 0 407
spring 10 y y 13 26 607
guice 10 y y 13 0 393
spring 100 y y 13 28 768
guice 100 y y 13 0 456
spring 1000 y y 13 53 1300
guice 1000 y y 13 0 492
spring 10000 y y 13 35 3910
guice 10000 y y 13 0 417

spring 1 y n 13 20 528
guice 1 y n 13 0 457
spring 10 y n 13 25 530
guice 10 y n 13 0 392
spring 100 y n 13 21 744
guice 100 y n 13 0 537
spring 1000 y n 13 34 1445
guice 1000 y n 13 0 591
spring 10000 y n 13 34 3819
guice 10000 y n 13 0 401

spring 1 n n 13 35 660
guice 1 n n 13 0 419
spring 10 n n 130 88 612
guice 10 n n 130 0 406
spring 100 n n 1300 221 708
guice 100 n n 1300 6 415
spring 1000 n n 13000 877 1243
guice 1000 n n 13000 55 386
spring 10000 n n 130000 3858 3765
guice 10000 n n 130000 202 400

spring 1 n y 13 31 567
guice 1 n y 13 0 393
spring 10 n y 130 67 564
guice 10 n y 130 1 407
spring 100 n y 1300 223 693
guice 100 n y 1300 7 435
spring 1000 n y 13000 957 1259
guice 1000 n y 13000 43 424
spring 10000 n y 130000 2931 3859
guice 10000 n y 130000 208 405

[Aquanox]

Сообщение от w4ter

еще JMX для управления и мониторинга за серваком и JNI для подрубки нативки . Хех. Ну а серьёзно, Spring + JMX хорошо идут, и мемори лики отследишь, что людям Спринг не нравится - хз. Готов присоединиться, пишите в пм.

Только jni здесь не хватало ... JNI это извращение.

Добавлено через 1 минуту

Сообщение от pitch

Если юзать спринг, то по большому счету 50% кода уже написано . Управление жизненным циклом проекта, инит и дестрой бинов, спринг дао (orm или jdbc), spring oxm (xstream или jaxb), RMI или JMS взаимодействие, WS и тп... Кароче не нужно заморачиваться с великами ). Вопрос в быстродействии. Насклько быстро спринг достанет bean из контекста, чем вызов MyClass.getInstance()

одноразово только при инициализация. если верно использовать DI, то вообще не прийдется обращаться к контексту.
Использовать контейнер намного безопаснее чем простые одиночки.

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

Сообщение от w4ter

Ну если в быстродействии, то гугл быстрее спринг.

#C Клиентов
S : Сервисные синглтоны
C : Вызов методаdoPerfom
I : Создание экземпляров класса
T : Среднее время закрепления структуры в бины (мс)
M : Время стартапа модуля (мс)

откуда данные? чем тестировалось

[pitch]

Сообщение от Aquanox

то вообще не прийдется обращаться к контексту.

всегда когда делаешь @Autowire или context.getBean() обращаешся к контексту приложения, чтобы выдернуть бин... Чтобы совсем не обращаться к контейнеру, так не бывает.