- kvakvs
- Постоялец
Easy
> По сути разные приложения обычно, подключается сокет к логин серверу, а после
> авторизации как подключится к Серверу Мира. вот каким образом?
Логин сервер сообщает, что авторизация прошла успешно, пишет в базу (или в мемкеш) случайно созданный уникальный ключ сессии, сообщает его клиенту, и просит клиента переподключиться на новый заданный хост:порт. Вот и все дела, всё как в web.
> И например чат сервер отдельно если то как он с игровым сервером связывается,
> тоже через сокет или есть другие механизмы о которых я не подозреваю и мне
> нужно погуглить)
Есть целый ряд межпроцессных механизмов взаимодействия. Разные локал ТСР сокеты, юникс сокеты, очереди сообщений, шаред память, итд. Погугли boost::interprocess к примеру, всё то же есть и в яве я уверен. А если сервер у тебя маленький и всё в одном процессе, то и проблема такая не возникнет.
Я что то даже не подумал о таком способе... Я думал что логин сервер в роли прокси будет ))
Спасибо всем за помощь, пока с этим более менее разобрался)) Буду пытаться архитектуру продумать сервера, хотя сложно не знаю что за игра :)
от сервера нужна стабильность и грузоподъёмность
упереться в I/O bound проще чем в CPU bound, хотя такое тоже бывает т.к. определяется фактически пиковой нагрузкой на одно ядро, а если у тебя восьмиядерник, то и там и ядро более дохлое, нежели в кваде, и тем более в дуо
Easy
> не знаю что за игра
грузоподъёмность сильно зависит от игры : )
Sh.Tac.
> от сервера нужна стабильность и грузоподъёмность
> упереться в I/O bound проще чем в CPU bound, хотя такое тоже бывает т.к.
> определяется фактически пиковой нагрузкой на одно ядро, а если у тебя
> восьмиядерник, то и там и ядро более дохлое, нежели в кваде, и тем более в дуо
То есть всё таки скорей всего одного потока всё же хватит, но чем больше ядер, а соответственно частота одного ядра ниже тем больше шансов что всё таки нужно будет разделить на потоки? Или я не правильно вас понял?
Но опять же, в последнем примере я сделал сокеты в одном потоке ядро обработку пакетов и все игровые вычисления соответственно в другом.
То есть у меня получается основной процесс просто запускает ещё два, и того три, но первый не чего не делает больше)
Можно например в основном потоке вести лог, добавлять из двух потоков в буфер строки а первый поток их будет сохранять в файл или базу.
Easy
> все игровые вычисления соответственно в другом
вот это кандидат на CPU bound, и сериализация
сама сеть CPU не жрёт практически, тока I/O
>чем больше ядер, а соответственно частота одного ядра ниже тем больше шансов что всё таки нужно будет разделить на потоки?
об этом надо задумываться изначально т.к. потом бывает уже поздно
но это касается только логики и областей видимости
если, например, не бить мир на части и не контролировать видимости, то трафик получается тупо квадратичным от числа юзеров и CPU может загнуться от одной лишь сериализации, если I/O не загнётся раньше
если игра комнатная, то проблем обычно не бывает, см. World of Tanks с его мегарекордами : )
Игра будет комнатная. Игроков например 5 на 5 или 10 на 10. Ну не совсем комнатная, типа мини стратегии но вся карта будет укладываться в экран.
Sh.Tac.
> но это касается только логики и областей видимости
не совсем понял, областей видимости на карте?
Я не представляю как можно разбить в отдельные потоки ировой мир, в отдельные сервера представляю для кластерной системы а вот в отдельные потоки обработку мира не знаю как)
Хотя... Если рабить на части по опкодам... типа такой то в том потоке, а этот в этом, так повысится производительность? (ну конечно надо продумать какие опкоды чаще параллельно обрабатывать нужно...)
Я так понимаю если у меня три потока, а процессор 4х ядерный то одно ядро вообще бдет простаивать относительно данного приложения?
Easy
> не совсем понял, областей видимости на карте?
видимости в игре, ну если ограничена экраном и нет долгоиграющих перемещений по глобальной карте замечательно
> Если рабить на части по опкодам
есть два подхода:
1) разбиваем на сервисы, сервис это поток или процесс который умеет делать что-то одно
2) разбиваем на игровые зоны, каждая зона обслуживается потоком или процессом который умеет всё
процессы предпочтительнее потому как масштабируются горизонтально
Ясно, спасибо за подсказку.
Назрел новый вопрос)) В яве тред - процесс или или поток, я так понимаю что поток всё же... А процессы там есть? Гугл толком не ответил, так как треды некоторые процессами называют некоторые потоками. А в книге написано только потоки)
> Хотя... Если рабить на части по опкодам...
Бредятина ) Самый простой вариант: 1 комната = 1 отдельный процесс, либо поток.
> Я так понимаю если у меня три потока, а процессор 4х ядерный то одно ядро
> вообще бдет простаивать относительно данного приложения?
Easy, я последний раз повторю, что оптимизация в твоём случае - это пустая трата времени. Больше этот вопрос поднимать не буду )
> В яве тред - процесс или или поток, я так понимаю что поток всё же... А
> процессы там есть?
Процесс = отдельно запущенное приложение.
slava_mib
> Бредятина ) Самый простой вариант: 1 комната = 1 отдельный процесс, либо поток.
На одну комнату от 2 до 10 чел максимум будет. Получится слишком много процессов, грубо говоря максимум (коли чел ) / 2
Ну ещё вопросик)
Клиент флеш, что лучше свой протокол, или юзать АМФ от флеша.
Свой будет типа
2 байта версия
2 байта опкод
2 байта данные если есть дополнительные
Я думаю использовать свой лучше, так как то что нужно и не чего лишнего.
AMF это читай нативная сериализация для флеша, т.е. вроде бы самая быстрая
любой самопальный разбор пакета на флеше по определению должен быть хуже : )
Я спросил про то что для сервера лучше)
Я считаю что 1 миллисекунда для клиента не заметна, если она на сервере нагрузит, а вот по 1 миллисекунде на 10к клиентов например на сервере, это уже долго :)
Я считаю что на сервере сделать разбор амф, которым предполагается передавать просто XML а потом соответственно ещё и хмл распарсить, это не оправданная нагрузка) трафик + память + процессорное время разьве не пострадает у сервера?
Лучше уэ у клинта нагрузить немного тем более функция readUTF и у явы сама читает размер + текст и того на флеше пишем
writeShort(1); //протокол
writeShort(1); //опкод
writeShort(20); //длинна доп данных
writeUTF("Юзер"); //запишется в сокет 2 байта длинна строки то есть 8, так как утф и сама строка
writeUTF("Пасс"); //см выше
а прочесть можно просто
buf.position = 6; //откуда читать данные 2 + 2 + 2
var login:String = buf.readUTF(); //само прочтёт длину + строку
var pass:String = buf.readUtf(); //прочтёт следующую строку
функции так же сделаны разработчиками адоба) так что не думаю что они тормозят сильно.
для всего этого можно сделать удобную обёртку.
Вот небольшая демонстрация мысли
https://bitbucket.org/rualex/fserverclient/src/eb8b70481486/ServerTest.as
но код в отличи от XML + AMF сокращается сильно...
Или всё таки я не прав, и лучше юзать то что предлагает напарник?
Easy
Если не трудно, сделай тест: для AMF, custom plain binary, и protobuf протокола скорость разбора, удивишься, ну и выложи графики
Трудно ) не когда не умел делать точные тесты)
Тем более АМФ на яве) надо ещё написать либу для чтения амф)
Уточню ещй раз, я так понял из вашего высказывания АМФ работает во флеше быстрей, так вот я спросил про то что для сервер а лучше? Клиентская игра в пару метров не пострадает из за пары миллисекунд, а пакеты предполагаются частые. И пара миллисекунд для сервера умноженная на кол клиентов - вот это меня интересует, сейчас порою либы амф для явы, для питона нашел) но как проверит скорость не знаю)
Тема в архиве.