Есть задача написать игровой сервер для MMORPG, например для lineage или WoW.

Известно что оригинальные сервера написаны на С++ (там нативный win64 код), и поддерживают онлайн порядка нескольких тысяч клиентов, а опенсорсные эмуляторы на Java поддерживают онлайн порядка нескольких сотен клиентов. Почему так происходит - не знаю, однако это факт.

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

Мне в первую очередь хочется писать на более удобном языке. Но с удобными библиотеками, и в удобной ИДЕ, а не в блокноте с сырыми библиотеками как на D.

С другой стороны, мне хочется в результате получить хорошую производительность сервера. Лучше чем у существующих опенсорсных серверов на Java, где на обычном ПК лагает при онлайне в 3 человека. Т.е. сервер не должен жрать х10 памяти по сравнению с С++, и не должен иметь заметно низкую производительность по сравнению с С++.

Также, есть большая вероятность, что сервер будет запускаться на фряхе. Т.е. если писать на С#, то это моно, а не .NET 4.0, или может вайн (?).

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

Так что можете посоветовать, вместо старого недоброго С++ ?

  Язык не имеет такого уж значения, если времени есть много. Лучше писать на том что лучше знаешь. И лучше определиться с платформой.

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

Платформы - как минимум 2. Винда и никсы. Писать я буду под виндой, дебажить под виндой, а запускать может быть на фряхе. Даже если в обозримом будущем и не придется запускать сервер на никсах, такая возможность должна быть.

Это сообщение отредактировал(а) GoldFinch - 30.12.2009, 20:47

GoldFinch, мне кажется тебе лучше сосредоточиться не на том на чем писать, а на том, чтобы понять сложность реализации, и что ограничивает производительность существующих систем.
по-моему, соревноваться одному с командой программистов, которые получают з/п за это и кропотают над этим 20 часов в день - по меньшей мере неуважительно по отношению к этим программистам.
во вторых, насколько я могу себе представить, коммерческие сервера не только разрабатываются, но и тестируются огромным количеством людей. 
в третьих, и на java и на PERL и на python и на ruby и на LISP можно написАть как руками с головой, так ногами с }|{**ой.

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

Ну вообще от игры надо отталкиваться.
В основном все переезжает на C#, пишутся сокетные серверы.

А если проект попроще- например на флеше клиент, то можно с сокетным сервером не заморачиваться, а написать на ПХП сервер, запустить под nginx или Апач и вуа-ля, все работает.

Другое дело- грамотно написать этот самый сервер. А то на любом языке можно такой ###код родить, что будет на 10+ коннектах отваливаться.

  Есть понятие сложности алгоритма. В каждом языке есть эффективные и неэффективные конструкции. Узкие места всегда пишутся неэффективными конструкциями. Если это невозможно, то всегда можно написать маленькую библиотеку закрывающую узкое место. Тот же C# много использует WinApi в реализации своих классов + COM. Казалось бы COM старая неэффективная модель, но на ней работает DirectX, т.е. то что требует идеальной оптимизации. Сложная архитектура пишется в несколько уровней. 
  Если ты хочешь закрывать эффективно самый низкий уровень, то без С/С++ будет сложно. Если нижний уровень уже закрыт кем-то, то язык уже не так важен.

если работать за зарплату, я бы выбрал С++ плюс boost.asio
если ради интереса(а я так не умею  ) то erlang + расширения на С++, либо F#  

Lazin, не хочу функциональщину, хочу императивщину

Вера ТС в "магические" свойста С++ (жрать в 10 раз меньше памяти, и обслуживать в тыщщу раз больше клиентов) забавляет.

LSD, ну вообще-то от языка таки зависит. Даже при удачной реализации можно потерять 50% производительности из-за языка  . Так что смысл есть, но не такой большой как кажется.

Индийский код- он и в России индийский...
А от языка не думаю что зависит больше 2-3% разницы производительности.

  Откуда такие данные? Сравнивали код, который генерит freePascal и MS VS 2005 при наилучшей оптимизации. Разница весьма существенная. Аналогично то что генерит JIT будет заметно тяжелее. Не забывай, что C# сует проверки данных на уровне инструкций. Такие вещи не сказываются на сложности алгоритма, но существенные потери дает. 
  Вопрос в другом, как правило такие потери перекрывает типичный ###код, который тупо повышает сложность алгоритма.

я бы не был так категоричен
http://shootout.alioth.debian.org/u32/benc...ll&lang=all

Но не в данном случае. Все таки это не вычислительная задача, тут тебе и сеть и БД и кластеризация. Так что хорошая архитектура и реализации, значат на порядок больше чем "быстрый компилятор".

Я спрашиваю о выборе языка, а не о архитектуре.
Или хотите сказать я на одном языке сделаю хорошую архитектуру, а на другом - плохую?)

