K
если сервер использует проксирование и на каждый входящий коннект создаёт исходящий (к бекэнду), причём бекэнд сидит на 1 IP, то сервер упрётся в лимит исходящих подключений
Size: a a a
2021 June 28
K
но это уже совсем другая проблема
K
а то что tcp дуплексный вообще не важно
K
главное чтобы эти 4 параметра были уникальны
K
а в какую сторону пакеты ходят не важно от слова совсем
AS
если на клиенте нет активности, можно же нули не слать, просто в данный период подсоединенный клиент не контрибутит в общий сигнал своей активностью. но контрибутит соединением, т.е. 10м ничего не делающих подсоединенных клиентов - дают сигнал = 0, если 1м начнут долбить и давать максимальный сигнал в 1.0, то общий сигнал будет 0.1...
O
Общий сигнал - это твой аггрегат. Каждое хоть какой-то пакет данных от клиента - это пакет, который тебе придется обработать, чтобы достать из него данные. Если у тебя 1м клиентов шлют не-ноли, то согласно твоим таймингом это 4 миллиона пакетов, иными словами - 4 пакета в секунду на активного клиента и на одно, соответственно, соединение.
AS
Да, правильно.
O
То, как твоя логика обрабатывает эти данные, сетевому стеку вообще все равно:)
O
В этом случае мне не очень понятно, зачем вообще держать соединение, в котором ты не гоняешь данные:)
O
Его кстати с шансом дропнет nat где-нить посередине, есть кипаливы не совпадут)
AS
это общий счетчик клиентов.
O
Во, кстати, кипаливы это тоже пакетрейт) Хоть и слать их придется 1 раз в 30 секунд или около того. Но я бы слал почаще, встречаются нервные наты, у которых таймаут короче
AS
дропанет если keepalive не будет слаться, а так - не должен
O
Угу. Но кипаливы - это тоже нагрузка, это ж тоже пакет, который к тебе придет. Хоть и небольшая (относительно). 330krps при отсылке 1 раз в 30 секунд в среднем на 10м клиентов)
GP
ну а если вот такое решение. Данные отправляются одним мессаджем, без постоянного соединения. Это может быть HTTP или даже DNS запрос. При каждом новом блоке данных где-то откладывается запись и обновляется ее TTL (например в redis). Теперь мы знаем, что если кто-то достаточно долго не присылает пакеты, то записи протухнут, и клиент как бы уйдет в офлайн.
AS
подожди, давай немного назад отмотаем. Из вышесказанного - я неправильно понимаю как работает websocket, да ? т.е. нету никакого физического ограничения на количество Websocket соединений К одному серверу с разных клиентов, даже если вебсокет это двунаправленное соединение и по нему сервер может отправить ответ ( это исходящее соединение, когда сервер стучится в нат-->клиента или это просто переиспользуется как-то существующее ?)
K
направление передачи данных не важно. важна только уникальность tuple local ip : local port : remote ip : remote port
K
при передаче в другую сторону просто local и remote меняются местами)
K
и да, сервер УЖЕ использует только один порт