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

[w4ter]

http://rapidshare.com/files/411929654/Gu...arison.zip

Вот сравнение.

[Redvain]

Ребят, как на счёт вот такой основы сервера:
http://www.reddwarfserver.org/?q=content...g-universe
Это бывший DarkStar от Sun. Хз что из себя представляет, но на нём не маленький такой список серверов сделан был.

[Aquanox]

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

один раз при инициализации.

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


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

[Blakkky]

Да что ж вас так в ЕЕ-то тянет?
Еnterprise - это в первую очередь - скорость разработки в ущерб производительности / ресурсоемкости. За написание 30 строк кода + 3х XML-ек вместо 3000 строк кода расплачиваться придется произвобительностью. Много кто готов выделить 2 железяки с 8 ядрами и 16+Гб оперы, как под ПТС, чтоб переварить 200+ онлайна? Кому нужен будет такой сервер ла2?

Вот если это все не для ла2 делается, а для своей игрушки, тогда да, есть смысл.
Но фреймворк для создания игр на базе пачки фреймворков, спроектированных для ускарения разработки ПО - это пусть к кластерным серверам для небольшого онлайна.
Ну чего страшного в написании своего многопоточного NIO движка под сетевую? Да, на это нужно будет потратить неделю и еще неделю его погрузить, чтоб отладить производительность, зато из этого можно будет выжать максимум производительности при минимуме ресурсов. И так со всем.

[n3k0nation]

Blakkky, в большинстве правильно, но кто, например, захочет писать свой пул для базы данных (работа напрямую с java.sql & j driver)? Лучше использовать тот же orm hibernate, намного сократит время разработки, к тому же у программиста останется чуть больше нервов
Да и спринг вроде не настолько ресурсоемкий...

[ATracer]

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

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

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

Также находил несколько статей где скорость на базе netty лучше самодельных NIO. Я вообще netty не рассматриваю как жирный фреймворк - если посмотреть ядро то там та же пачка классов которую самому придется писать (хотя погонять в сравнении не мешало бы).

В целом соглашусь что в энетрпрайз залезать не надо. А вот использование DI фреймворка (с ограничениями на рантайм!) это все таки лучше чем классы-синглтоны по всему коду (хотя в принципе можно локатор шаблон в крайнем случае использовать). Также это позволит при разработке заменять имплементацию - например орм или ждбц.

кстати насчет перезагрузки модулей - очень большая вероятность что в итоге надо будет перезагрузить все приложение = рестарт

[n3k0nation]

кстати насчет перезагрузки модулей - очень большая вероятность что в итоге надо будет перезагрузить все приложение = рестарт

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

[pitch]

Че вы к скорости то цепляетесь:
По большому счету медленнее будет только инит сервака, тк спринг будет все бины заливать в контейнер.
Уверен, что орм покажет себя достойно, тк тут не нужны сложные объединеия таблиц, для постройки отчетов, а примитивные вещи (UPDATE,INSERT,DELETE) вполне подходят под ОРМ.
По поводу написания велосипеда, без привлечения фреймов - я против, железо сейчас не особо и дорогое, лишние 200 мб памяти которые возможно сожрут фреймы, в чем я сильно сомневаюсь особой роли не сыграют, на фоне всей картины. Уйдут зато (ламо-админы) которые ставят сборки на домашние компы, а те, кто ставит в ДЦ у них вполне подходящее железо.
ID или прямые вызовы, не думаю, что код будет настолько оптимизорован и идеален, что можно будет упереться в производительность reflection'a. Это не 1.4 ява где рефлекшен был много медленее, изспользуя cglib разницы особо не затемишь, уж игрок 100% наносекунды не обработает зрительно.

[Aquanox]

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

[VISTALL]

вкладу свои 5 копеёк ищо раз
1. Сетевая часть(apache mina не годится, netty негодится понял это ASevenfold), я писал свою сетеву NioAcceptor/NioConnector, + поддержка 1 и более NioProcessor которые разгребают конекты, доволи чисто написал, но пока не нашол хорошую идею как розписать работу с буфера(тоисть при чтении/писании), поетому и использую пока ММОГОРЕ. Прийдет время и выброшу xD
2. Почему Вы не довольны серваком л2? А. вам рук нехватает переписать? Ибо это ток слова xD. Реально никто не собирается... А вы скажете, сложно....Ну да есть немного... Я например полностью доволен своим серваком, кроме одной вещи, к которой я скоро прийду и перепишу xD. Это обмен база даных и сервак....(собираюсь и делаю на hibernate). Я например пришол к более ровном ДПаку, тоисть Дп в одной части у мну это XML...(а не SQL, cvs)
3. Ну и последнее, ну нафик фреймворкы что б скоротить 100 строк в 2 строчки, и добавить библиотеку в пару метров? Если Вы не уверены в своей "пряморукость", и хотите использовать чужие фреймворки...Это ваше дело...


Сейчас я пишу на коде L2Dream Open Source(!!!). Год работы, и я могу спокойно назвать то что у мну свой код....Я не прячусь то что я использую некоторые наработки тех же CCP/L2Phoenix/L2JServer....и так дальше, но не копипастю. И не собираюсь забивать голову дурными мыслями про переписать л2 сервака. Поетому лучше берите пишите. А не обговаривайте на форуме xD