Разумеется производительность кода, который выполняется рядом с кодом ввода-вывода (сеть, БД) - не очень важна. Однако работа сервера состоит совсем не из копирования данных БД<->сокет. Это в основном расчет формул, поиск путей, и прочие вычислительные задачи. При этом медленная БД работает в фоновом режиме, и нужна в основном для сохранения снапшотов игрового мира каждые n секунд. А все вычисления проводятся кодом самого сервера над родными для языка массивами данных.
И это никак не влияет на потребление памяти типами данных языка.

Nemerle+Mono    ну или квас (шарп)

млин, как не смотри, а C++ лучше всех.
плохой бенчмарк =\

Добавлено через 13 минут
а вообще, если смотреть на диаграммы "объем кода vs время выполнения", F# неплох
http://shootout.alioth.debian.org/u64q/cod...used-shapes.php

да синтаксис языка вроде нормальный, циклы там человеческие, операторных скобок нет, как в питоне

Не знаю, где вы нашли "Факт", что 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.

То есть по твоему даже не стоит пытаться?  Лично я плевал на то, сколько и что пишут неизвестные мне люди создавая своё закрытое ПО. Пусть хоть всю жизнь горбатятся. Вообще полный лол, уважать кого-то там, за то что они работают за зарплату 20 часов в день (когда ж спят только).  

Из одного только "безграничного презрения" к ним я буду пытаться сделать лучше.  

1. Уверен, что на Erlang ты сделаешь довольно кривую архитектуру.
2. Ты сам начал рассказывать байки, про то как одно наличие в проекте С++, позволяет серверу держать сто тыщь клиентов.

По поводу Java. Хотите писать ява сервера, так пожалуйста, жалко что ли.

ключевое слово - пытаться  

  Java веб ориентированный язык. Наверняка там нижний уровень закрыт оптимально до нельзя. Не стоит недооценивать оптимизированные фреймворки. 

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

Ура!!! unicuum разрешил писать серврер на Java!!! Теперь у нас есть все что нужно для разработки!!!

Я не решил, это тебе показалось. Если будут писать сервер, то использую что-то типа boost и т.п. Но зачем навязывать своё мнение? Если кто-то хочет писать на яве, пусть пишет.

Что ты не решил? Кто будут писать и причем тут то что будешь использовать ты?  

Моя твоя не понимать.

Твоя читать невнимательно... 

а не решил.   

Erlang

Вариантов вообще не много. Серьезных (по моему мнению) языков мало C++, C#, Java. Из них явно выделяется С++, как более низкоуровневый. Остальные 2 одного поля ягода. Выбирать практически не приходится.

Ну дак чтож выбрать?

serger, Если нужна аховская производительность, то C++. Нет, C# тоже может ее дать, но привязка к винде (вдруг захотите еще где-то сервер вертеть). Java, извините, отожрет всю память и не подавится. Работает у нас система документооборота на ней, плохих слов не хватает...  

Это сообщение отредактировал(а) Landing - 15.1.2010, 12:40

А чем она, принципиально от C# отличается?


Сказал "а" - говори "б". Или только из-за памяти недовольство?

А что бы ты сам выбрал?

  

> Так что можете посоветовать, вместо старого недоброго С++ ?

> ###

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

Причём здесь вера, я включаю Azureus и конец котёнку. Следующее приложение на Java глючить начинает.  

При том, что игровой сервер немного отличается от десктоп приложения. И 30-50 Мб накладных расходов на обслуживание JVM, для сервера обслуживающего тыщщу клиентов, погоды не сделают.

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 

