если ради интереса(а я так не умею
) то erlang + расширения на С++, либо F# 
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > на чем писать игровой сервер? |
| Автор: GoldFinch 30.12.2009, 20:19 |
| Есть задача написать игровой сервер для MMORPG, например для lineage или WoW. Известно что оригинальные сервера написаны на С++ (там нативный win64 код), и поддерживают онлайн порядка нескольких тысяч клиентов, а опенсорсные эмуляторы на Java поддерживают онлайн порядка нескольких сотен клиентов. Почему так происходит - не знаю, однако это факт. Надо выбрать на каком языке писать сервер. Последние темы говорят что С++ плох, стар и т.п.. Во многом это так. на нем действительно неудобно писать, по сравнению с более высокоуровневыми языками. Мне в первую очередь хочется писать на более удобном языке. Но с удобными библиотеками, и в удобной ИДЕ, а не в блокноте с сырыми библиотеками как на D. С другой стороны, мне хочется в результате получить хорошую производительность сервера. Лучше чем у существующих опенсорсных серверов на Java, где на обычном ПК лагает при онлайне в 3 человека. Т.е. сервер не должен жрать х10 памяти по сравнению с С++, и не должен иметь заметно низкую производительность по сравнению с С++. Также, есть большая вероятность, что сервер будет запускаться на фряхе. Т.е. если писать на С#, то это моно, а не .NET 4.0, или может вайн (?). На каком именно языке писать - мне без разницы, проект делается для себя, время на изучение языка+его библиотек неограничено. Так что можете посоветовать, вместо старого недоброго С++ ? |
| Автор: Alexeis 30.12.2009, 20:31 |
| Язык не имеет такого уж значения, если времени есть много. Лучше писать на том что лучше знаешь. И лучше определиться с платформой. |
| Автор: GoldFinch 30.12.2009, 20:46 |
| Alexeis, кроме написания самой программы, я еще хочу изучить какой-нибудь хороший язык, на котором удобно писать. Сейчас я лучше всего знаю С++ и асм. С++ лучше, однако писать мне на нем не хочется, на асме тем более. Платформы - как минимум 2. Винда и никсы. Писать я буду под виндой, дебажить под виндой, а запускать может быть на фряхе. Даже если в обозримом будущем и не придется запускать сервер на никсах, такая возможность должна быть. |
| Автор: bilbobagginz 30.12.2009, 21:08 |
| GoldFinch, мне кажется тебе лучше сосредоточиться не на том на чем писать, а на том, чтобы понять сложность реализации, и что ограничивает производительность существующих систем. по-моему, соревноваться одному с командой программистов, которые получают з/п за это и кропотают над этим 20 часов в день - по меньшей мере неуважительно по отношению к этим программистам. во вторых, насколько я могу себе представить, коммерческие сервера не только разрабатываются, но и тестируются огромным количеством людей. в третьих, и на java и на PERL и на python и на ruby и на LISP можно написАть как руками с головой, так ногами с }|{**ой. |
| Автор: GoldFinch 30.12.2009, 21:41 |
| bilbobagginz, Сложность реализации - они всегда в том, что надо реализовывать. Насчет команд программистов с нереальным рабочим временем и з\п, толп тестировщиков и т.п. - мне на них всеравно. они пишут свой код - я свой. Ты можешь писать чем угодно, но если в языке типы данных требуют больше памяти чем похожие в нативном С++, и если они требуют больше операций для работы с ними - тебе не избежать оверхеда. |
| Автор: SoWa 30.12.2009, 21:55 |
| Ну вообще от игры надо отталкиваться. В основном все переезжает на C#, пишутся сокетные серверы. А если проект попроще- например на флеше клиент, то можно с сокетным сервером не заморачиваться, а написать на ПХП сервер, запустить под nginx или Апач и вуа-ля, все работает. Другое дело- грамотно написать этот самый сервер. А то на любом языке можно такой ###код родить, что будет на 10+ коннектах отваливаться. |
| Автор: Alexeis 30.12.2009, 22:08 |
| Есть понятие сложности алгоритма. В каждом языке есть эффективные и неэффективные конструкции. Узкие места всегда пишутся неэффективными конструкциями. Если это невозможно, то всегда можно написать маленькую библиотеку закрывающую узкое место. Тот же C# много использует WinApi в реализации своих классов + COM. Казалось бы COM старая неэффективная модель, но на ней работает DirectX, т.е. то что требует идеальной оптимизации. Сложная архитектура пишется в несколько уровней. Если ты хочешь закрывать эффективно самый низкий уровень, то без С/С++ будет сложно. Если нижний уровень уже закрыт кем-то, то язык уже не так важен. |
| Автор: Lazin 30.12.2009, 22:21 |
| если работать за зарплату, я бы выбрал С++ плюс boost.asio если ради интереса(а я так не умею ) то erlang + расширения на С++, либо F# |
| Автор: GoldFinch 30.12.2009, 23:52 |
| Lazin, не хочу функциональщину, хочу императивщину |
| Автор: LSD 31.12.2009, 11:40 |
| Вера ТС в "магические" свойста С++ (жрать в 10 раз меньше памяти, и обслуживать в тыщщу раз больше клиентов) забавляет. |
| Автор: Alexeis 31.12.2009, 12:07 |
LSD, ну вообще-то от языка таки зависит. Даже при удачной реализации можно потерять 50% производительности из-за языка  . Так что смысл есть, но не такой большой как кажется. |
| Автор: SoWa 31.12.2009, 12:21 |
| Индийский код- он и в России индийский... А от языка не думаю что зависит больше 2-3% разницы производительности. |
| Автор: Alexeis 31.12.2009, 12:37 | ||
Откуда такие данные? Сравнивали код, который генерит freePascal и MS VS 2005 при наилучшей оптимизации. Разница весьма существенная. Аналогично то что генерит JIT будет заметно тяжелее. Не забывай, что C# сует проверки данных на уровне инструкций. Такие вещи не сказываются на сложности алгоритма, но существенные потери дает. Вопрос в другом, как правило такие потери перекрывает типичный ###код, который тупо повышает сложность алгоритма. |
| Автор: Lazin 31.12.2009, 12:41 | ||
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all |
| Автор: LSD 31.12.2009, 12:46 | ||
Но не в данном случае. Все таки это не вычислительная задача, тут тебе и сеть и БД и кластеризация. Так что хорошая архитектура и реализации, значат на порядок больше чем "быстрый компилятор". |
| Автор: GoldFinch 31.12.2009, 13:35 |
| Я спрашиваю о выборе языка, а не о архитектуре. Или хотите сказать я на одном языке сделаю хорошую архитектуру, а на другом - плохую?) Разумеется производительность кода, который выполняется рядом с кодом ввода-вывода (сеть, БД) - не очень важна. Однако работа сервера состоит совсем не из копирования данных БД<->сокет. Это в основном расчет формул, поиск путей, и прочие вычислительные задачи. При этом медленная БД работает в фоновом режиме, и нужна в основном для сохранения снапшотов игрового мира каждые n секунд. А все вычисления проводятся кодом самого сервера над родными для языка массивами данных. И это никак не влияет на потребление памяти типами данных языка. |
| Автор: A5uKa 31.12.2009, 14:22 |
Nemerle+Mono  ну или квас (шарп) |
| Автор: GoldFinch 31.12.2009, 18:11 | ||
млин, как не смотри, а C++ лучше всех. плохой бенчмарк =\ Добавлено через 13 минут а вообще, если смотреть на диаграммы "объем кода vs время выполнения", F# неплох http://shootout.alioth.debian.org/u64q/code-used-time-used-shapes.php да синтаксис языка вроде нормальный, циклы там человеческие, операторных скобок нет, как в питоне |
| Автор: Temdegon 3.1.2010, 18:15 | ||
| Не знаю, где вы нашли "Факт", что java-серверы держат несколько сотен онлайн) Почитайте хотя бы на вики про java-серверы lineage
Лично играл 4 года назад на сервере http://la2.raid.ru со средним онлайном 2к игроков. Там есть технические характеристики сервера, и они совсем не заоблачные. А 4 года назад явно были в два раза слабее. Как я читал, java-сервер не многим хуже оригинального сервера по производительности, а местами даже наоборот. Так же, я постоянно запускал на своей машине (2ГБ DDR1 1.8Гц, одно ядро, WinXP) сервер и клиент и работало вполне адекватно, при том, что сам клиент жрет прилично, да еще и в фоне болтаются всякие эклипсы, винапы и т.п. Касательно самой платформы, очень желательно запускать сервер на серверной версии VM, а не на клиентской. По не проверенным мной данным, на нормальном linux сервере работать будет в разы лучше, чем на "домашней" винде. Ну и все-таки надо задуматься, а лучше спросить у разработчиков, какую VM выбрать и с какими опциями ее лучше запускать. В общем, мне кажется, что слухи о "тормознутости" java-эмуляторов распускают нубы, которым просто стрельнуло "хочу свой сервак, хочу косить бабло!". Они скачали неизвестно какую сборку и запустили ее на каком-нить гавняном VDS, особо не вникая в детали. А потом, когда их голубые мечты разбились о скалу суровой реальности, они заплакали и побежали засирать сервер на всевозможных форумах =) Сама задача мне кажется не реальной. Посмотрите тот же l2j, там только одних сырцов сервера - 1600 java-файлов. А еще ведь есть Login-сервер и datapack. |
| Автор: unicuum 3.1.2010, 20:42 | ||
То есть по твоему даже не стоит пытаться?  Лично я плевал на то, сколько и что пишут неизвестные мне люди создавая своё закрытое ПО. Пусть хоть всю жизнь горбатятся. Вообще полный лол, уважать кого-то там, за то что они работают за зарплату 20 часов в день (когда ж спят только). Из одного только "безграничного презрения" к ним я буду пытаться сделать лучше. |
| Автор: LSD 4.1.2010, 12:04 | ||
1. Уверен, что на Erlang ты сделаешь довольно кривую архитектуру. 2. Ты сам начал рассказывать байки, про то как одно наличие в проекте С++, позволяет серверу держать сто тыщь клиентов. |
| Автор: unicuum 4.1.2010, 12:58 |
| По поводу Java. Хотите писать ява сервера, так пожалуйста, жалко что ли. |
| Автор: Lazin 4.1.2010, 13:11 | ||
|
| Автор: Alexeis 4.1.2010, 13:20 | ||
Java веб ориентированный язык. Наверняка там нижний уровень закрыт оптимально до нельзя. Не стоит недооценивать оптимизированные фреймворки. |
| Автор: unicuum 4.1.2010, 13:29 | ||
Ну, а ты хочешь чтобы всё сразу, как по волшебству. Да даже те фирмы с капиталам, терпят неудачи раз за разом, пока у них не получается, или пока они не сдаются. |
| Автор: LSD 4.1.2010, 13:33 | ||
Ура!!! unicuum разрешил писать серврер на Java!!! Теперь у нас есть все что нужно для разработки!!! |
| Автор: unicuum 4.1.2010, 13:36 | ||
Я не решил, это тебе показалось. Если будут писать сервер, то использую что-то типа boost и т.п. Но зачем навязывать своё мнение? Если кто-то хочет писать на яве, пусть пишет. |
| Автор: LSD 4.1.2010, 13:48 | ||
Что ты не решил? Кто будут писать и причем тут то что будешь использовать ты?  |
| Автор: unicuum 4.1.2010, 14:04 | ||
Моя твоя не понимать. |
| Автор: serger 5.1.2010, 08:42 | ||||
Твоя читать невнимательно...
а не решил. |
| Автор: SHk 13.1.2010, 13:48 | ||
Erlang |
| Автор: Landing 15.1.2010, 09:04 |
| Вариантов вообще не много. Серьезных (по моему мнению) языков мало C++, C#, Java. Из них явно выделяется С++, как более низкоуровневый. Остальные 2 одного поля ягода. Выбирать практически не приходится. |
| Автор: serger 15.1.2010, 11:17 | ||
Ну дак чтож выбрать? |
| Автор: Landing 15.1.2010, 11:34 |
| serger, Если нужна аховская производительность, то C++. Нет, C# тоже может ее дать, но привязка к винде (вдруг захотите еще где-то сервер вертеть). Java, извините, отожрет всю память и не подавится. Работает у нас система документооборота на ней, плохих слов не хватает... |
| Автор: serger 15.1.2010, 14:28 | ||||
А чем она, принципиально от C# отличается?
Сказал "а" - говори "б". Или только из-за памяти недовольство? А что бы ты сам выбрал? |
| Автор: Lazin 15.1.2010, 14:32 | ||
|
| Автор: GoldFinch 15.1.2010, 16:46 |
| > Так что можете посоветовать, вместо старого недоброго С++ ? > ### Какбэ кроме названия ЯП хорошо бы писать почему именно этот ЯП а не другой. |
| Автор: unicuum 15.1.2010, 18:34 | ||
Причём здесь вера, я включаю Azureus и конец котёнку. Следующее приложение на Java глючить начинает.  |
| Автор: LSD 15.1.2010, 19:42 | ||
При том, что игровой сервер немного отличается от десктоп приложения. И 30-50 Мб накладных расходов на обслуживание JVM, для сервера обслуживающего тыщщу клиентов, погоды не сделают. |
| Автор: gcc 16.1.2010, 02:00 |
| 1) можно использовать собития ядра FreeBSD, механизм kqueue/kevent http://www.opennet.ru/base/dev/kevent_freebsd.txt.html вот видел интерфейс http://search.cpan.org/~msergeant/IO-KQueue-0.32/KQueue.pm 2) event loops. есть множество фреймворков для создания событийно-ориентированных приложений 3) AnyEvent |
| Автор: GoldFinch 16.1.2010, 14:01 |
| gcc, если С++, то сетевая часть будет на boost.asio, так что о kqueue vs порт_завершения_в_винде vs хзчто_в_линуксе говорить смысла нет |
| Автор: Lazin 16.1.2010, 14:55 |
| GoldFinch, если сервер будет работать на одной машине, если логика работы не сильно сложная(можно статически описать), то можно и на срр а вообще писать лучше на том, что лучше знаешь, если конечно не ставишь целью научиться использовать новый ЯП |
| Автор: Landing 18.1.2010, 12:27 | ||||||
Система объектно-ориентированная, с кучей наследования. Объектов создается немерянно. При этом очень медленно работает и ест память, да так что приходится, перезагружаться раз в сутки. Сервер стоит мощный, пользователей 500 чел. В онлайне до 200. Такой аптайм при таком количестве народу (действие которых сводится к загрузке документа несколько раз за рабочий день) нечто невообразимое. Любой совр. форум выдерживает гораздо большую нагрузку (php). Так что, я бы писал сервер на C#, чем вобщем-то и занимаюсь. Давно перешел на него и незнаю проблем. Для легких вещей python, т.к. позволяет писать со скоростью мысли. |
| Автор: GoldFinch 18.1.2010, 12:34 | ||
форуму не надо отсылать обновление данных каждому клиенту по несколько раз в секунду |
| Автор: LSD 18.1.2010, 13:04 | ||
И ты считаешь, что переписав это сервер на C# (полностью сохранив архитектуру) он по мановению волшебства БГ перестанет жрать память, начнет держать более 9000 клиентов и аптайм возрастет до 1000 лет, так? |
| Автор: Alexeis 18.1.2010, 13:58 | ||
Мож я чего не понял, но C# не фрагментирует кучу, поэтому производительность софта со временем падать не будет. |
| Автор: Lazin 18.1.2010, 14:26 | ||
С# не может не фрагментировать кучу не фрагментирует кучу сборщик мусора clr, да и любой современный сборщик мусора не будет фрагментировать кучу но даже если сборщика мусора нет, все равно можно написать так, что куча не будет фрагментироваться |
| Автор: Alexeis 18.1.2010, 15:30 | ||||
Сам себе противоречишь . С# не может фрагментировать кучу ввиду отсутствия таковой. Об том и речь. А стек дефрагментируется при очередном проходе.
Для этого нужно специально прилагать усилия. |
| Автор: Lazin 18.1.2010, 16:16 | ||||
вовсе нет, я просто хотел сказать, что отсутствие фрагментации - особенность современных сборщиков мусора, а вовсе не языка программирования C#
как это нет, тебе о чем нибудь говорит фраза managed heap?  |
| Автор: Alexeis 18.1.2010, 17:36 | ||
Я думал там стековая организация памяти. Не знал что есть еще дополнительная куча. Странно собственно от этого и уходили. |
| Автор: Lazin 18.1.2010, 17:50 | ||
там есть стек и есть куча(кстати, еще есть куча для больших объектов, которые нельзя перемещать во время сборки мусора), просто принцип работы этой кучи похож на стековый тем, что она делится на две части, занятую и свободную |
| Автор: Landing 19.1.2010, 12:34 | ||||
Рассылка происходит в момент прикрепления сканированного образа документа, примерно раз в 10 мин. А вообще, с форумами проблем не вижу, а с этой штукой ежедневно все на ушах. Отсюда и выводы. |
| Автор: Alexeis 19.1.2010, 13:00 | ||||
Я думал понятие куча определяет ее внутреннюю структуру в виде списков занятых и не занятых блоков. В дотнете стековая структура хранения, так что как-то странно звучит даже.
Про это в первый раз слышу. |
| Автор: Lazin 19.1.2010, 13:36 | ||
откуда ты это взял? http://msdn.microsoft.com/en-us/library/ms973837.aspx |
| Автор: Alexeis 19.1.2010, 14:51 | ||
Ну как, новые объекты выделяются всегда сдвигом указателя стека, поэтому не нужны списки блоков. Есть связи между объектами. При очередном проходе изолированные группы объектов уничтожаются, а связанные последовательно помещаются в стек уже долговременных объектов. Для выделения памяти не нужно искать свободный блок подходящего размера и добавлять в список занятых блоков, дробить блоки. По уничтожению не нужно добавлять память в список свободных блоков. Ну чистый стек, точнее группа стеков. |
| Автор: Lazin 19.1.2010, 15:25 |
| Alexeis, это называется managed heap |
| Автор: Alexeis 19.1.2010, 17:00 | ||
Ладно фик с названием, хотя для порядка можно было придумать название по круче . Где-то встречал в тырнете, что плюснутые поделки с автоматической памятью работают похуже. Ведь как в плюсах определить что группа объектов не связана ни чем и ее можно сносить? Ведь глобальные объекты сами по себе не связаны. Объекты в Dll также могут быть не связанными с объектами из главной программы. В таком случае как знать что можно удалять а что нет? Мне кажется, что для подобной реализации придется всюду использовать вместо объектов шаблоны типа auto_ptr, т.е. использование чужих библиотек будет ограниченно, ведь все что будет создано там не будет создано и использованием твоей библиотеки шаблонов. . Как по грибы, так сразу начнется глухой лес |
| Автор: serger 19.1.2010, 17:00 | ||||
Ну, наверное, надо хотя бы знать как всё устроено внутри, так сказать подноготную, а не сравнивать не сравнимые вещи. (в данном случае с форумом). Добавлено через 2 минуты и 38 секунд
Super-puper managed heap Ну да неудобно. Придётся или извращаться, или строго следовать соглашениям, балансировать, так сказать, на лезвии... |
