Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 206
21 человек добавили в избранное. 0 прокомментировали.
Давайте уже обсуждать? )
Давайте уже обсуждать? )
solver, у тебя Game Logic 1 и Game Logic 2 это отдельные потоки? А не пробовал выносить это в отдельные приложения(и обмениваться пакетами так-же как и с клиентом), чтобы можно было растащить сервер на несколько машин и повысить стабильность?
а будет продолжение с «БД и прочими вещами»? :)
Будет. Я там пишу цикл статей по созданию сетевой игры на флеше.
А это в виде отступления, по просьбам трудящихся, описал архитектуру рабочего проекта.
Так что потом будет и про остальное.
А это в виде отступления, по просьбам трудящихся, описал архитектуру рабочего проекта.
Так что потом будет и про остальное.
О! Мне скоро самому предстоит делать нечто похожее, но я почему то собирался реализовывать это все на Node.JS. Как думаете это плохая идея?
Технологии сами по себе редко бывают плохими или хорошими. Бывает лишь плохое или хорошее их применение.
С Node.JS я не работал, поэтому не могу сравнивать его с Java.
Но если он перекрывает все что вам необходимо для создания проекта и его развития, то почему бы и нет.
С Node.JS я не работал, поэтому не могу сравнивать его с Java.
Но если он перекрывает все что вам необходимо для создания проекта и его развития, то почему бы и нет.
да, все это можно сделать, зачастую гораздо приятнее и с меньшим кодом
Как раз недавно делал сравнение: devnest.blogspot.com/2012/01/nodejs-vs-netty.html
А по-хорошему с нодом вряд ли получиться срезать некоторые углы, которые можно срезать с нетти.
А по-хорошему с нодом вряд ли получиться срезать некоторые углы, которые можно срезать с нетти.
Первый коммент по ссылке позабавил =)
40 %? Да Вы шутите. Спасибо. Попробую сам теперь сравнить.
В данный момент я пишу небольшую мультиплеерную игру на Node.JS + Socket.IO В принципе, все не так уж и сложно. Пришлось правда пойти на небольшие хитрости. Как оказалось, что самая затратная операция по CPU в моем приложении это запись и чтения из сокета. По бенчмаркам я одним процессом node.js мог добиться около 2-3k rps на вход и 15k rps на выход (особенности моего приложения, что на одно сообщение на вход приходится около 5-10 сообщений на выход). Мне этой производительности было недостаточно. Решил изменить архитектуру сделав выполнение приложения в несколько процессов (остановился на 4-ех): 1 процесс, который отвечает за логику игры, и 3 процесса, которые отвечают за сетевые подключения. В итоге на синтетическом тесте получил такие цифры — 12k клиентов, которые создавали 12k запросов в секунду, и получали 120k событий в секунду. Пока этой цифры мне стало достаточно.
Делал я это все относительно давно, вроде как еще до версии Node.JS 0.6. Надо сейчас будет попробовать протестировать это же приложение, использую нативный модуль cluster, который позволяет делить между процессами сетевые подключение.
Ну и так же в версии 0.7 Node.JS были анонсированы isolates — что-то вроде тредов у которых нет общей памяти.
Делал я это все относительно давно, вроде как еще до версии Node.JS 0.6. Надо сейчас будет попробовать протестировать это же приложение, использую нативный модуль cluster, который позволяет делить между процессами сетевые подключение.
Ну и так же в версии 0.7 Node.JS были анонсированы isolates — что-то вроде тредов у которых нет общей памяти.
а что-нибудь про mina можете сказать, в сравнение?:)
1. Статья не является пособием по программированию. Это всего лишь пример как может быть. В джаве есть GC.
2. Не вижу проблемы. Люди подключаются, отключаются… все нормально.
3. Это вообще очень странный вопрос. Вы всерьез считаете, что 1 поток в состоянии обслужить несколько (десятков?) тысяч подключенных клиентов?
2. Не вижу проблемы. Люди подключаются, отключаются… все нормально.
3. Это вообще очень странный вопрос. Вы всерьез считаете, что 1 поток в состоянии обслужить несколько (десятков?) тысяч подключенных клиентов?
А какие вы предлагаете альтернативы, собсно?
Вы критикуете проблему, но не предлагаете решений.
Я использую похожую архитектуру в своём сервере. Сервер высылает сотни тысяч подобных пакетов клиентам (самый маленький пакет весит 2 байта) в секунду. Справляется отлично. GC не занимается долго такими мелкими объектами, его активность на весь сервер меньше 1% CPU.
Сервер работает сутками, ничего не накапливается нигде.
Сервер работает сутками, ничего не накапливается нигде.
я попробую O:-)
andybel просто ни разу не жабщик и местный бомонд не понимает его претензий
а претензии в том, что за удобство ООП приходится платить доп накладные расходы
java или с++, в целом пох:
«пришел» пакет, создается экземпляр класса пакет, при это выделяется память, в выделенную память копируется или парсится по полям инфа пришедшего пакета и того 2 лишних действия (которые не заметны, потому что выполняются системой, подальше от глаз программиста). После того как пакет обработан, память освобождается (деструктор у с++, 3-е лишнее действие) или ждет пока ее освободит GC (разбухание программы в памяти, особенно когда пакетов приходит ОЧЕНЬ много и ОЧЕНЬ быстро и GC начинает паниковать)
чистый с:
как правило у нас есть некий буфер, который мы один раз инициализировали, и просто, каждый новый прибывший пакет попадает в него, при это память не выделяется:
andybel просто ни разу не жабщик и местный бомонд не понимает его претензий
а претензии в том, что за удобство ООП приходится платить доп накладные расходы
java или с++, в целом пох:
«пришел» пакет, создается экземпляр класса пакет, при это выделяется память, в выделенную память копируется или парсится по полям инфа пришедшего пакета и того 2 лишних действия (которые не заметны, потому что выполняются системой, подальше от глаз программиста). После того как пакет обработан, память освобождается (деструктор у с++, 3-е лишнее действие) или ждет пока ее освободит GC (разбухание программы в памяти, особенно когда пакетов приходит ОЧЕНЬ много и ОЧЕНЬ быстро и GC начинает паниковать)
чистый с:
как правило у нас есть некий буфер, который мы один раз инициализировали, и просто, каждый новый прибывший пакет попадает в него, при это память не выделяется:
while (....) {
u_char buf[1024];
recv(fd, buf, size)
...
}
далее, в пакете есть полезная нагрузка, некие поля, которые нужно рапарсить и что-то в зависимости от их содержиого сделать.
typedef struct {
int len;
char field1;
char field2;
int filed3;
} packet;
packet *p = (packet *)buf;
swith(p->filed1) {
....
все.. вот он, пример особой уличной магии простой работы с указателями.
Мы получаем доступ куда хотим, без копирования и выделения памяти каждый раз, на каждый пришедший пакет. Оверхед сведен к миниму, на огромном кол-ве конектов приведенный код будет справлятся лутше, будет использовать меньше памяти и тд.
И да, треды нафиг не нужны, мультиплексирование справляется с нагрузками на ура. Это я понял, когда во времена 486 процессоров увидел, как фтп сервер спокойно держал и обслуживал ~10к пользователей одновременно.
Автор молодец, читать мне было интересно. Для флеш игрушки самое оно. Но если вы хотите hi-load, вам нужно общаться с компютером ЕГО сущностями, абстракции и прочие человекообразный объекты сдесь только мешает.1,2. Можете руками его убивать если вам так жалко напрягать GC )
3. Походу вы просто не понимаете как оно все работает. Никто не создает поток на каждого из 20к клиентов. Почитайте теорию про многопоточность, многое прояснится.
И откуда вы взяли 4 потока нетти? Я в конфиге нетти могу 10 задать.
3. Походу вы просто не понимаете как оно все работает. Никто не создает поток на каждого из 20к клиентов. Почитайте теорию про многопоточность, многое прояснится.
И откуда вы взяли 4 потока нетти? Я в конфиге нетти могу 10 задать.
Если честно, даже не знаю что сказать… почитайте теорию по всем пунктам.
1. Вы серьезно? Если не создавать объект то что делать? Напишите, мы все поучимся…
2. Сервер работает сутками, потребляемая память меняется, как ей и положено.
3. Вы вообще знаете что такое ThreadPool ?? Вы походу вообще не понимаете о чем говорите.
Про 4 потока в нетти вам уже несколько раз сказали, что вы ерунду говорите.
1. Вы серьезно? Если не создавать объект то что делать? Напишите, мы все поучимся…
2. Сервер работает сутками, потребляемая память меняется, как ей и положено.
3. Вы вообще знаете что такое ThreadPool ?? Вы походу вообще не понимаете о чем говорите.
Про 4 потока в нетти вам уже несколько раз сказали, что вы ерунду говорите.
Не обращайте внимание, этот andybel троллит во многих топиках, неся откровенный бред.
Вполне возможно, что вы никем не понятый гений, и то, что всем кажется ахинеей, на самом деле гениальные идеи. В таком случае я бы на вашем месте не заморачивался вентилляторами, а работал бы над гениальным проектом по преобразованию мира. Задумайтесь.
То есть, по-вашему, «жители Хабра» обязаны отвечать на ваши вопросы, даже если считают их ахинеей? Интересная мысль.
Значит, все «жители Хабра» неправы по отношению к вам и вашим вопросам, а вы один прав. Возможность обратного, как я понимаю, даже не обсуждается? ))
Значит, все «жители Хабра» неправы по отношению к вам и вашим вопросам, а вы один прав. Возможность обратного, как я понимаю, даже не обсуждается? ))
Несостыковка: выше вы пишете «спрашивал по делу», теперь «имею наглость задавать глупые вопросы». Так вы по делу спрашиваете или ахинею?
Ну слава богу, достигли консенсуса. На этой весёлой ноте закончим оффтопить. )))
я бы с радостью вам помог и минуснул бы вас, но увы… )))
andybel, зачем спорить с вебдевелоперами?
Для них и такая производительность покажется невероятным достижением. Хотя я бы назвал эту статью так: «Как нагрузить 16 логических процессоров, получив производительность однотредового решения» :)
А отвратительные решения у жавистов в плане конкарренси/параллелизма из-за ущербности литературы(сейчас точно не знаю, перечитывал 2 года назад). Они почему-то не могут читать книжки где встречаются интересные слова и нет рядом слова жава.
Для них и такая производительность покажется невероятным достижением. Хотя я бы назвал эту статью так: «Как нагрузить 16 логических процессоров, получив производительность однотредового решения» :)
А отвратительные решения у жавистов в плане конкарренси/параллелизма из-за ущербности литературы(сейчас точно не знаю, перечитывал 2 года назад). Они почему-то не могут читать книжки где встречаются интересные слова и нет рядом слова жава.
А уж как они потом долго будут отлавливать баги с nondetermenism'ом и писать тонны кода чтобы обойти эти проблемы. Есть же ярчайшие примеры этих фэйлов при разработке игровых серверов, а люди всё продолжают идти по тем же граблям, да ещё и учить других )
То есть Ваше решение — перейти на другую технологию? Я правильно Вас понял?
моё решение — ни в коем случае не использовать то что нарисовано здесь для разработки _игрового_ сервера картинка из поста
Да и нетти можно не использовать, не понимаю зачем нужна ещё какая-то абстракция для работы с сокетами, всё ведь итак просто.
Да и нетти можно не использовать, не понимаю зачем нужна ещё какая-то абстракция для работы с сокетами, всё ведь итак просто.
Я частично с Вами согласен. А можно увидеть Ваше решение?
Решение точно такое же как и при разработке обычных игр, ничем не отличается. В геймдеве уже много мозгочасов убили на тему паралелизма игровой логики. Это очень сложная проблема, и то что тут предлагается с разбиванием мессэджей на задачки, которые исполняются в тпэкзекьюторе породит лишь большой геморрой из-за непредсказуемости и громадный оверхед на локи повсюду, что в итоге однотред будет работать гораздо эффективнее.
А вообще отличный пример фэйла по распараллеливанию сервера был ещё давно с днс сервером bind9, они даже публиковали отчёт по тому как всё так печально получилось.
А вообще отличный пример фэйла по распараллеливанию сервера был ещё давно с днс сервером bind9, они даже публиковали отчёт по тому как всё так печально получилось.
Не согласен с тем, что single thread приложение всегда будет быстрее. В общем виде, быстрее будет то приложение, количество потоков которого равно количеству отданных ему ядер. Большее количество потоков приводит к потере на switch context. Но, писать логику удобнее, когда много потоков, потому и имеем, что имеем.
Хватит уже показывать какой вы умный, не приведя ни одного реального примера.
Утрите мне нос, покажите как делают реальные джедаи.
Утрите мне нос, покажите как делают реальные джедаи.
Э. Вы это серьезно? Т.е. сможете показать однотредовое решение которое дает на одном нетбуке 20к сообщений в сек, а на нормальном сервере более 150к сообщений?
Если вы не приведете пруф, то будем считать, что вы врун и пернули в лужу…
Если вы не приведете пруф, то будем считать, что вы врун и пернули в лужу…
Возьмём даже больше, однотредовое решение, которое не тупо гоняет сообщения, а ещё и делает полезную работу. И о чудо, перед нами открываются тысячи обычных серверов вроде redis'а итд.
Но в статье то вы учите писать _игровые_ сервера, и смею предположить что вы не участвовали в разработке ниодного высокопроизводительного _игрового_ сервера, где игровая логика была посложнее чем многопользовательская ферма.
Но в статье то вы учите писать _игровые_ сервера, и смею предположить что вы не участвовали в разработке ниодного высокопроизводительного _игрового_ сервера, где игровая логика была посложнее чем многопользовательская ферма.
Да вы что… вот оно в чем дело, ведь в статье-то я написал, что это архитектура самых крутейших серверов на свете… а оно вона как…
У вас случайно нет мании величия? Даже если в ваших словах есть хоть капля истины (в чем я сильно сомневаюсь т.к. кроме понтов ничего еще не видел). В сатье написано, что это всего лишь один из вариантов как сделать сервер.
Который не является самым крутым на свете.
А вы вместо того чтобы пальцы гнуть, лучше каписали бы как делают крутые перцы… а то походу вы кроме распальцовок ничего не умете…
У вас случайно нет мании величия? Даже если в ваших словах есть хоть капля истины (в чем я сильно сомневаюсь т.к. кроме понтов ничего еще не видел). В сатье написано, что это всего лишь один из вариантов как сделать сервер.
Который не является самым крутым на свете.
А вы вместо того чтобы пальцы гнуть, лучше каписали бы как делают крутые перцы… а то походу вы кроме распальцовок ничего не умете…
Ну покажите же нам это чудо. Покажите нам однотредовое приложение на чудо языке, которое 150к сообщений в секунду гоняет при этом еще выполняя полезную работу.
Или опять одни понты?
Или опять одни понты?
а вдруг вынет из широких штанин и покажет? ))) я тут попкорном запасся, жду.
Да самому интересно… всегда прикалывало как такие выскочки накидают понтов и в кусты ))
Memcached/Redis benchmark
Ну и можете дальше сами гуглить по этой теме, мне как бы это не особо интересно. Это же у вас только начался путь к разработке _производительных_ игровых серверов, и при этом вы уже учите как же их нужно делать )
И до вас видимо совсем никак не доходит разница между прокидыванием сообщений и разработкой _игрового_ сервера. Всё самое сложное ещё будет впереди, и если работу с сетью элементарно параллельно выполнять(хотя особого выхлопа не будет, а будет повышение лэйтэнси), то со всем остальным будет очень и очень сложно.
Ну и можете дальше сами гуглить по этой теме, мне как бы это не особо интересно. Это же у вас только начался путь к разработке _производительных_ игровых серверов, и при этом вы уже учите как же их нужно делать )
И до вас видимо совсем никак не доходит разница между прокидыванием сообщений и разработкой _игрового_ сервера. Всё самое сложное ещё будет впереди, и если работу с сетью элементарно параллельно выполнять(хотя особого выхлопа не будет, а будет повышение лэйтэнси), то со всем остальным будет очень и очень сложно.
И что это показывает? Что ваш редис может столько же переварить запросов сколько сервер на джаве…
Вы не увиливаейте, пернули в лужу, так будьте добры показать как на редисе сделать игровой реалтайм сервер.
Вы не увиливаейте, пернули в лужу, так будьте добры показать как на редисе сделать игровой реалтайм сервер.
Читать видимо совсем не умеем, а можем лишь смотреть на циферки. Если постараться вникнуть в суть той статьи, а потом попробовать применить мозг, то можно понять что выхлоп от разработки редиса как многотред не стоит того. А разработка игрового сервера гораздо сложнее чем какая-то средненькая БД вроде редиса, на этом моменте советую попробовать задуматься.
А с масштабированием игровых серверов всё просто — нужно напрягать геймдизайнера чтоб он придумал какой-нибудь портал для перехода между мирами или то как сделано в Eve, чтобы можно было легко перебрасывать клиентов на другие шарды. В гамасутре вроде даже была статья про это. Обычно всё равно всё упирается в недостаток контента и тупо рубят онлайн по N людей на шард.
И вы всё пытаетесь найти бенчи против ваших выдуманых циферок? Ох уж эти 150к риквестов на хз каком железе. Ну на хз другом железе однотред на Си выдавал 100к транзакций в бд :) Если для крутых жава кодеров это что-то может значить, например что жава быстра, ну пусть будет так, не буду переубеждать :)
А с масштабированием игровых серверов всё просто — нужно напрягать геймдизайнера чтоб он придумал какой-нибудь портал для перехода между мирами или то как сделано в Eve, чтобы можно было легко перебрасывать клиентов на другие шарды. В гамасутре вроде даже была статья про это. Обычно всё равно всё упирается в недостаток контента и тупо рубят онлайн по N людей на шард.
И вы всё пытаетесь найти бенчи против ваших выдуманых циферок? Ох уж эти 150к риквестов на хз каком железе. Ну на хз другом железе однотред на Си выдавал 100к транзакций в бд :) Если для крутых жава кодеров это что-то может значить, например что жава быстра, ну пусть будет так, не буду переубеждать :)
Может хватит сравнивать хрен с пальцем?
Зачем мне ваши транзакции в БД?
Приведите пример сетевой части для игрового сервера на другом языке с другой архитектурой, расскажите как надо делать. Я и другие хабравчане вам большое спасибо скажем.
А если лично вам показать нечего, и вы только пальцы гнуть горазды, то покиньте пожалуйста мою статью.
P.S. Мои цифры не выдуманы, это тесты сервера на Java находящиеся в открытом доступе.
Зачем мне ваши транзакции в БД?
Приведите пример сетевой части для игрового сервера на другом языке с другой архитектурой, расскажите как надо делать. Я и другие хабравчане вам большое спасибо скажем.
А если лично вам показать нечего, и вы только пальцы гнуть горазды, то покиньте пожалуйста мою статью.
P.S. Мои цифры не выдуманы, это тесты сервера на Java находящиеся в открытом доступе.
Делайте всё в одном треде. Или это для вас будет слишком просто? Недостаточно производительно для ваших ядер :)
Зачем делать все в одном треде, если один тред дает например 10к сообщений, а 3 треда 30к сообщений???
Ну вот нахрена это? Я понимаю, что есть ситуации которые распараллелить если и можно, то очень сложно. Но это далеко не всегда так. Абсолютно все делают игровые сервера многотредовыми, я просто ни разу в инете не встречал примеров многопользовательских игровых серверов с одним тредом. Вы сами то хоть один сделали?
И не надо приводить тут базы данных… хорошо?
Ну вот нахрена это? Я понимаю, что есть ситуации которые распараллелить если и можно, то очень сложно. Но это далеко не всегда так. Абсолютно все делают игровые сервера многотредовыми, я просто ни разу в инете не встречал примеров многопользовательских игровых серверов с одним тредом. Вы сами то хоть один сделали?
И не надо приводить тут базы данных… хорошо?
>я просто ни разу в инете не встречал примеров многопользовательских игровых серверов с одним тредом
eAthena
RunUO
Там конечно больше одного треда, но используются они совсем иначе :) Например в рануо есть тред для таймеров — полный вынос мозга :), там какое-то пародие на Timer Wheel внутри крутится. Ещё в ранке треды используют во время сохранения данных на диск. В eAthena всё акуратнее, сразу чувствуется рука японцев :)
>Вы сами то хоть один сделали?
принимал участие.
eAthena
RunUO
Там конечно больше одного треда, но используются они совсем иначе :) Например в рануо есть тред для таймеров — полный вынос мозга :), там какое-то пародие на Timer Wheel внутри крутится. Ещё в ранке треды используют во время сохранения данных на диск. В eAthena всё акуратнее, сразу чувствуется рука японцев :)
>Вы сами то хоть один сделали?
принимал участие.
>Но эти жители Хабра не отвечают на вопросы.
Это мне одному показалось, что вы не стремитесь получить ответы на свои якобы вопросы? Да и о теме имеете настолько смутное представление, что кажется, что никакого. Очевидно, это именно тот случай, когда тратить время на ответы нет смысла. Вы их не понимаете.
Это мне одному показалось, что вы не стремитесь получить ответы на свои якобы вопросы? Да и о теме имеете настолько смутное представление, что кажется, что никакого. Очевидно, это именно тот случай, когда тратить время на ответы нет смысла. Вы их не понимаете.
Да именно так и есть. Вы не понимаете что такое ThreadPool, не удосужились заглянуть в доки и посмотреть. Поэтому объяснять очевидные истины никому неохота. Тем более человеку который ничего не хочет делать, а только тыкает всех носом, да еще неправильно тыкает. Понимаете? Вы пишете очевидную ерунду. Поэтому вам и не разжевывают. Вели бы себя как нормальный человек, возможно кто-то потратил бы минутку чтобы разжевать вам.
Полез в профиль минус поставить, а там уже красная стрелочка. :)
~9 месяцев аптайма (правда вместо нетти — мина), от 1к юзеров на сервере, от 50к дейли актив юзерс, сотни тысяч минорных сборок мусора, и десяток полноценных.
Кушает много цп? Если на графике можно было увидеть более 3-х процентов cpu-тайма это была пичалька. Много памяти? 4 гигабайта иногда кушало да. Нагибает бд? Какое из 8 приложений которое стучится на тот же сервер в соседний инстанс постгреса?
Кушает много цп? Если на графике можно было увидеть более 3-х процентов cpu-тайма это была пичалька. Много памяти? 4 гигабайта иногда кушало да. Нагибает бд? Какое из 8 приложений которое стучится на тот же сервер в соседний инстанс постгреса?
Это пять!!!
Написать программу не используя ни одного new это надо быть как минимум гением ))
Написать программу не используя ни одного new это надо быть как минимум гением ))
Ох тыж смешной. По твоему если я перестану создавать объекты, что в яве практически ничего не стоящая операция, по сравнению с некоторыми другими, а уж тем более по сравнению с достаточно жирной бизнес логикой в некоторых местах… у нас от этого 450к юзеров подвалит, и будет каждый день заходить в нашу чудную игру?
Второй абзац ты наверное даже и не читал, там кратко описано на фоне чего это 50к получаются.
Ах да, кстати, с людьми, которые пишут сервера на плюсах, долгое время сидел в одной комнате. Так что отлично представляю что и как там у них, и на сколько (нинасколько вообще после трех минут работы сервера) ява медленнее чем те же си.
Второй абзац ты наверное даже и не читал, там кратко описано на фоне чего это 50к получаются.
Ах да, кстати, с людьми, которые пишут сервера на плюсах, долгое время сидел в одной комнате. Так что отлично представляю что и как там у них, и на сколько (нинасколько вообще после трех минут работы сервера) ява медленнее чем те же си.
Вот теперь понятно почему такие вопросы… у вас 10лет С++, джаву вы не знаете совсем, вот и странно для вас то, что для других очевидно.
Но в любом случае эта статья не топик обучения языку.
Да и манеру общаться надо менять… с такими амбициями у вас все всегда плохие будут…
Но в любом случае эта статья не топик обучения языку.
Да и манеру общаться надо менять… с такими амбициями у вас все всегда плохие будут…
К сожалению, не могу оценить ваше достижение, банально не знаю ничего о RTOS-32. Но по опыту могу сказать, что 1мс это не так уж и мало.
А что касается умником и общения с ними — может следует научиться общаться с людьми и тогда не придется ждать по часу что бы кому-нибудь ответить?
А что касается умником и общения с ними — может следует научиться общаться с людьми и тогда не придется ждать по часу что бы кому-нибудь ответить?
Ну как вы не понимаете, это же не разумно, статья учит использовать труъ решение, с помощью которого можно нагрузить все логические процессоры по максимуму, только так можно получить производительный сервер :) Ведь параллелизм — это так легко, вот так взял тредпул и всё стало работать быстрее ) Или ещё и scheduled executor'ы для таймаутов (о да, я видел такое убожество в реальном ммо сервере).
Вы бредите…
«один поток вполне может обслужить несколько десятков тысяч подключённых клиентов»
Вы с этим согласны.
Но когда я в своей статье привожу пример когда запускается 2-3-4 таких потока параллельно, у вас случается приступ…
Не находите противоречия?
Если железа много и оно позволяет запустить 2-3-4 потока параллельно, то почему этого не сделать? Ведь все равно 1 поток не нагрузит весь процессор, каким бы крутым язык программирования не был.
Что именно у вас вызывает такую бурю эмоций?
«один поток вполне может обслужить несколько десятков тысяч подключённых клиентов»
Вы с этим согласны.
Но когда я в своей статье привожу пример когда запускается 2-3-4 таких потока параллельно, у вас случается приступ…
Не находите противоречия?
Если железа много и оно позволяет запустить 2-3-4 потока параллельно, то почему этого не сделать? Ведь все равно 1 поток не нагрузит весь процессор, каким бы крутым язык программирования не был.
Что именно у вас вызывает такую бурю эмоций?
>Вы с этим согласны.
Не согласен.
Клиенты и сервера бывают разные :)
Например сервер может делать какую-то особую магию для обработки запросов от клиентов и обрабатывать 1000 запросов в секунду, при этом его будет чертовски сложно распараллелить. И попытки распараллелить начнут давать какой-то прирост только где-нибудь с 16 ядер (сможет обработать 1200 запросов) и при этом ещё случится какая-нибудь беда в виде увеличения лэйтэнси :)
Как вам такая ситуация? )
>Что именно у вас вызывает такую бурю эмоций?
Повторение истории о крутых жава пацанах, способных распараллелить всё и вся, в книжках же написано что для этого нужно просто воткнуть побольше tpexecutor'ов :)
Ну не сможете вы распараллелить игровую логику так чтобы это было эффективнее однотреда, неужели не очевидно? Ну вот честно, громадное кол-во студентов пыталось взяться за подобное, вон даже упомянутый в комментах труп ммо фрэймворка от сановцев пытались сделать подобное. Если они ещё не поубивали свои обсуждения, то там можно прочитать очень много интересных вещей, которые никогда бы не пригодились, еслиб они понимали что реально нужно от игровых серверов )
Не согласен.
Клиенты и сервера бывают разные :)
Например сервер может делать какую-то особую магию для обработки запросов от клиентов и обрабатывать 1000 запросов в секунду, при этом его будет чертовски сложно распараллелить. И попытки распараллелить начнут давать какой-то прирост только где-нибудь с 16 ядер (сможет обработать 1200 запросов) и при этом ещё случится какая-нибудь беда в виде увеличения лэйтэнси :)
Как вам такая ситуация? )
>Что именно у вас вызывает такую бурю эмоций?
Повторение истории о крутых жава пацанах, способных распараллелить всё и вся, в книжках же написано что для этого нужно просто воткнуть побольше tpexecutor'ов :)
Ну не сможете вы распараллелить игровую логику так чтобы это было эффективнее однотреда, неужели не очевидно? Ну вот честно, громадное кол-во студентов пыталось взяться за подобное, вон даже упомянутый в комментах труп ммо фрэймворка от сановцев пытались сделать подобное. Если они ещё не поубивали свои обсуждения, то там можно прочитать очень много интересных вещей, которые никогда бы не пригодились, еслиб они понимали что реально нужно от игровых серверов )
Вы просто фанатик… вам что-то объяснять просто бесполезно, вы как бык на красную тряпку, бросаетесь просто на слово Java.
1. Где я в статье сказал хоть раз. что это самое крутое мега решение всех времен и народов?
2. Почему вы считаете, что игровую логику невозможно распараллелить? Где в статье написано, что для случаев, когда логика не распараллеливается ОБЯЗАТЕЛЬНО надо делать несколько потоков? Кто мешает в этом случае запустить один поток?
3. Какие нахрен студенты? SmartFoxServer, Electroserver например выпускаеют сервера на джаве которые на одном сервере по 300к сообщений обрабатывают. Тысячи игр сделаны на их серверах. И эти, омайн год, школьники нихрена не понимают в колбасных обрезках… надо было им делать свои сервера на редисе… это точно. В однотреде.
Вы хоть понимаете что ситуации бывают разные? Что мой пример всего лишь один из вариантов построения сервера? Но, судя по той просто религиозной фанатичности с которой вы набрасываетесь на джаву, вы вряд ли поймете что инструменты бывают разные, и существуют разные архитектуры для разных задач.
P.S. Если вы такой умный, то опишите как вы будете обрабатывать 100к или 300к клиентов на игровом сервере в одном треде… а мы посмотрим. А то вы пока только пальцы гнете, что однотред лучше в 100 раз.
1. Где я в статье сказал хоть раз. что это самое крутое мега решение всех времен и народов?
2. Почему вы считаете, что игровую логику невозможно распараллелить? Где в статье написано, что для случаев, когда логика не распараллеливается ОБЯЗАТЕЛЬНО надо делать несколько потоков? Кто мешает в этом случае запустить один поток?
3. Какие нахрен студенты? SmartFoxServer, Electroserver например выпускаеют сервера на джаве которые на одном сервере по 300к сообщений обрабатывают. Тысячи игр сделаны на их серверах. И эти, омайн год, школьники нихрена не понимают в колбасных обрезках… надо было им делать свои сервера на редисе… это точно. В однотреде.
Вы хоть понимаете что ситуации бывают разные? Что мой пример всего лишь один из вариантов построения сервера? Но, судя по той просто религиозной фанатичности с которой вы набрасываетесь на джаву, вы вряд ли поймете что инструменты бывают разные, и существуют разные архитектуры для разных задач.
P.S. Если вы такой умный, то опишите как вы будете обрабатывать 100к или 300к клиентов на игровом сервере в одном треде… а мы посмотрим. А то вы пока только пальцы гнете, что однотред лучше в 100 раз.
>Где я в статье сказал хоть раз. что это самое крутое мега решение всех времен и народов?
Ну так надо было написать что решение подходит для игр типа фермы.
>Почему вы считаете, что игровую логику невозможно распараллелить?
Пример ммо реалтайм игры, в которой игровая логика легко параллелится(без шардинга, ну всмысле data parallelism).
>Почему вы считаете, что игровую логику невозможно распараллелить?
Можно, но кому это надо? Только себе проблемы создавать.
>и существуют разные архитектуры для разных задач.
я имел в виду примитив, в котором бегают солдатики, стреляют друг в друга, общаются )
>100к или 300к клиентов на игровом сервере в одном треде…
А зачем на одном сервере обрабатывать столько клиентов? Есть пример игр, в которые играют по 100к-300к клиентов?
Eve Online с их онлайном в 50к не надо в пример, там используется совершенно другая архитектура, а не то что предлагают smartfoxserver/electroserver и вы :)
Ну так надо было написать что решение подходит для игр типа фермы.
>Почему вы считаете, что игровую логику невозможно распараллелить?
Пример ммо реалтайм игры, в которой игровая логика легко параллелится(без шардинга, ну всмысле data parallelism).
>Почему вы считаете, что игровую логику невозможно распараллелить?
Можно, но кому это надо? Только себе проблемы создавать.
>и существуют разные архитектуры для разных задач.
я имел в виду примитив, в котором бегают солдатики, стреляют друг в друга, общаются )
>100к или 300к клиентов на игровом сервере в одном треде…
А зачем на одном сервере обрабатывать столько клиентов? Есть пример игр, в которые играют по 100к-300к клиентов?
Eve Online с их онлайном в 50к не надо в пример, там используется совершенно другая архитектура, а не то что предлагают smartfoxserver/electroserver и вы :)
В общем понятно… вы доказываете непонятно что… и сами себе противоречите…
>Ну так надо было написать что решение подходит для игр типа фермы.
У меня на нем сделана игра типа танков он лайн. О_о охренеть… надо будет на ридис переписать, в одном потоке…
>Можно, но кому это надо? Только себе проблемы создавать.
Проблемы с многопоточностью есть только у вас видимо…
>>и существуют разные архитектуры для разных задач.
>я имел в виду примитив, в котором бегают солдатики, стреляют друг в >друга, общаются )
Я не курю, можете пояснить что это и для чего написано?
>А зачем на одном сервере обрабатывать столько клиентов?
Ну как же? Вы же всю беседу утверждаете, что один поток разрулит абсолютно все. А теперь съезжаете, на параллельную обработку.
У EVE просто дохрена проблем, больше 500 человек в одном месте (читай на одном шареде) приводят к сильнейшим лагам. Так что и там не идеально все… хотя постойте, предложите им переписать всю игру на редис в одном потоке. Они ва мбабок заплатят )
Да, я предлагаю такую архитектуру, как и другие наверно. Не вижу в этом ничего плохого, ибо она работает. И работает хорошо. Хоть это и не самое лучшее решение всех проблем в мире. Вы вот вообще ничего не предлагаете, а только пальцы гнете.
>Ну так надо было написать что решение подходит для игр типа фермы.
У меня на нем сделана игра типа танков он лайн. О_о охренеть… надо будет на ридис переписать, в одном потоке…
>Можно, но кому это надо? Только себе проблемы создавать.
Проблемы с многопоточностью есть только у вас видимо…
>>и существуют разные архитектуры для разных задач.
>я имел в виду примитив, в котором бегают солдатики, стреляют друг в >друга, общаются )
Я не курю, можете пояснить что это и для чего написано?
>А зачем на одном сервере обрабатывать столько клиентов?
Ну как же? Вы же всю беседу утверждаете, что один поток разрулит абсолютно все. А теперь съезжаете, на параллельную обработку.
У EVE просто дохрена проблем, больше 500 человек в одном месте (читай на одном шареде) приводят к сильнейшим лагам. Так что и там не идеально все… хотя постойте, предложите им переписать всю игру на редис в одном потоке. Они ва мбабок заплатят )
Да, я предлагаю такую архитектуру, как и другие наверно. Не вижу в этом ничего плохого, ибо она работает. И работает хорошо. Хоть это и не самое лучшее решение всех проблем в мире. Вы вот вообще ничего не предлагаете, а только пальцы гнете.
>У меня на нем сделана игра типа танков он лайн
Ну так тем более, у вас в игровой комнате не может быть громадного кол-ва одновременных участников, с лёгкостью можем использовать data parallelism.
Запускаем N однопоточных серверов, каждый из которых способен обрабатывать по 1000 игровых комнат. Весь головняк с многопоточностью и оверхедом сразу отпадает. Получаем линейное масштабирование + более высокую надёжность.
>Вы же всю беседу утверждаете, что один поток разрулит абсолютно все.
Я утверждаю что ваша архитектура для игровых серверов — очень далека от той, которой следовало бы называться «производительной» :)
Ну так тем более, у вас в игровой комнате не может быть громадного кол-ва одновременных участников, с лёгкостью можем использовать data parallelism.
Запускаем N однопоточных серверов, каждый из которых способен обрабатывать по 1000 игровых комнат. Весь головняк с многопоточностью и оверхедом сразу отпадает. Получаем линейное масштабирование + более высокую надёжность.
>Вы же всю беседу утверждаете, что один поток разрулит абсолютно все.
Я утверждаю что ваша архитектура для игровых серверов — очень далека от той, которой следовало бы называться «производительной» :)
>Я утверждаю что ваша архитектура для игровых серверов — очень далека от той, которой следовало бы называться «производительной» :)
Да вы что… Может просветите, что такое «производительный»?
И почему 150-300к сообщений на одном стандартном сервере это очень плохая производительность…
Да вы что… Может просветите, что такое «производительный»?
И почему 150-300к сообщений на одном стандартном сервере это очень плохая производительность…
Вот что вы всё к какой-то цифре прицепились, которая проявляется на хз каком бенче :) Игровые сервера — это не мессенджер. Сейчас для наглядности рассматриваем насколько подходит ваша архитектура для игры типа танки онлайн :)
Вы не согласны с тем что N однопоточных серверов будут быстрее чем то что вы нагородили с никому непонятным task parallelism'ом? И то что однопоточники программировать во много проще?
Вы не согласны с тем что N однопоточных серверов будут быстрее чем то что вы нагородили с никому непонятным task parallelism'ом? И то что однопоточники программировать во много проще?
Да бог с вами )))
Если абстрагироваться от всего, однопотчные программы писать проще. Это очевидно. Но это не означает, что писать ВСЕ многопоточные программы невероятно сложно и связано с большим геморроем.
Это у вас хз какие цифры… это вы сравниваете геймсервер и редис, А моя цифра это вайтпеппер одного из самых популярных java серверов, на котором пишут и игры типа контры и фермы. Они тестили свой продукт и выложили тесты в открытый доступ. Там и железки описаны и прочие условия.
Да, игровой сервер это не месенджер, с этим трудно спорить… ну и что это доказывает? С таким же успехом могли аргументировать что-то типа, тролейбус не подвоная лодка…
Для игры подходит, ибо уже работает ))
И у меня нет «непонятного task parallelism'а».
Если вы не внимательно читали, то у меня и есть N-однопоточных серверов… количество N варьируется исходя из задачи. Только вы почему-то считаете, что запуск разных потоков одного приложения на разных машинах это не однопоток, а тот же самый запуск разных потоков, но на одной многопроцессорной машине это не одно поток…
Весьма странные у вас представления о распараллеливании вычислений…
Если абстрагироваться от всего, однопотчные программы писать проще. Это очевидно. Но это не означает, что писать ВСЕ многопоточные программы невероятно сложно и связано с большим геморроем.
Это у вас хз какие цифры… это вы сравниваете геймсервер и редис, А моя цифра это вайтпеппер одного из самых популярных java серверов, на котором пишут и игры типа контры и фермы. Они тестили свой продукт и выложили тесты в открытый доступ. Там и железки описаны и прочие условия.
Да, игровой сервер это не месенджер, с этим трудно спорить… ну и что это доказывает? С таким же успехом могли аргументировать что-то типа, тролейбус не подвоная лодка…
Для игры подходит, ибо уже работает ))
И у меня нет «непонятного task parallelism'а».
Если вы не внимательно читали, то у меня и есть N-однопоточных серверов… количество N варьируется исходя из задачи. Только вы почему-то считаете, что запуск разных потоков одного приложения на разных машинах это не однопоток, а тот же самый запуск разных потоков, но на одной многопроцессорной машине это не одно поток…
Весьма странные у вас представления о распараллеливании вычислений…
>Только вы почему-то считаете, что запуск разных потоков одного приложения на разных машинах это не однопоток, а тот же самый запуск разных потоков, но на одной многопроцессорной машине это не одно поток…
Как же печально, неужели нужно ткнуть прям в то место где у вас происходит вся тупость?
Runnable, который запускается в тредпуле и делает:
Нах task parallelism с shared data? Танки недостаточно быстро ездят и ты пытаешься это ускорить? Зааачем оно тут? )) И да, это типичная проблема жавистов, хоть жава тут не причём, во всём виновата литература по жаве.
Используй data parallelism, решение получится более простым и более производительным.
Как же печально, неужели нужно ткнуть прям в то место где у вас происходит вся тупость?
Runnable, который запускается в тредпуле и делает:
public void run()
{
while ( isActive )
{
// Получаем следующую сессию для обработки
Session session = (Session) this.sessionQueue.take();
// Здесь происходит обработка игровых сообщений
// получаем пакет
packet = session.getReadPacketQueue().take();
// далее получаем и обрабатываем данные из него
data = packet.getData();
}
}
Нах task parallelism с shared data? Танки недостаточно быстро ездят и ты пытаешься это ускорить? Зааачем оно тут? )) И да, это типичная проблема жавистов, хоть жава тут не причём, во всём виновата литература по жаве.
Используй data parallelism, решение получится более простым и более производительным.
Как жаль, что вы предпочитаете гнуть пальцы вместо конструктивного диалога, и для того чтобы вы описали конкретный пример, вам пришлось запостить кучу пустых сообщений… да я понимаю, что собственных мозгов не хватило и пришлось обращаться к более продвинутым друзьям… иначе вы бы это узкое место ни за что не привели в пример…
Но вы, в попытках найти хоть что-то хреновое в моем решении, забыли один очень важный момент… мое решение, как я уже ни раз говорил, не претендует на звание самого крутого. Оно лишь позволяет решать задачу построения игрового сервера. Производительность решения совсем не маленькая, и достаточна реализации многих проектов. Да, я не спорю, что на java или на другом языке возможно написать более производительное решение, это в принципе понятно из многих факторов.
Идеал вообще не достижим.
И опять же, вы вместо того, чтобы напрягая знакомых, искать изъяны в моем предложении, лучше бы написали свое видение как надо делать игровые сервера… а то от таких как вы только понты и негатив идет…
Да и сомневаюсь я, что лично вы, без тех тех кто вам подсказал этот момент в моем сервере, способны придумать и реализовать более изящное решение… Так что все ваши потуги в общем-то прошли даром…
Мне лично вы ничего нового не сообщили и не доказали… люди которым моя статья поможет хоть что-то сделать, довольны. А идеальные сферические кони в вакууме далеко не всем нужны.
Но вы, в попытках найти хоть что-то хреновое в моем решении, забыли один очень важный момент… мое решение, как я уже ни раз говорил, не претендует на звание самого крутого. Оно лишь позволяет решать задачу построения игрового сервера. Производительность решения совсем не маленькая, и достаточна реализации многих проектов. Да, я не спорю, что на java или на другом языке возможно написать более производительное решение, это в принципе понятно из многих факторов.
Идеал вообще не достижим.
И опять же, вы вместо того, чтобы напрягая знакомых, искать изъяны в моем предложении, лучше бы написали свое видение как надо делать игровые сервера… а то от таких как вы только понты и негатив идет…
Да и сомневаюсь я, что лично вы, без тех тех кто вам подсказал этот момент в моем сервере, способны придумать и реализовать более изящное решение… Так что все ваши потуги в общем-то прошли даром…
Мне лично вы ничего нового не сообщили и не доказали… люди которым моя статья поможет хоть что-то сделать, довольны. А идеальные сферические кони в вакууме далеко не всем нужны.
>лучше бы написали свое видение как надо делать игровые сервера…
Да я уже множество раз сказал как написать игровой сервер, для игр типа танки онлайн (до этого правда подразумевал игру с большим онлайном и общим миром, но в этой ветке речь про танки онлайн). Не надо всё настолько сильно усложнять как вы тут сделали. Напишите примитивнейший сервер, который будет работать в одном треде и полноценно обслуживать N игровых комнат, не нужен никакой параллелизм для того чтобы обслужить игровую комнату с 50'ю людьми! НЕ НУЖЕН! Здесь есть проблема с масштабированием на большое кол-во комнат, для это просто запустите множество таких ПРОСТЫХ приложений и никаких проблем не будет.
Не нужна никакая Netty, достаточно простой работы с сокетами/select. Всё в одном треде, пришли данные на сокет, прочитали, обработали. Никаких сложностей.
Ладно там еслиб моё решение было гораздо сложнее сделать и оно давало прирост в производительности, так ведь нет, моё решение делается на порядок проще, тк потом не надо думать о куче проблем с синхронизацией из-за того что всё крутится в тредпуле.
p.s. это мой последний коммент у вас в теме, если вам до сих пор кажется что ваше решение не полное гавно, то ну увы :) Только укрепите образ джавистов, которые думают что чтобы сделать что-то быстрее, достаточно поставить тредпул.
Да я уже множество раз сказал как написать игровой сервер, для игр типа танки онлайн (до этого правда подразумевал игру с большим онлайном и общим миром, но в этой ветке речь про танки онлайн). Не надо всё настолько сильно усложнять как вы тут сделали. Напишите примитивнейший сервер, который будет работать в одном треде и полноценно обслуживать N игровых комнат, не нужен никакой параллелизм для того чтобы обслужить игровую комнату с 50'ю людьми! НЕ НУЖЕН! Здесь есть проблема с масштабированием на большое кол-во комнат, для это просто запустите множество таких ПРОСТЫХ приложений и никаких проблем не будет.
Не нужна никакая Netty, достаточно простой работы с сокетами/select. Всё в одном треде, пришли данные на сокет, прочитали, обработали. Никаких сложностей.
Ладно там еслиб моё решение было гораздо сложнее сделать и оно давало прирост в производительности, так ведь нет, моё решение делается на порядок проще, тк потом не надо думать о куче проблем с синхронизацией из-за того что всё крутится в тредпуле.
p.s. это мой последний коммент у вас в теме, если вам до сих пор кажется что ваше решение не полное гавно, то ну увы :) Только укрепите образ джавистов, которые думают что чтобы сделать что-то быстрее, достаточно поставить тредпул.
Мне кажется глупым, считать ваш подход «единственно верным». Да можно писать однопоточные серверы, если ОС поддерживает асинхронный IO и запускать несколько процессов. Но далеко не факт, что это оправдано с точки зрения время разработки, сложности системы и производительности. Я сам принимал участия в разработке серверной системы, которая, с точки зрения ОС была однопоточной, что бы сэкономить context switch. На самом деле это была монстрообразная система, со своими нитями на пользовательском уровне (которых в каждом инстансе бежали сотни), полностью своим менеджментом памяти, и кучей других бубнов, что бы выжать максимум производительности из железа. Ну там задача такая — кластерная ФС, с тысячими параллельных операций ввода/вывода, гигабайтами данных в секунду и тд. Но при этом сложность системы была такая, что код без тщательного построчного ревью всеми инженерами не коммитился — шанс что то ненароком сломать был огромный. Оправдана была такая архитектура для той системы? Возможно, хотя некоторые и сомневались. Оправдана она была бы на системе с меньшими требованиями? Не в коем случае. За почти любой выигрыш в скорости надо платить временем разработки и поддержки. По этому нельзя сказать, что игровой сервер на джава, хуже такового на С++. А если они оба отвечают требованиям, а на Джаве заняло написать его в 3 маньше времени, то он даже однозначно лучше.
А ваш тезис, о том, что «потоки не нужны» попахивает догматизмом. Я не говорю, что они всегда нужны, но мне было бы интернсно посмотреть как вы напишете полностью однопоточный сервер, когда вам придется обращатся к БД или делать другие медленные IO операции.
А ваш тезис, о том, что «потоки не нужны» попахивает догматизмом. Я не говорю, что они всегда нужны, но мне было бы интернсно посмотреть как вы напишете полностью однопоточный сервер, когда вам придется обращатся к БД или делать другие медленные IO операции.
Эх, ну раз объявился другой комментатор, то отвечу и вам :) Раз уж у вас опыт и с concurrency и с parallelism'ом есть, то наверно с вами получится нормальный диалог )
Но вы всё же немного не понимаете о том про что я пишу.
Представьте сложную in-memory базу данных с кучей очень сложных хранимых процедур. Теперь попытайтесь её распараллелить :)
Наверно вы понимаете, что сделать так чтобы такое решение работало на 4 ядрах хотябы так же как на 1ядре с такой же производительностью — это невероятно сложная задача. А то что в этом посте было предложено, будет работать на 16 ядрах как на 1 :) Стоит ли напрягаться на распараллеливание(придётся написать во много больше кода, и понимать этот код будут только настоящие джедаи), если можно всё сделать по простому?
>А ваш тезис, о том, что «потоки не нужны» попахивает догматизмом.
мой тезис в том что не нужно пытаться распараллелить игровую логику, это очень сложная задача, кто-то для этого пытается создавать специальные дсл язычки, есть и другие подходы. Но при любом подходе всё это очень и очень сложно, и не нужно :) Тк проще поставить геймдизайнера в определённые рамки и обойтись более простым решением, качество игрушки при этом не пострадает.
>Я не говорю, что они всегда нужны, но мне было бы интернсно посмотреть как вы напишете полностью однопоточный сервер, когда вам придется обращатся к БД или делать другие медленные IO операции.
Речь про _игровой_ сервер. Нет никаких медленных IO операций, все запросы должны обрабатываться мгновенно, всё в памяти. Я сразу в этой теме первым комментом написал — это не веб разработка, не нужно переносить архитектуру веб приложений в разработку игрового сервера, всё можно сделать проще и будет работать быстрее.
Но вы всё же немного не понимаете о том про что я пишу.
Представьте сложную in-memory базу данных с кучей очень сложных хранимых процедур. Теперь попытайтесь её распараллелить :)
Наверно вы понимаете, что сделать так чтобы такое решение работало на 4 ядрах хотябы так же как на 1ядре с такой же производительностью — это невероятно сложная задача. А то что в этом посте было предложено, будет работать на 16 ядрах как на 1 :) Стоит ли напрягаться на распараллеливание(придётся написать во много больше кода, и понимать этот код будут только настоящие джедаи), если можно всё сделать по простому?
>А ваш тезис, о том, что «потоки не нужны» попахивает догматизмом.
мой тезис в том что не нужно пытаться распараллелить игровую логику, это очень сложная задача, кто-то для этого пытается создавать специальные дсл язычки, есть и другие подходы. Но при любом подходе всё это очень и очень сложно, и не нужно :) Тк проще поставить геймдизайнера в определённые рамки и обойтись более простым решением, качество игрушки при этом не пострадает.
>Я не говорю, что они всегда нужны, но мне было бы интернсно посмотреть как вы напишете полностью однопоточный сервер, когда вам придется обращатся к БД или делать другие медленные IO операции.
Речь про _игровой_ сервер. Нет никаких медленных IO операций, все запросы должны обрабатываться мгновенно, всё в памяти. Я сразу в этой теме первым комментом написал — это не веб разработка, не нужно переносить архитектуру веб приложений в разработку игрового сервера, всё можно сделать проще и будет работать быстрее.
>мой тезис в том что не нужно пытаться распараллелить игровую логику, это очень сложная задача, кто-то для этого пытается создавать специальные дсл язычки
Вы дажене удосужились почитать статью и посмотреть код…
У меня есть несколько потоков которые обрабатывают сообщения не глядя друг на друга, логика нигде не распарралеливается. Вы это можете понять? Поток берет сообщение и обрабатывает его не глядя что делается в других.
Это все равно что запустить как отдельные приложения. Логика там не парралелится… она в один поток работает.
Вы дажене удосужились почитать статью и посмотреть код…
У меня есть несколько потоков которые обрабатывают сообщения не глядя друг на друга, логика нигде не распарралеливается. Вы это можете понять? Поток берет сообщение и обрабатывает его не глядя что делается в других.
Это все равно что запустить как отдельные приложения. Логика там не парралелится… она в один поток работает.
— Прилетают два входящих соединения
— Оба отправляют сообщения: сделать шаг влево
— Netty кусок переварил эти сообщения, положил в сессии
— Прогретый threadpool уже жаждит ускорить всё и вся со своим ReadQueueHandler начинает обрабатывать _параллельно_ сообщения. Как же нам так изменить положения двух игроков, перестроить индексы в map grid'е/octree/хз-что у вас там используется для различных запросов типа check los'а, и умудриться сделать это так чтобы всем казалось что мы однотред.
И тут начинает слышаться плачь разработчиков: «Логика там не парралелится… она в один поток работает.», честно-честно.
— Оба отправляют сообщения: сделать шаг влево
— Netty кусок переварил эти сообщения, положил в сессии
— Прогретый threadpool уже жаждит ускорить всё и вся со своим ReadQueueHandler начинает обрабатывать _параллельно_ сообщения. Как же нам так изменить положения двух игроков, перестроить индексы в map grid'е/octree/хз-что у вас там используется для различных запросов типа check los'а, и умудриться сделать это так чтобы всем казалось что мы однотред.
И тут начинает слышаться плачь разработчиков: «Логика там не парралелится… она в один поток работает.», честно-честно.
У вас очень извращенная фантазия ))
ReadQueueHandler вообще-то ничего не ускоряет… более того не для этого делался ))
Положение игроков рассчитывается в порядке очереди поступления от них данных… кто первый встал того и тапки. Проблем нет.
Просто вы увидели маленький кусочек сервера и делаете по нему далеко идущие выводы… и да, если вы не осилили это, совершенно не означает, что другие не могут )
ReadQueueHandler вообще-то ничего не ускоряет… более того не для этого делался ))
Положение игроков рассчитывается в порядке очереди поступления от них данных… кто первый встал того и тапки. Проблем нет.
Просто вы увидели маленький кусочек сервера и делаете по нему далеко идущие выводы… и да, если вы не осилили это, совершенно не означает, что другие не могут )
>Положение игроков рассчитывается в порядке очереди поступления от них данных… кто первый встал того и тапки. Проблем нет.
Что и следовало доказать, вы занимаетесь синхронизацией внутри своих тред-пулов, а это значит что сложность кода возрастает на порядок и вероятность того что вы сделаете решение более производительным чем однотред ничтожно мало.
>и да, если вы не осилили это, совершенно не означает, что другие не могут )
Ну если вам той ссылки на redis мало, где их разработчики не способны осилисть, то почитайте что выдаёт Michael Stonebraker, вот почитайте про его проект H-Store и пройдитесь по их publications. Игровой сервер по сути и будет очень сложной in-memory базой данных. Видимо люди, которые не один десяток лет занимаются разработкой таких систем не достигли того уровня, какой появился у вас после прочтения книжек по тому как воткнуть тредпул в жаве.
Что и следовало доказать, вы занимаетесь синхронизацией внутри своих тред-пулов, а это значит что сложность кода возрастает на порядок и вероятность того что вы сделаете решение более производительным чем однотред ничтожно мало.
>и да, если вы не осилили это, совершенно не означает, что другие не могут )
Ну если вам той ссылки на redis мало, где их разработчики не способны осилисть, то почитайте что выдаёт Michael Stonebraker, вот почитайте про его проект H-Store и пройдитесь по их publications. Игровой сервер по сути и будет очень сложной in-memory базой данных. Видимо люди, которые не один десяток лет занимаются разработкой таких систем не достигли того уровня, какой появился у вас после прочтения книжек по тому как воткнуть тредпул в жаве.
>Что и следовало доказать, вы занимаетесь синхронизацией внутри своих тред-пулов
Это пипец. НЕТУ там синхронизации. Откуда вы ее взяли? Покажите в коде где у меня там синхронизация.
>Ну если вам той ссылки на redis мало, где их разработчики не способны осилисть.
Я не спорю что редис быстрый и крутой.
НО! Говоря ">и да, если вы не осилили это, совершенно не означает, что другие не могут ) ", я имел в виду лично вас. Если редис не ваше личное достижение и Michael Stonebraker не вы, то грош цена вашим каментам… Вы пока не привели вообще никаких примеров своих личных разработок. Одни только понты какие все вокруг идиоты и не умеют писать сервера… один вы в белом красивый стоите ))
Еще раз говорю, все потоки работают независимо, ничего друг с другом не синхронизируя. Это не теория, это рабочий проект.
Вы кроме криков, синглтред рулит, ничего не привели вообще. Вариантов построения игрового сервера >1. Если это не укладывается в вашей голове, то вам же и хуже ))
Это пипец. НЕТУ там синхронизации. Откуда вы ее взяли? Покажите в коде где у меня там синхронизация.
>Ну если вам той ссылки на redis мало, где их разработчики не способны осилисть.
Я не спорю что редис быстрый и крутой.
НО! Говоря ">и да, если вы не осилили это, совершенно не означает, что другие не могут ) ", я имел в виду лично вас. Если редис не ваше личное достижение и Michael Stonebraker не вы, то грош цена вашим каментам… Вы пока не привели вообще никаких примеров своих личных разработок. Одни только понты какие все вокруг идиоты и не умеют писать сервера… один вы в белом красивый стоите ))
Еще раз говорю, все потоки работают независимо, ничего друг с другом не синхронизируя. Это не теория, это рабочий проект.
Вы кроме криков, синглтред рулит, ничего не привели вообще. Вариантов построения игрового сервера >1. Если это не укладывается в вашей голове, то вам же и хуже ))
>ReadQueueHandler вообще-то ничего не ускоряет… более того не для этого делался ))
Я лишь пересказываю то что у вас написано: «Создает пул потоков. Добавляем в очередь сессии на обработку и в обработчике реализуем свою игровую логику» => параллелизм игровой логики.
Я лишь пересказываю то что у вас написано: «Создает пул потоков. Добавляем в очередь сессии на обработку и в обработчике реализуем свою игровую логику» => параллелизм игровой логики.
> => параллелизм игровой логики.
Да вы еще и читать не умеете )) Ра пересказываете неверно…
Это такой же параллелизм как и в вашем однотреде запущенном на разных машинах.
Да вы еще и читать не умеете )) Ра пересказываете неверно…
Это такой же параллелизм как и в вашем однотреде запущенном на разных машинах.
В моём однотреде два клиента, играющие в одной игровой комнате будут обрабатываться всегда внутри одного треда, будут обращаться к общей памяти, которая доступна только внутри этого треда, поэтому реализация игровой логики будет примитивна.
В вашем случае два клиента, играющие в одной игровой комнате смогут начать обрабатываться в двух различных тредах. Или что вообще вы подразумеваете под игровой логикой? Пересылка сообщений от клиентов куда-то дальше, где всё работает по схеме, которую я описал? Тогда зачем нужно это промежуточное звено в виде readqueuehandler?
В вашем случае два клиента, играющие в одной игровой комнате смогут начать обрабатываться в двух различных тредах. Или что вообще вы подразумеваете под игровой логикой? Пересылка сообщений от клиентов куда-то дальше, где всё работает по схеме, которую я описал? Тогда зачем нужно это промежуточное звено в виде readqueuehandler?
Да, ситуация, когда 2 клиента в одной комнате будут обрабатываться в разных тредах возможна. Это критично только для реалтайм игрушек типа контры. Но опять же не делает невозможным их написание. И опять же для такой игрушки никто не мешает указать в настройках 1 игровой тред и получить так вами любимый однотредовый сервер. А для прочих ферм и пошаговых игр это вообще не имеет значения…
Опять же это никак не отрицает право на существование моей архитектуры, ибо как я и говорил вам неоднократно, это всего лишь пример реализации и не более того. Он не претендует на идеальность…
Вообще странно, чего вы так взъелись на этот пример…
Опять же это никак не отрицает право на существование моей архитектуры, ибо как я и говорил вам неоднократно, это всего лишь пример реализации и не более того. Он не претендует на идеальность…
Вообще странно, чего вы так взъелись на этот пример…
>Это критично только для реалтайм игрушек типа контры.
«У меня на нем сделана игра типа танков он лайн» :)
>А для прочих ферм и пошаговых игр это вообще не имеет значения…
Да, обычно для простоты разработки в таких играх используются такая же архитектура как при разработке веб приложений и все проблемы ложатся на внешнюю базу данных, а во время обработки сообщений не происходит никакого взаимодействие с общей памятью, всё только через внешнюю базу данных.
>Опять же это никак не отрицает право на существование моей архитектуры
Не отрицает, я сразу говорил что для фермы оно подойдёт :) Для танки онлайн — нет.
«У меня на нем сделана игра типа танков он лайн» :)
>А для прочих ферм и пошаговых игр это вообще не имеет значения…
Да, обычно для простоты разработки в таких играх используются такая же архитектура как при разработке веб приложений и все проблемы ложатся на внешнюю базу данных, а во время обработки сообщений не происходит никакого взаимодействие с общей памятью, всё только через внешнюю базу данных.
>Опять же это никак не отрицает право на существование моей архитектуры
Не отрицает, я сразу говорил что для фермы оно подойдёт :) Для танки онлайн — нет.
>>Это критично только для реалтайм игрушек типа контры.
>«У меня на нем сделана игра типа танков он лайн» :)
Не вижу противоречий. Реалтайм делать сложнее, это очевидно… И да я на своем сервере сделал реалтайм который держит пару тысяч в онлайне. Если делать по другому и на другом языке возможно будет быстрее и что с того?
>Не отрицает, я сразу говорил что для фермы оно подойдёт :)
Это вы потом обронили проходя… а сначала вы говорили «однотред рулит полюбому, многотред по умолчанию гавно». Причем без вариантов ))
В любом случае вы выступили не теме, вы доказывали вещи которые в статье даже не упоминались, я никогда не утверждал что это самый быстрый реалтайм сервер на свете… просто вам захотелось с помощью знакомых выпендриться, что вы самый умный в белом, а другие «webдевелоперы» нихрена не умеют )))
>«У меня на нем сделана игра типа танков он лайн» :)
Не вижу противоречий. Реалтайм делать сложнее, это очевидно… И да я на своем сервере сделал реалтайм который держит пару тысяч в онлайне. Если делать по другому и на другом языке возможно будет быстрее и что с того?
>Не отрицает, я сразу говорил что для фермы оно подойдёт :)
Это вы потом обронили проходя… а сначала вы говорили «однотред рулит полюбому, многотред по умолчанию гавно». Причем без вариантов ))
В любом случае вы выступили не теме, вы доказывали вещи которые в статье даже не упоминались, я никогда не утверждал что это самый быстрый реалтайм сервер на свете… просто вам захотелось с помощью знакомых выпендриться, что вы самый умный в белом, а другие «webдевелоперы» нихрена не умеют )))
>Если делать по другому и на другом языке возможно будет быстрее и что с того?
Если есть уже опыт работы с джавой, то делать на джаве, она отлично справится с этой задачей. Но если делать вариант попроще без тредпулов/нетти, кода будет значительно меньше и работать будет быстрее :)
Я думал/общался на тему распараллеливания в игровом сервере, есть на уровне идеи архитектурка, но оно было не востребовано, тк небыло проблемы с производительностью, обычный однотред был способен обслуживать 7к онлайна. Вобщем если задача писать сервер для игрушки типа WOW, то можно попробовать всё сделать примерно так:
разбиваем всё на задачи:
— PacketReader (читаем из сокетов, обрабатываем запросы)
— PacketWriter (отправляем данные)
— GameTick
++ MoveMobiles (производим перемещение персонажей)
++ CheckLOS: depends on MoveMobiles (делаем возможные запросы на проверку видимости, будет делаться куча ненужных запросов, но из-за параллелизма получим выигрыш)
++ Other Queries: depends on MoveMobiles
++ Game Logic: depends on MoveMobiles, CheckLOS, Other Queries (сложная игровая логика, которую уже лучше не пытаться распараллелить)
Ну и запускаем тредов по кол-ву логических процессоров, которые будут исполнять нашу архитектуру, описаную в таком декларативном стиле.
Например у нас 8 тредов.
Планировщик начинает свою работу:
PacketReader (в зависимости от кол-ва клиентов планировщик разбивает эту задачу на несколько подзадач, которые могут исполнятся параллельно)
PacketWriter (тоже самое)
GameTick -> ищем корневые задачи, у которых нет зависимостей -> находим MoveMobiles (задача возможна для распараллеливания, планировщик решает на сколько бить подзадач)
Как только отработал MoveMobiles, планировщик видит что может выполнить две задачи CheckLOS, Other Queries — свободные треды подхватывают и выполняют. После чего остаётся Game Logic, который уже лучше не пытаться распараллелить и всё по кругу.
Вот как-то так, естественно нигде на серверах ничего подобного я не пробовал использовать, так что всё на уровне идеи.
>просто вам захотелось с помощью знакомых выпендриться
Причём тут какие-то знакомые? Это я сейчас лежу с температурой под 40 градусов и могу развлекаться, а каким-то знакомым было бы совсем лень читать всю эту бредятину :)
Если есть уже опыт работы с джавой, то делать на джаве, она отлично справится с этой задачей. Но если делать вариант попроще без тредпулов/нетти, кода будет значительно меньше и работать будет быстрее :)
Я думал/общался на тему распараллеливания в игровом сервере, есть на уровне идеи архитектурка, но оно было не востребовано, тк небыло проблемы с производительностью, обычный однотред был способен обслуживать 7к онлайна. Вобщем если задача писать сервер для игрушки типа WOW, то можно попробовать всё сделать примерно так:
разбиваем всё на задачи:
— PacketReader (читаем из сокетов, обрабатываем запросы)
— PacketWriter (отправляем данные)
— GameTick
++ MoveMobiles (производим перемещение персонажей)
++ CheckLOS: depends on MoveMobiles (делаем возможные запросы на проверку видимости, будет делаться куча ненужных запросов, но из-за параллелизма получим выигрыш)
++ Other Queries: depends on MoveMobiles
++ Game Logic: depends on MoveMobiles, CheckLOS, Other Queries (сложная игровая логика, которую уже лучше не пытаться распараллелить)
Ну и запускаем тредов по кол-ву логических процессоров, которые будут исполнять нашу архитектуру, описаную в таком декларативном стиле.
Например у нас 8 тредов.
Планировщик начинает свою работу:
PacketReader (в зависимости от кол-ва клиентов планировщик разбивает эту задачу на несколько подзадач, которые могут исполнятся параллельно)
PacketWriter (тоже самое)
GameTick -> ищем корневые задачи, у которых нет зависимостей -> находим MoveMobiles (задача возможна для распараллеливания, планировщик решает на сколько бить подзадач)
Как только отработал MoveMobiles, планировщик видит что может выполнить две задачи CheckLOS, Other Queries — свободные треды подхватывают и выполняют. После чего остаётся Game Logic, который уже лучше не пытаться распараллелить и всё по кругу.
Вот как-то так, естественно нигде на серверах ничего подобного я не пробовал использовать, так что всё на уровне идеи.
>просто вам захотелось с помощью знакомых выпендриться
Причём тут какие-то знакомые? Это я сейчас лежу с температурой под 40 градусов и могу развлекаться, а каким-то знакомым было бы совсем лень читать всю эту бредятину :)
>Вобщем если задача писать сервер для игрушки типа WOW
Вы вообще понимаете о чем статья? Очень сильно сомневаюсь…
Я уже многократно говорил о чем она.
Вы приводите описание полного игрового сервера, для ММОРПГ, я привел описание обобщенной архитектуры для игрового сервера, причем сразу сказал, что это не идеал а лишь вариант который я использую.
Опять же где в вашем описании один тред который все делает???
Опять себе противоречите? Один тред это же круто по любому!
>Причём тут какие-то знакомые?
Они тут притом, что ваши каменты в начале и в конце очень сильно отличаются… плюс вы пару раз упоминали «МЫ рассмотрим вашу архитектуру», т.е. создается полное ощущение, что вы зашли в топик, нихрена не поняли о чем он, но посчитали нужным накидать пальцев, что только лоховатые вебдевелоперы пишут сервера на java, а все реальные пацаны пишут на… (не знаю на чем там они пишут?) в одном треде.
За каким-то фигом привели редис, хотя в статье даже нет полного описания сервера, только его часть по работе с пакетами при помощи Netty. Именно это меня попросили описать в другом топике про Netty, что я и сделал. Потом когда стало понятно, что вы кроме пальцев ничего показать не можете, вы обратились к более опытным знакомым, которые таки указали узкое место моей архитектуры… но оно было очевидно и в доказательстве не нуждалось )) С этого момента ваши каменты приобрели более реальные черты, такое ощущение что вам более опытные товарищи подсказывали аргументы… но так как лично вы ни одного сервера не написали (вы сами об этом сказали), то о чем вообще речь? Описав свое видение сервера вы сами сделали его многопоточным со сложной логикой, наплевав на собственные аргументы о крутизне однотреда и простоте кода…
В общем вы относитесь к той категории людей, которые сами нихрена не делают, но готовы обсирать чужие изделия при любой возможности… даже не по делу…
Вы вообще понимаете о чем статья? Очень сильно сомневаюсь…
Я уже многократно говорил о чем она.
Вы приводите описание полного игрового сервера, для ММОРПГ, я привел описание обобщенной архитектуры для игрового сервера, причем сразу сказал, что это не идеал а лишь вариант который я использую.
Опять же где в вашем описании один тред который все делает???
Опять себе противоречите? Один тред это же круто по любому!
>Причём тут какие-то знакомые?
Они тут притом, что ваши каменты в начале и в конце очень сильно отличаются… плюс вы пару раз упоминали «МЫ рассмотрим вашу архитектуру», т.е. создается полное ощущение, что вы зашли в топик, нихрена не поняли о чем он, но посчитали нужным накидать пальцев, что только лоховатые вебдевелоперы пишут сервера на java, а все реальные пацаны пишут на… (не знаю на чем там они пишут?) в одном треде.
За каким-то фигом привели редис, хотя в статье даже нет полного описания сервера, только его часть по работе с пакетами при помощи Netty. Именно это меня попросили описать в другом топике про Netty, что я и сделал. Потом когда стало понятно, что вы кроме пальцев ничего показать не можете, вы обратились к более опытным знакомым, которые таки указали узкое место моей архитектуры… но оно было очевидно и в доказательстве не нуждалось )) С этого момента ваши каменты приобрели более реальные черты, такое ощущение что вам более опытные товарищи подсказывали аргументы… но так как лично вы ни одного сервера не написали (вы сами об этом сказали), то о чем вообще речь? Описав свое видение сервера вы сами сделали его многопоточным со сложной логикой, наплевав на собственные аргументы о крутизне однотреда и простоте кода…
В общем вы относитесь к той категории людей, которые сами нихрена не делают, но готовы обсирать чужие изделия при любой возможности… даже не по делу…
>Я уже многократно говорил о чем она.
Да понимаю о чём статья. Для игрового сервера, который использует внешнюю базу данных и вся нагрузка лежит на ней, для игры вроде фермы.
Просто я привёл пример как можно попробовать использовать параллелизм в задаче, где это действительно может понадобиться.
>Опять же где в вашем описании один тред который все делает???
То описание, которое я привёл — это очень сложное решение, которое нужно рассматривать в последнюю очередь. В этом описании не один тред, но я же написал что это рассуждения о том как можно попробовать распараллелить, а вообще в большинстве игр этого не понадобится и однотред будет справляться с задачей превосходно.
>что только лоховатые вебдевелоперы пишут сервера на java
я про лоховатых вебдевелоперов, которые вставляют ThreadPoolExecutor'ы в места где им совсем не место :)
>а все реальные пацаны пишут на… (не знаю на чем там они пишут?) в одном треде.
реальные пацаны пишут на всём и умеют использовать «много тредов», но это очень сложно. Поэтому рациональнее использовать тот язык, с которым знаком и стараться избегать использовать треды, если не понимаешь как распараллеливать.
>За каким-то фигом привели редис
За тем что разработка in-memory базы данных очень похожа на разработку игрового сервера.
>но так как лично вы ни одного сервера не написали
Ну можно по пальцам наверно пересчитать людей, которые в одиночку реализовывали такие сложные проекты как игровые сервера :) Если инфраструктурный кусок можно в одного написать, то остальные 99% кода в одного как-то проблематично сделать.
Или под сервером понимается то что у вас тут в статье расписано? ) Ну работа с сокетами, epoll, circular буффера через mmap(либо chunked buffer'а если тысячи полудохлых соединений) и немного знаний Си позволят всё это сделать за пару часиков, не понимаю что в этом сложного. Писал и не раз :) Писал на джаве, на Си, на ерланге, на питоне. Работу с сетью предпочитаю на си и ерланге.
>Описав свое видение сервера вы сами сделали его многопоточным со сложной логикой
ээ, а вы ждали описание однотреда? Оно как бы настолько просто, что я даже не думал что нужно описывать :)
ну пожалуйста:
Да понимаю о чём статья. Для игрового сервера, который использует внешнюю базу данных и вся нагрузка лежит на ней, для игры вроде фермы.
Просто я привёл пример как можно попробовать использовать параллелизм в задаче, где это действительно может понадобиться.
>Опять же где в вашем описании один тред который все делает???
То описание, которое я привёл — это очень сложное решение, которое нужно рассматривать в последнюю очередь. В этом описании не один тред, но я же написал что это рассуждения о том как можно попробовать распараллелить, а вообще в большинстве игр этого не понадобится и однотред будет справляться с задачей превосходно.
>что только лоховатые вебдевелоперы пишут сервера на java
я про лоховатых вебдевелоперов, которые вставляют ThreadPoolExecutor'ы в места где им совсем не место :)
>а все реальные пацаны пишут на… (не знаю на чем там они пишут?) в одном треде.
реальные пацаны пишут на всём и умеют использовать «много тредов», но это очень сложно. Поэтому рациональнее использовать тот язык, с которым знаком и стараться избегать использовать треды, если не понимаешь как распараллеливать.
>За каким-то фигом привели редис
За тем что разработка in-memory базы данных очень похожа на разработку игрового сервера.
>но так как лично вы ни одного сервера не написали
Ну можно по пальцам наверно пересчитать людей, которые в одиночку реализовывали такие сложные проекты как игровые сервера :) Если инфраструктурный кусок можно в одного написать, то остальные 99% кода в одного как-то проблематично сделать.
Или под сервером понимается то что у вас тут в статье расписано? ) Ну работа с сокетами, epoll, circular буффера через mmap(либо chunked buffer'а если тысячи полудохлых соединений) и немного знаний Си позволят всё это сделать за пару часиков, не понимаю что в этом сложного. Писал и не раз :) Писал на джаве, на Си, на ерланге, на питоне. Работу с сетью предпочитаю на си и ерланге.
>Описав свое видение сервера вы сами сделали его многопоточным со сложной логикой
ээ, а вы ждали описание однотреда? Оно как бы настолько просто, что я даже не думал что нужно описывать :)
ну пожалуйста:
for(;;) {
wait_for_sys_events(wait_for_next_timeout); // дожидаемся евентов от операционки и обрабатываем
time = now(); // текущее время
wait_for_next_timeout = do_timers(time); // обработать таймеры и получить через сколько будет след таймер
do_game_logic(time); // игровая логика
garbage_collect(); // почистить ненужные сокеты итп
}
Т.е. сначала говорили что «однопоток наше фсе», многотреды идут лесом вместе с вебдевелоперами которые их пишут… причем без вариантов. Вы просто таки всеми силами доказывали что реальные пацаны юзают только однотред.
А сейчас вдруг оказывается, что вы допускаете возможность многопоточных серверов… заврались уже…
А сейчас вдруг оказывается, что вы допускаете возможность многопоточных серверов… заврались уже…
Какая же печаль :)
Если разрабатывать игру типа «Танки онлайн», то однотред наиболее выигрышный вариант из всех, тк быстрее сделать будет тяжелее, код получается очень простым, более надёжным, линейно масштабируется.
Если игра, где общий мир и кол-во одновременных игроков ~10k, то тут можно рассматривать различные варианты с параллелизмом, но разработка сильно усложнится и проще ставить геймдизайнера в рамки.
Если игра типа фермы, то тут зависит от разработчиков, если в команде сплошные вебдевелоперы, у которых есть только опыт отображения того что находится во внешней базе данных, то ваш вариант имеет место быть :)
Если разрабатывать игру типа «Танки онлайн», то однотред наиболее выигрышный вариант из всех, тк быстрее сделать будет тяжелее, код получается очень простым, более надёжным, линейно масштабируется.
Если игра, где общий мир и кол-во одновременных игроков ~10k, то тут можно рассматривать различные варианты с параллелизмом, но разработка сильно усложнится и проще ставить геймдизайнера в рамки.
Если игра типа фермы, то тут зависит от разработчиков, если в команде сплошные вебдевелоперы, у которых есть только опыт отображения того что находится во внешней базе данных, то ваш вариант имеет место быть :)
Охренеть…
2 дня переписки и вы наконец-то признали, что существуют различные архитектурные варианты построения игровых серверов…
Давно я так не развлекался… )))
2 дня переписки и вы наконец-то признали, что существуют различные архитектурные варианты построения игровых серверов…
Давно я так не развлекался… )))
А я где-то говорил что существует только один труъ вэй? Это вы за меня это сказали, а потом ещё несколько раз повторили.
Почти сразу сказал про «где игровая логика была посложнее чем многопользовательская ферма.», а потом старался всегда говорить где пишу про игру типа «танки онлайн» раз уж вы её упомянули, а где про совсем сложные типа «wow».
А теперь ещё встаёт вопрос про разработки игр типа ферма, целесообразно ли для вебдевелоперов использовать что-то сложнее, чем привычный для них стэк для разработки веб приложений? Тк обработка риквестов наврятли будет узким местом :)
Почти сразу сказал про «где игровая логика была посложнее чем многопользовательская ферма.», а потом старался всегда говорить где пишу про игру типа «танки онлайн» раз уж вы её упомянули, а где про совсем сложные типа «wow».
А теперь ещё встаёт вопрос про разработки игр типа ферма, целесообразно ли для вебдевелоперов использовать что-то сложнее, чем привычный для них стэк для разработки веб приложений? Тк обработка риквестов наврятли будет узким местом :)
Мне кажется вы очень шировких спектр зачач сводите к какой-то кокретной зачаде. То, что вы описываете, это не некий универсальный «игровой сервер» (такого не бывает) а что-то больше похоже на сервер в FPS игры, где компанты всего на пару десятков игроков, все в памяти, и все упирается в CPU и скорость обработки пакетов. А если игра — это какой-нибудь mmorpg с едиными миром — то тут все в память не загрузишь, без БД не обойдешься и в одном потоке N тысяч соединеней не обработаешь. А тут уже все как у взрослых — балансировка, перекидование клиентов, сервисы, запись и чтение БД, синхронизазия информаци между инстансами и нодами сервера, многопоточность и все остальное.
>Мне кажется вы очень шировких спектр зачач сводите к какой-то кокретной зачаде.
Я отлично понимаю проблемы различных задач. И описывал как можно попробовать распараллелить mmorpg с единым миром.
>А если игра — это какой-нибудь mmorpg с едиными миром — то тут все в память не загрузишь, без БД не обойдешься и в одном потоке N тысяч соединеней не обработаешь.
Ну из публичной инфы на память приходит: UO, шард Hybrid, сервер RunUO, железо ~2004года, один тред, 7600 онлайна(реальные игроки/возможно боты) на стресс тесте, всё упиралось в пропускную способность канала, а так бы система смогла обслужить и большее кол-во игроков. И при этом сервер реализован не самым эфективным способом, есть просто отвратительные алгоритмы в таких местах как таймеры, исполнялся в старом .NET'е, который был очень далёк от того что делает современная Java и .net.
Я отлично понимаю проблемы различных задач. И описывал как можно попробовать распараллелить mmorpg с единым миром.
>А если игра — это какой-нибудь mmorpg с едиными миром — то тут все в память не загрузишь, без БД не обойдешься и в одном потоке N тысяч соединеней не обработаешь.
Ну из публичной инфы на память приходит: UO, шард Hybrid, сервер RunUO, железо ~2004года, один тред, 7600 онлайна(реальные игроки/возможно боты) на стресс тесте, всё упиралось в пропускную способность канала, а так бы система смогла обслужить и большее кол-во игроков. И при этом сервер реализован не самым эфективным способом, есть просто отвратительные алгоритмы в таких местах как таймеры, исполнялся в старом .NET'е, который был очень далёк от того что делает современная Java и .net.
а чего, вы, собственно, вцепились в редис то? вполне хорошее и годное для hi-load и продакшина решение.
В основном потоки создаются, чтобы в случае блокировки какой-то операции система не зависла в ожидании выполнения данной операции и могла продолжать обслуживать остальные запросы. Обычно +1/+2 потока относительно ядер системы.
Допустим я бью мечем, а противник ставит щит именно в такой последовательности. На Вашем сервере это может обработаться как — противник ставит щит и только потом я бью мечем? Зависит от того когда Ваш нетти отдаст пакет в логику?
Ну тут уже зависит в каком порядке придут пакеты :) Зачем серверу их переставлять? Кто первый встал того и тапки.
Допустим они пришли в правильном порядке, но с задержкой в 1 мс. Как нетти отработает эти 2 запроса? В разных потоках или в одном? Собственно почему возник вопрос, потому что не понятно как нетти их отработает. Как она отрабатывает 20к запросов в сек?
Странные вопросы… Нетти их вообще не обрабатывает, она только их принимает. Примет нетти их отлично, в несколько потоков… на десктопе у меня вообще 40-50к принимает и ничего все Ок. В чем конкретно проблема?
Не важно в каком потоке происходит обработка пакета. А по поводу, как тут вам надо почитать матчасть о Java NIO. На эту тему уже есть много информации, не хочу повторяться.
Во первых нетти не мой ). Я его просто использую.
Во вторых, на моем сервере все обработается корректно.
В третьих, эта проблема (если ее так можно назвать) присутствует при любом варианте реализации сервера. Синхронизацию клиентов еще никто не отменял.
Задача TCP сервера максимально быстро получить пакет и отдать его в очередь на обработку, чтобы минимизировать влияние обработчика на последовательность пакетов. Это одна из причин по которой не пишут логику в обработчике на netty. А дальше ваша логика разруливает сообщения, что с ними делать и в какой последовательности их обработать.
Если у кого-то из клиентов пинг очень большой, то он ССЗБ. И портить из-за него игру всем просто нет смысла.
Во вторых, на моем сервере все обработается корректно.
В третьих, эта проблема (если ее так можно назвать) присутствует при любом варианте реализации сервера. Синхронизацию клиентов еще никто не отменял.
Задача TCP сервера максимально быстро получить пакет и отдать его в очередь на обработку, чтобы минимизировать влияние обработчика на последовательность пакетов. Это одна из причин по которой не пишут логику в обработчике на netty. А дальше ваша логика разруливает сообщения, что с ними делать и в какой последовательности их обработать.
Если у кого-то из клиентов пинг очень большой, то он ССЗБ. И портить из-за него игру всем просто нет смысла.
Обычно в играх есть такое понятие как «tick». Это единица времени игры. Для пользователя состояния между тиками интерполируют, также многие предсказывают поведение, чтобы процесс со стороны игрока казался плавным. На деле же если задержка уложится в текущий тик то действие будет выполнено синхронно, и, в зависимости от системы, по определенным условиям (например, инициатива/скорость/другие критерии) уже будет выполнено то или иное действие: блокировка или атака.
А почему не использовать protocol buffers?
Хм… Статью не читал, но спрашиваю? )
Ах, извините. Я как вы понимаете вряд ли извлеку какую-либо новую для себя информацию. Мне гораздо интереснее обсуждение :)
Если честно не понимаю, почему я должен понимать, что вы не извлекете что-то новое )
И опять же не понимаю как вопрос «А почему не использовать protocol buffers?» относится к обсуждению статьи про сервер, в которой про реализацию протокола нет ни слова…
И опять же не понимаю как вопрос «А почему не использовать protocol buffers?» относится к обсуждению статьи про сервер, в которой про реализацию протокола нет ни слова…
Могу быть не прав, но Netty поддерживает protobuf из коробки(есть стандартный кодек для protobuf) и тогда не нужен будет ProtocolPacketHandler и FrameHandler. Или вы в образовательных целях решили выкинуть сами детали относящиеся к protobuf?
Поддержка protobuf в Netty есть. Но она не для всех случаев подходит. Если точнее, то он сработает только если если и клиент и сервер сделаны на Netty. А вот если у вас клиент например на флеше, то все, суши весла )
Интересно, надо попробовать на досуге.
Да нет, сушить ничего не надо — протобаф работает и в AS :)
www.flasher.ru/forum/blog.php?b=72
code.google.com/p/protoc-gen-as3/
code.google.com/p/as3-protobuf/
www.flasher.ru/forum/blog.php?b=72
code.google.com/p/protoc-gen-as3/
code.google.com/p/as3-protobuf/
Еще раз поясняю.
В нетти встроены кодер и декодер фреймов для протобуфа. А не сам протобуф.
Т.е. из потока байтов нетти сама может выделять сообщения. То что вы привели это совсем другое. Это всего лишь генерация смого протобуфа. При этом вопрос разделения потока байтов на сообщения остается в ваших руках.
Я понятно излагаю?
В нетти встроены кодер и декодер фреймов для протобуфа. А не сам протобуф.
Т.е. из потока байтов нетти сама может выделять сообщения. То что вы привели это совсем другое. Это всего лишь генерация смого протобуфа. При этом вопрос разделения потока байтов на сообщения остается в ваших руках.
Я понятно излагаю?
Я понял. Но я отвечал, насколько я разобрался, на ту часть сообщения, где говорилось о том, что если клиентом будет AS, то не получиться использовать этот протокол.
Ну я привел клиентскую часть, которая посылает (и принимает) сообщения в протобафе, а нетти умеет с ним работать. Остальное немного не понял :)
Ну я привел клиентскую часть, которая посылает (и принимает) сообщения в протобафе, а нетти умеет с ним работать. Остальное немного не понял :)
Вы неправильно прочитали. У меня написано, что не получится использовать поддержку протобуф в нетти, а не то что протобуф вообще нельзя использовать.
Хмм. извиняюсь, да теперь понятно. Но не вижу сути — в чем там проблема и как это коррелирует? протобаф абстрактная вещь. как он в нетти так сделан, что клиентом только нетти может выступать? Можете обьяснить в двух словах (опыт в нетти есть но до протобафа не добрался, когда работал с ним его еще не было)
Протобуф здесь косвенно, просто как протокол, на его месте может быть любой другой.
проблема в том, что от клиента серверу и обратно идет поток байтов. Внимание вопрос: Где начинается и заканчивается сообщение? Для программы все байтики одинаковые.
Вот в этом и проблема, надо сообщения как-то разделять. Самый удобный, это первым передать длину сообщения, потом тело сообщения.
т.е. поток будет выглядеть так: длина.тело, длина.тело, длина.тело.
Наша программа считывает первое число и знает сколько байт ей надо прочитать чтобы получить одно целое сообщение. Получает эти байтику и вот тут уже вступает в дело наш протокол, в данном случае протобуф, он десериализует эти байтики в понятный программе объект.
Как видно, дело тут не в протобуфе, а втом, что поток надо разделять на сообщения.
Вот весь этот процесс и имплементирован в Netty. Если у вас и сервер и клиент на netty, то весь процесс будет прозрачным и удобным.
Но если у вас клиент на флеше, то весь этот процесс, разделения потока на сообщения, надо делать самому. Что в общем совсем не сложно.
проблема в том, что от клиента серверу и обратно идет поток байтов. Внимание вопрос: Где начинается и заканчивается сообщение? Для программы все байтики одинаковые.
Вот в этом и проблема, надо сообщения как-то разделять. Самый удобный, это первым передать длину сообщения, потом тело сообщения.
т.е. поток будет выглядеть так: длина.тело, длина.тело, длина.тело.
Наша программа считывает первое число и знает сколько байт ей надо прочитать чтобы получить одно целое сообщение. Получает эти байтику и вот тут уже вступает в дело наш протокол, в данном случае протобуф, он десериализует эти байтики в понятный программе объект.
Как видно, дело тут не в протобуфе, а втом, что поток надо разделять на сообщения.
Вот весь этот процесс и имплементирован в Netty. Если у вас и сервер и клиент на netty, то весь процесс будет прозрачным и удобным.
Но если у вас клиент на флеше, то весь этот процесс, разделения потока на сообщения, надо делать самому. Что в общем совсем не сложно.
В посте нехватает ссылки на оригинал картинки: company.yandex.ru/technologies/datacenter/
Сложно читать код на жаве не имея привычки, но я постарался.
Увидел у вас проблему, что TCP поток может приходить быстрее, чем выгребается очередь. Почитайте, про режим {active,once} в эрланге. Вы тут здорово велосипедов переизобрели.
Увидел у вас проблему, что TCP поток может приходить быстрее, чем выгребается очередь. Почитайте, про режим {active,once} в эрланге. Вы тут здорово велосипедов переизобрели.
кстати, а вы не смотрели в сторону RedDwarf Server? про него как-то писали на хабре, интересно сравнить его возможности и netty.
Это как сравнивать двигатель внутреннего сгорания и готовый автомобиль ))
Netty это сетевая библиотека. А RedDwarf Server это готовый игровой сервер.
Да. Я его смотрел. Мне не очень понравилось. После того как его бросил оракл, после покупки сана, развитие его практически остановилось а самой главной фишки, прозрачного масштабирования, в нем так и не сделали…
Netty это сетевая библиотека. А RedDwarf Server это готовый игровой сервер.
Да. Я его смотрел. Мне не очень понравилось. После того как его бросил оракл, после покупки сана, развитие его практически остановилось а самой главной фишки, прозрачного масштабирования, в нем так и не сделали…
Тоже хотел спросить про то, щупали ли вы RedDwarf. Все-таки, игровой сервер — это далеко не только обработка пакетов. Будет интересно услышать ваше мнение о нем в более развернутом виде (например, статье)
Подробностей не будет, т.к. я не пишу на нем ничего. Я попробовал сделать на нем тестовый проект. Посмотрел как там все делается и мне не понравилось. Плюс последний раз он обновлялся в 2010 году, так что считаю это мертвая разработка. Сановцы просто не успели вывести RedDwarf на нормальный уровень.
У вас совершенно не покрыта проблема возможной блокировки многих клиентов одновременно при ожидании одного из них на sessionQueue.add. Не уверен, что за очередь у вас, но при заполнении подозреваю блокировку. Т.е. я про те ситуации, когда очередь заполняется, например слишком активным/агрессивным клиентом полностью и ваш пул не успевает обрабатывать. Видимо стоит в таких случаях «успокаивать» слишком активных клиентов переводом канала в нечитаемый режим. Кроме того, у вас игнорируется ситуация saturated outbound. Я вполне допускаю, что все это у вас делается за кадром, но из статьи возникает ложное впечатление, что в Netty эти проблемы решаются сами, волшебным образом. Увы, это не так.
Ну, блокировки всех одним не будет, т.к. потоков обрабатывающих sessionQueue.add много. Посмотрю как оно себя поведет при онлайне в 20-30к (если такое получится) ), а пока на паре тысяч клиентов это не заметно. К тому же в сервере есть понятие флуд, для блокировки бессмысленных сообщений и клиентов. Что касается saturated outbound, то я не планировал разложить по полочкам абсолютно все ньюансы работы сервера. На это легко можно пару десятков статей угрохать…
Тут недавно была статья про сервер на Netty. Там была описана обработка пакетов. В каментах меня попросили описать как это я делаю. Я написал.
Хотя в своем цикле статей про мультиплеер игрушку я и планировал затронуть многие аспекты разработки сервера, но не у уверен, что там будет абсолютно все.
P.S. У вас должен быть приличный опыт разработки серверов. Может поделитесь своими соображениями по этому поводу? )
Тут недавно была статья про сервер на Netty. Там была описана обработка пакетов. В каментах меня попросили описать как это я делаю. Я написал.
Хотя в своем цикле статей про мультиплеер игрушку я и планировал затронуть многие аспекты разработки сервера, но не у уверен, что там будет абсолютно все.
P.S. У вас должен быть приличный опыт разработки серверов. Может поделитесь своими соображениями по этому поводу? )
Прошу прощения за оффтопик, но НЕ ПИШИТЕ НА JAVA КЛИЕНТЫ пжлст.
Это оскорбляет ваши религиозные чувства? :)
Нет, они по статистике требуют намного больше костылей чтобы заставить их работать, причём на Linux и Windows костыли разные, ещё и от программы к программе меняются. Возможно это связано со средней кривизной рук джавакодеров, а не с самим языком и системой, не знаю.
2TheShock:
Вы прекрасно осведомлены о десятках возможностей, не заставляйте меня продвигать здесь какую-то одну пжлст.
2TheShock:
Вы прекрасно осведомлены о десятках возможностей, не заставляйте меня продвигать здесь какую-то одну пжлст.
Товарищи, неужели вы думаете что написав бездоказательную, многозначительную ерунду, вы будете выглядеть круто?
1. Причем тут клиенты на java вообще? топик про серверную часть.
2. Где пруфы на статистику, по которой клиент на java требует много костылей.
3. Какие вообще костыли на java клиенте?? Например мои клиенты работают на винде и линухе без проблем и каких бы то ни было костылей.
4. Больше костылей по сравнению с чем?
Может хватить уже писать многозначительную ерунду не по теме?
1. Причем тут клиенты на java вообще? топик про серверную часть.
2. Где пруфы на статистику, по которой клиент на java требует много костылей.
3. Какие вообще костыли на java клиенте?? Например мои клиенты работают на винде и линухе без проблем и каких бы то ни было костылей.
4. Больше костылей по сравнению с чем?
Может хватить уже писать многозначительную ерунду не по теме?
Я не пытаюсь выглядеть круто.
1. Я сразу предупредил что ветка — оффтопик. Странно что вы в оффтопик-ветке спрашиваете какая связь с топиком.
2. Например, форумы Desura, где подавляющее большинство баг.репортов именно про Java.
3. Например, 32 vs 64 bit библиотеки, которые именно в проектах на Java вечно перепутаны.
4. Не хочу ничего здесь рекламировать, да вы и сами прекрасно представляете на чём ещё можно писать игровые клиенты или самостоятельные программы кроме Java. Я надеюсь.
Я предупредил об оффтопике. Не хотите читать не по теме — не читайте. Написанное не является ни многозначительным, ни ерундой.
1. Я сразу предупредил что ветка — оффтопик. Странно что вы в оффтопик-ветке спрашиваете какая связь с топиком.
2. Например, форумы Desura, где подавляющее большинство баг.репортов именно про Java.
3. Например, 32 vs 64 bit библиотеки, которые именно в проектах на Java вечно перепутаны.
4. Не хочу ничего здесь рекламировать, да вы и сами прекрасно представляете на чём ещё можно писать игровые клиенты или самостоятельные программы кроме Java. Я надеюсь.
Я предупредил об оффтопике. Не хотите читать не по теме — не читайте. Написанное не является ни многозначительным, ни ерундой.
1. Ну в принципе да…
2. Большое количество вопросов по Java, связана с тем, что на ней просто большое число людей пишет. И никак не говорит о сложности написания клиентов вообще.
3. Этой проблемы вообще нет. Java NIO не зависит от 32 или 64 платформы. За свою многолетнюю практику столкнулся всего один раз с различиями, когда надо было с железкой напрямую через COM порт общаться. Но что-то не припомню чтобы такое было необходимо в игровом клиенте ) Да и обходилась эта проблем 3-мя строчками кода. Т.е. проблемы то и не было.
4. Спасибо КЭП, мы тут просто не в курсе были, что писать сетевые клиенты можно на чем-то кроме java ))
2. Большое количество вопросов по Java, связана с тем, что на ней просто большое число людей пишет. И никак не говорит о сложности написания клиентов вообще.
3. Этой проблемы вообще нет. Java NIO не зависит от 32 или 64 платформы. За свою многолетнюю практику столкнулся всего один раз с различиями, когда надо было с железкой напрямую через COM порт общаться. Но что-то не припомню чтобы такое было необходимо в игровом клиенте ) Да и обходилась эта проблем 3-мя строчками кода. Т.е. проблемы то и не было.
4. Спасибо КЭП, мы тут просто не в курсе были, что писать сетевые клиенты можно на чем-то кроме java ))
Намного больше, чем что??? И где смотреть статистику? Это я как разработчик явских клиентов интересуюсь. Запасшись, заодно, попкорном в ожидании когда коллеги допилят своего клиента виндового и попытаются начать делать линуксовый вариант :).
А на чём и почему?
Зачем в статье фото ДЦ яндекса?
Первоначально реализовал один из своих клиент-сервер проектов на nio-сокетах, в новом проекте подумываю о Netty для работы с клиентами (так как используются те же самые nio-sockets). Интересно так же мнение по поводу использования Remote Method Invocation и Java Caching System для внутреннего обмена командами(RMI) и данными(JCS) внутри системы в плане масштабируемости системы.
пока недостатком мне видится сложность (и зачастую невозможность) связи с системами на других языках. Потому что-то типа RPC но более открытого.
Использовать RMI внутри чего-то другого будет неимоверно сложно. Это практически устаревшая технология, плохо расчитанная на такие вещи как сети за прокси, многопоточность, множественные загрузчики классов и несколько приложений в рамках одной VM. Можно лишь сделать нечто похожее на RMI.
А где бенчмарки, которые доказывают, что сервер производительный?
Ждём продолжения, с взамодействием с базой, спасибо за статью.
Спасибо, за статью! Вы можете залить картинки на другой хостинг, а то не отображаются.
И вопрос, можно ли привести код, чтобы посмотреть как взаимодействуют эти обработчики. Кто кого вызывает?
Может стоит объединить ProtocolPacketHandler и FrameHandler? Прочитать данные и заголовок и поставить в очередь, а ProtocolPacketHandler замещает ReadQueueHandler.
И вопрос, можно ли привести код, чтобы посмотреть как взаимодействуют эти обработчики. Кто кого вызывает?
Может стоит объединить ProtocolPacketHandler и FrameHandler? Прочитать данные и заголовок и поставить в очередь, а ProtocolPacketHandler замещает ReadQueueHandler.
То есть мне не очень понятно, как повесить эти несколько обработчиков на сокет подключения с клиентом.
Сейчас пишу сервер и решил обратить внимание в сторону netty, проясните пожалуйста.
Сейчас пишу сервер и решил обратить внимание в сторону netty, проясните пожалуйста.
Картинки у всех моих знакомых отображаются нормально, возможно у вас стоит банерорезалка?
Обработчики в netty подключаются элементарно…
bootstrap.setPipelineFactory( new ChannelPipelineFactory()
{
Override
public ChannelPipeline getPipeline() throws Exception
{
ChannelPipeline p = Channels.pipeline();
p.addLast( «connectHandler», connectHandler );
p.addLast( «frameDecoder», packetFramer );
p.addLast( «handler», packetHandler );
return p;
}
});
bootstrap.setPipelineFactory( new ChannelPipelineFactory()
{
Override
public ChannelPipeline getPipeline() throws Exception
{
ChannelPipeline p = Channels.pipeline();
p.addLast( «connectHandler», connectHandler );
p.addLast( «frameDecoder», packetFramer );
p.addLast( «handler», packetHandler );
return p;
}
});
for ( int i = 0; i < this.threadPoolSize; i++ )
{
this.threadPool.execute( this );
}
тут случайно нет опечатки по поводу this и i?
{
this.threadPool.execute( this );
}
тут случайно нет опечатки по поводу this и i?
В целом, совершенно неправы…
Как определили что игровой запрос мапится на запрос в БД?
Из чего получилось ограничение на 2 человека в комнате?
Как определили что игровой запрос мапится на запрос в БД?
Из чего получилось ограничение на 2 человека в комнате?
Ну во первых… что означает ваше «вообще нет проблем с блокировками»?
Блокировками чего?
Блокировками чего?
Все решается точно так же как и в любых других серверах. Проблемы точно такие же как у всех…
С чего вы взяли, что перенос сетевой части в многопоточность, как-то решает эти проблемы?
Многопоточность просто позволяет лучше утилизировать существующие ресурсы железа…
Но не является какой-то панацеей от всех проблем в жизни)
P.S. Походу, вы, как и некоторые коментаторы просто неудосужились почитать статью…
С чего вы взяли, что перенос сетевой части в многопоточность, как-то решает эти проблемы?
Многопоточность просто позволяет лучше утилизировать существующие ресурсы железа…
Но не является какой-то панацеей от всех проблем в жизни)
P.S. Походу, вы, как и некоторые коментаторы просто неудосужились почитать статью…
В статье описывается обработка соединений, про логику там ни слова.
Именно. Так при чем тут проблемы блокировок?
Вы говорите, что понимаете о чем статья, но ваши вопросы говорят об обратном. В статье нет понятия «тик», нет обработки игровой логики… откуда все эти претензии не по теме?
Я Вам задал конкретный вопрос, до этого другие комментаторы его задали ещё в начале 2012 года, но Вы так и не удосужились на него ответить.
Ну вы даете) Разве есть закон по которому я обязан отвечать на все вопросы любого человека? )
А если серьезно, то на вопросы заданные в форме тролинга, считаю нет необходимости отвечать или как-то распространяться на эту тему…
— Где профит вашей архитектуры?
Профит в параллельной обработке пакетов
— Где хранится состояние игрового мира, кто им управляет?
—Для этого есть отдельный сервис, который и управляет им
Более того, открою вам страшную тайну), в реале там кластер и игровой мир размазан по нему.
при чем размазывание происходит динамически и неравномерно)
— Блокировки по всему коду
Прямо таки по всему коду? Голословное утверждение. Хоть один примерчик блокировки покажите…
— Трудность отладки и поддержки кода
Опять голословное утверждение. Какие там проблемы то при отладке и поддержке? нет ничего подобного…
Хотя, если вы джун и у вас очень мало опыта, то да, код кажется сложным)
Очень простой тролинг…
Статья про сетевой обработчик пакетов… а вы у меня находите какие-то блокировки по какому-то «всему коду»… что это за «весь код» такой и почему он должен быть покрыт блокировками, непонятно) при чем все без конкретики, одни эфемерные понятия вроде «весь код» и «блокировки»… хоть бы показали место в коде где будет что-то блокироваться…
А если интересует что-то за рамками статьи, то так и пишие. Мол интересно как у вас другие части проекта работают. А то ваши высказывания выглядят как гадания экстрасенсов, код вы не видели, но утверждаете что он весь покрыт какими-то блокировками…
Ок
Во первых, не вижу причинно следственной связи, а во вторых, блокировка конкретно чего появляется?
Что же это у вас за архитектура такая, что блокировки (может уже поясните наконец, какие ресурсы-то блокируются) висят гроздьями на каждом чихе? И почему они все так влияют друг на друга?
Статья про сетевой обработчик пакетов… а вы у меня находите какие-то блокировки по какому-то «всему коду»… что это за «весь код» такой и почему он должен быть покрыт блокировками, непонятно) при чем все без конкретики, одни эфемерные понятия вроде «весь код» и «блокировки»… хоть бы показали место в коде где будет что-то блокироваться…
А если интересует что-то за рамками статьи, то так и пишие. Мол интересно как у вас другие части проекта работают. А то ваши высказывания выглядят как гадания экстрасенсов, код вы не видели, но утверждаете что он весь покрыт какими-то блокировками…
Сущность игрока, в котором содержится его здоровье.
Ок
Игрока можно атаковать, а значит это уже +1 блокировка.
Во первых, не вижу причинно следственной связи, а во вторых, блокировка конкретно чего появляется?
У игрока есть мана на которую может влиять другой игрок, это ещё +1 блокировка, на игроке висят «эффекты», которые могут отменится другими игроками, это ещё +1 блокировка, На деле такой список в 100 раз больше.
Что же это у вас за архитектура такая, что блокировки (может уже поясните наконец, какие ресурсы-то блокируются) висят гроздьями на каждом чихе? И почему они все так влияют друг на друга?
В общем понятно, очередной минусятор с гипертрофированным ЧСВ…
Раскинул пальцы, жиденько обделался, минусов наставил и в кусты…
Раскинул пальцы, жиденько обделался, минусов наставил и в кусты…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка производительного игрового сервера на Netty + Java