A
А сервак вовки не раздаешь, случаем?
Size: a a a
2020 May 30
AZ
А сервак вовки не раздаешь, случаем?
нет
AZ
все клиенты качают, серваки никому не нужны на торрентах
A
Там мб ператку какую
AZ
так я про пиратку и речь. лицуха вроде давно не утекала :)
AZ
Если утекала вообще
/¯
ох блять на свою голову превратил приложение в акторный ад
эвент луп из семи залуп?
AZ
эвент луп из семи залуп?
да я просто не совсем понимаю, хорошо я сделал или нет
A
эвент луп из семи залуп?
In sevrn weeks
A
Т-34 85
но говорят, что там песдец
Да
A
Хотя я вот ору с чуваков из соседнего отдела которые грят шо юзат Go для хайлоада)
/¯
Еще скажи что у него там есть exactly-once-delivery гарантия
in-process же
AZ
Могу обьяснить подробнее:
Есть условно игровая сессия. Она является актором и у неё есть состояние. Состояние описывается с помощью fsm.
Помимо своего собственного состояния сессия имеет внутренние подсистемы, которые тоже имеют своё собственное внутреннее состояние - например, статистика сессии, управление хуергой какой-нибудь и так далее. Эти вещи тоже, где можно, выражены через FSM и тоже представлены акторами.
Сессия подписана на ивенты, как-то на них реагирует. Но сама реакция заключается также в том, что сессия этот ивент отправляет подсистемам. И тут начинается веселье.
1) Сессия не должна начинать обрабатывать ивенты, пока подсистемы не завершат обработку ивента
2) Подсистемы помимо общения со своей сессией (которая по сути менеджер для них) также могут слать ивенты друг другу (например игрок ливнул и надо обнулить его статистику - посылаем ивент). И тут мне уже надо городить в акторах-подсистемах вместо обычного синхронного вызова хуергу вида "Отправил ивент - переключаемся в режим ожидания результата - если отрицательный ответ пришёл, то роллбэчимся"
3) Как завершим работу - надо пингануть менеджер, что мол всё ок и можешь подавать нам следующий ивент. А если ивент пришёл на обработку не одной подсистеме, а нескольким - как узнать, сколько подсистем менеджеру ждать? Это вкодивать уже надо как-то для каждого отдельного ивента, а мне это не нравится
Вот пока что над этим думаю
Есть условно игровая сессия. Она является актором и у неё есть состояние. Состояние описывается с помощью fsm.
Помимо своего собственного состояния сессия имеет внутренние подсистемы, которые тоже имеют своё собственное внутреннее состояние - например, статистика сессии, управление хуергой какой-нибудь и так далее. Эти вещи тоже, где можно, выражены через FSM и тоже представлены акторами.
Сессия подписана на ивенты, как-то на них реагирует. Но сама реакция заключается также в том, что сессия этот ивент отправляет подсистемам. И тут начинается веселье.
1) Сессия не должна начинать обрабатывать ивенты, пока подсистемы не завершат обработку ивента
2) Подсистемы помимо общения со своей сессией (которая по сути менеджер для них) также могут слать ивенты друг другу (например игрок ливнул и надо обнулить его статистику - посылаем ивент). И тут мне уже надо городить в акторах-подсистемах вместо обычного синхронного вызова хуергу вида "Отправил ивент - переключаемся в режим ожидания результата - если отрицательный ответ пришёл, то роллбэчимся"
3) Как завершим работу - надо пингануть менеджер, что мол всё ок и можешь подавать нам следующий ивент. А если ивент пришёл на обработку не одной подсистеме, а нескольким - как узнать, сколько подсистем менеджеру ждать? Это вкодивать уже надо как-то для каждого отдельного ивента, а мне это не нравится
Вот пока что над этим думаю
CC
А потом смаком собирать его
Ты видимо вообще все смаком собираешь)
AZ
Ты видимо вообще все смаком собираешь)
такое себе увлечение, если честно :)
A
Может ли всемогущая сущность(где под всемоущестью подразумевает возможность создания чего угодно, либо модификация чего угодно в произвольных количествах) создать нечто, что невозможно изменить этой всемогущей сущностью?
В рике и Морти это помню было
CC
В рике и Морти это помню было
Там в последней серии Рик пиздился с богом