Это сообщение отредактировал(а) gcc - 16.1.2010, 14:29

gcc, если С++, то сетевая часть будет на boost.asio, так что о kqueue vs порт_завершения_в_винде vs хзчто_в_линуксе говорить смысла нет

GoldFinch, если сервер будет работать на одной машине, если логика работы не сильно сложная(можно статически описать), то можно и на срр
а вообще писать лучше на том, что лучше знаешь, если конечно не ставишь целью научиться использовать новый ЯП

Система объектно-ориентированная, с кучей наследования. Объектов создается немерянно. При этом очень медленно работает и ест память, да так что приходится, перезагружаться раз в сутки. Сервер стоит мощный, пользователей 500 чел. В онлайне до 200. Такой аптайм при таком количестве народу (действие которых сводится к загрузке документа несколько раз за рабочий день) нечто невообразимое.

Любой совр. форум выдерживает гораздо большую нагрузку (php).

Так что, я бы писал сервер на C#, чем вобщем-то и занимаюсь. Давно перешел на него и незнаю проблем. Для легких вещей python, т.к. позволяет писать со скоростью мысли.

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

И ты считаешь, что переписав это сервер на C# (полностью сохранив архитектуру) он по мановению волшебства БГ перестанет жрать память, начнет держать более 9000 клиентов и аптайм возрастет до 1000 лет, так?  

Мож я чего не понял, но C# не фрагментирует кучу, поэтому производительность софта со временем падать не будет.

С# не может не фрагментировать кучу
не фрагментирует кучу сборщик мусора clr, да и любой современный сборщик мусора не будет фрагментировать кучу
но даже если сборщика мусора нет, все равно можно написать так, что куча не будет фрагментироваться  

Сам себе противоречишь  . С# не может фрагментировать кучу ввиду отсутствия таковой. Об том и речь. А стек дефрагментируется при очередном проходе.


Для этого нужно специально прилагать усилия.

вовсе нет, я просто хотел сказать, что отсутствие фрагментации - особенность современных сборщиков мусора, а вовсе не языка программирования C#


как это нет, тебе о чем нибудь говорит фраза managed heap?  

  Я думал там стековая организация памяти. Не знал что есть еще дополнительная куча. Странно собственно от этого и уходили.

там есть стек и есть куча(кстати, еще есть куча для больших объектов, которые нельзя перемещать во время сборки мусора), просто принцип работы этой кучи похож на стековый тем, что она делится на две части, занятую и свободную

Рассылка происходит в момент прикрепления сканированного образа документа, примерно раз в 10 мин. 

А вообще, с форумами проблем не вижу, а с этой штукой ежедневно все на ушах. Отсюда и выводы.

  Я думал понятие куча определяет ее внутреннюю структуру в виде списков занятых и не занятых блоков. В дотнете стековая структура хранения, так что как-то странно звучит даже. 


Про это в первый раз слышу. 

откуда ты это взял?

http://msdn.microsoft.com/en-us/library/ms973837.aspx

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

Alexeis, это называется managed heap

Ладно фик с названием, хотя для порядка можно было придумать название по круче   . Где-то встречал в тырнете, что плюснутые поделки с автоматической памятью работают похуже. Ведь как в плюсах определить что группа объектов не связана ни чем и ее можно сносить? Ведь глобальные объекты сами по себе не связаны. Объекты в Dll также могут быть не связанными с объектами из главной программы. В таком случае как знать что можно удалять а что нет? 
  Мне кажется, что для подобной реализации придется всюду использовать вместо объектов шаблоны типа auto_ptr, т.е. использование чужих библиотек будет ограниченно, ведь все что будет создано там не будет создано и использованием твоей библиотеки шаблонов.  . Как по грибы, так сразу начнется глухой лес   

Ну, наверное, надо хотя бы знать как всё устроено внутри, так сказать подноготную, а не сравнивать не сравнимые вещи. (в данном случае с форумом).

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

Super-puper managed heap   
Ну да неудобно. Придётся или извращаться, или строго следовать соглашениям, балансировать, так сказать, на лезвии...