Хотелось бы тут ответить, что люди приходящие в Go — это очень круто, но формат в виде листа кода действительно не подходящий вариант, если эта статья обучающая.
Main loop:
func main() {
ch := make(chan string)
for {
go func(ch)
}
}
Player open connect:
func func(ch chan string) {
text := "Hello, i am Kitty connected"
ch <- text
}
Player loop:
func func(ch chan string) {
for {
if ch != nil {
packet.Write(<- ch)
}
}
}
У вас уже система завязана на массиве, который постоянно дергается, добавляя или удаляя информацию о подключенных персонажах.
Если говорить на словах о том, как бы работала система на каналах, то следующим образом:
Игрок подключается к серверу, для каждого игрока выделяется рутина с каналом, когда соединение создается или разрывается — канал уже заполнен этими данными, а они просто мониторятся в рутине каждого игрока, одновременно при изменении посылая нужный пакет.
Это избавляет вашу систему от бесконечного перебора в доп. рутинах, да еще и с постоянным выделением новой структуры в памяти.
Каналы по своему определению связывают потерявшиеся рутины в просторах процессора, но в тоже время вы создаете некий «notifyClients()», чтобы оповестить других о том, что персонаж подключился к их семье. Каналами начинают думать, когда создается изначальная архитектура сервера, но для этого нужен некий багаж знаний — не постыжусь, но чтобы мыслить этим делом, мне понадобилось около 2 месяцев.
Задать можно, но если проект пишется под кого то с определенными требованиями к производительности и заранее известны мощности платформы, на которой будет размещаться проект — то в окружении это можно упустить очень легко.
В глубину я не изучал работу рутин, разработчики позиционируют, как «Многопоточная модель», из этого делаю обычный вывод => все выполняется параллельно и ничего не происходит «событиями».
Все же «Многопоточность», это Node.js использует «Асинхронную модель».
— Вы не используете каналы, которые очень тесно связаны с потоками в Go и предоставляют основную производительность.
— Вы не используете так нужную переменную GOMAXPROCS для библиотеки WebSocket.
И когда у вас будет обрабатываться огромное количество данных, которые особо не нуждаются в мгновенной обработки, то потом вам придется увеличивать net.core.netdev_max_backlog, но это уже относится больше к тюнингу на будущее.
Главную особенность Go — упрощенное параллельное программирование вы исключили, думается, что причиной этому «не опытность».
Таким образом сервер на node.js отрабатывал бы с минимальным пингом куда больше соединений, чем ваша программа на Go.
Попробуйте откинуть годик другой еще назад, т.е. мысль звучит так: «Первый год мне стукнула крутая мысль, я начал ее реализовывать, изучая все подряд, что мне нужно для этой идеи, а дальше целый год пустоты. Опять же, когда прошло 2 года, я с крутым дизайнером самоучкой начал творить игру и через 4 месяца (Думаю, что это сугубо чистое время разработки или приблизительное) получилась такая игрушка».
Можно сделать простой вывод, данное устройство не требуется вам в очень большой нужде. А в другом смысле я знаю 2 реальных владельцев шилда и не стоит забывать про 4pda, где есть жизнь по поводу этого устройства.
Я к этому и клоню вас, что на данный момент сервер не имеет достаточного уровня покрытия проверками тех или иных пакетов (В зависимости от архитектуры сервера). Но вы написали «У нее проверки реализованы в КЛИЕНТЕ».
UPD: Конечно же это было написано к последнему посту Quanzi.
Если говорить на словах о том, как бы работала система на каналах, то следующим образом:
Это избавляет вашу систему от бесконечного перебора в доп. рутинах, да еще и с постоянным выделением новой структуры в памяти.
Задать можно, но если проект пишется под кого то с определенными требованиями к производительности и заранее известны мощности платформы, на которой будет размещаться проект — то в окружении это можно упустить очень легко.
В глубину я не изучал работу рутин, разработчики позиционируют, как «Многопоточная модель», из этого делаю обычный вывод => все выполняется параллельно и ничего не происходит «событиями».
— Вы не используете каналы, которые очень тесно связаны с потоками в Go и предоставляют основную производительность.
— Вы не используете так нужную переменную GOMAXPROCS для библиотеки WebSocket.
И когда у вас будет обрабатываться огромное количество данных, которые особо не нуждаются в мгновенной обработки, то потом вам придется увеличивать net.core.netdev_max_backlog, но это уже относится больше к тюнингу на будущее.
Таким образом сервер на node.js отрабатывал бы с минимальным пингом куда больше соединений, чем ваша программа на Go.
Это, конечно же, лишь догадки.
UPD: Конечно же это было написано к последнему посту Quanzi.