Телеграмм чат группы js_ru страница 11401

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

JavaScript — русскоговорящее сообщество

5307 membersпожаловаться на группу

2020 August 21

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Понятно. Современные браузеры с тобой только не согласятся https://chromium.googlesource.com/chromium/src/net/+/master/socket/client_socket_pool_manager.cc

Вбей в поиск на выше приведенной странице "Limit of sockets of each socket pool"

Даже если их вдруг 300 станет возможно сделать, речь не об этом, а о подходе.

Будет несколько пулов, это не проблема

источник

01:30пожаловаться #1

N

Nau in JavaScript — русскоговорящее сообщество

Будет несколько пулов, это не проблема

В рамках одной вкладки более 256 соединений не позволяет браузер завести. Он будет грохать в порядке очереди предыдущие соединения, когда станут появляться новые, можешь проверить сам.

Но речь не об этом

источник

01:32пожаловаться #2

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Nikolai Reguliarniy

Через один сокет можно передать все данные. Если нужно поднимать даже 2, то явно неправильно спроектирован формат обмена между бэком и фронтом

Я бы не делал такие заявления не зная архитектуры проекта. Может там датчики, и на каждый поднимается свое соединение. Мультиплексирования эти данные на бэке и следить за статусами может быть сложнее чем на фронте

источник

01:33пожаловаться #3

🦜

🦜 in JavaScript — русскоговорящее сообщество

Я бы не делал такие заявления не зная архитектуры проекта. Может там датчики, и на каждый поднимается свое соединение. Мультиплексирования эти данные на бэке и следить за статусами может быть сложнее чем на фронте

Если есть датчик, то есть и уникальный идентификатор, соот эту информацию можно гонять по одному каналу

источник

01:36пожаловаться #4

KS

Konstantin Sedykh in JavaScript — русскоговорящее сообщество

ну если данные никак не взаимосвязанны, то возможно такой подход и прокатит. но всё равно нагрузка на бэк будет конечно некислая.

источник

01:36пожаловаться #5

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Если есть датчик, то есть и уникальный идентификатор, соот эту информацию можно гонять по одному каналу

А заодно нужно будет гонят статус соединения между датчиком и сервером, вместо того чтоб просто Вебсокет с клиентом разорвать. И реализовать удаленное соединение с датчиком через вебсокет тоже придется

источник

01:37пожаловаться #6

NR

Nikolai Reguliarniy in JavaScript — русскоговорящее сообщество

Я бы не делал такие заявления не зная архитектуры проекта. Может там датчики, и на каждый поднимается свое соединение. Мультиплексирования эти данные на бэке и следить за статусами может быть сложнее чем на фронте

И эта сложность перемещается с бэка на фронт. Отлично придумано(сарказм)

источник

01:37пожаловаться #7

🦜

🦜 in JavaScript — русскоговорящее сообщество

А заодно нужно будет гонят статус соединения между датчиком и сервером, вместо того чтоб просто Вебсокет с клиентом разорвать. И реализовать удаленное соединение с датчиком через вебсокет тоже придется

Статус можно и без этого чекать

источник

01:38пожаловаться #8

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Nikolai Reguliarniy

И эта сложность перемещается с бэка на фронт. Отлично придумано(сарказм)

Потому что бэкенд лучше делать стейтлес, а фронт стейтфул

источник

01:38пожаловаться #9

🦜

🦜 in JavaScript — русскоговорящее сообщество

Называется keep a live

источник

01:38пожаловаться #10

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Называется keep a live

У тебя будет статус только между клиентом и сервером. Для статуса между сервером и датчиком дополнительные данные нужно слать

источник

01:39пожаловаться #11

🦜

🦜 in JavaScript — русскоговорящее сообщество

У тебя будет статус только между клиентом и сервером. Для статуса между сервером и датчиком дополнительные данные нужно слать

Датчик без клиента может накопить пакет событий

источник

01:39пожаловаться #12

N

Nau in JavaScript — русскоговорящее сообщество

Konstantin Sedykh

ну если данные никак не взаимосвязанны, то возможно такой подход и прокатит. но всё равно нагрузка на бэк будет конечно некислая.

Есть датчики и идентификаторы к ним на бэке всё так. И нагрузка там будет существенная, чтобы свести к одному каналу, да

Однако ограничения ресурсной мощности на фронте с его браузером куда больше , чем на бэке

+ на бэке больше возможностей масштабирования этой мощности, горизонтально и вертикально.

источник

01:39пожаловаться #13

🦜

🦜 in JavaScript — русскоговорящее сообщество

При восстановлении системы отправить его

источник

01:39пожаловаться #14

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Датчик без клиента может накопить пакет событий

Ты всё равно должен сообщить клиенту что связь с датчиком пропала

источник

01:40пожаловаться #15

🦜

🦜 in JavaScript — русскоговорящее сообщество

Ты всё равно должен сообщить клиенту что связь с датчиком пропала

Думаю, у датчиков есть на этот счёт свои механизмы

источник

01:41пожаловаться #16

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

Но клиент об этом не сможет узнать, потому что через 1 веб сокет идёт информация от многих устройств

источник

01:42пожаловаться #17

N

Nau in JavaScript — русскоговорящее сообщество

Но клиент об этом не сможет узнать, потому что через 1 веб сокет идёт информация от многих устройств

1 сокет почему не может дать информацию, что такой-то датчик отвалился?

Не понимаю логики, почему через 1 канал ровно ту же информацию, на твой взгляд, не передать на клиент

источник

01:44пожаловаться #18

S🛸

Sergey 🛸 in JavaScript — русскоговорящее сообщество

1 сокет почему не может дать информацию, что такой-то датчик отвалился?

Не понимаю логики, почему через 1 канал ровно ту же информацию, на твой взгляд, не передать на клиент

Может, но тебе уже придется реализовать Вебсокет через вебсокет

источник

01:45пожаловаться #19

N

Nau in JavaScript — русскоговорящее сообщество

Может, но тебе уже придется реализовать Вебсокет через вебсокет

Зачем? Пришло на фронт сообщение с информацией по набору датчиков, один из них отвалился. Узнаем на фронте, что один датчик отвалился из этого сообщения - выводим результат на экран.

Не знаю, что такое "веб сокет через веб сокет", честно говоря. Может не вполне тебя понимаю

источник

01:48пожаловаться #20