Взаимодействие с сервером производится через вебсокеты таким образом: клиент подписывается на какие-то события, а потом они к нему сыплются с сервака в виде JSON-посылок. Объектов, которые генерят события, на которые можно подписаться — порядка нескольких тысяч. Некоторые события могут сыпаться довольно часто — к примеру, до нескольких раз в секунду. Но могут и не часто.
В протоколе прописано ограничение — не больше 32х соединений с одного адреса. Хорошо, сервак не тянет больше. Стал реализовывать — и что-то вот в упор не вижу смысла иметь больше одного соединения. У меня обмен идет до провайдера по 100 мегабитам, там дальше хз, но тоже вроде не особо тупит.
Надежность? Так если одно соединение отвалилось, то и остальные скорее всего отвалятся. Латентность? Так вроде у кучи соединений как раз хуже будет, не? Да и протокол по сути потоковый, какая тут латентность?
Простота реализации клиента? По мне — так проще либо одно соединение на все объекты, либо по соединению на каждый. Иначе — геммор с тем, что разбираться что отвалилось и какие подписки были через отвалившееся соединение.
А, ну да. Теоретически оно может работать через мобильный интернет. Может смысл в том, что дублировать подписки по нескольким соединениям, и держа несколько неактивных наготове — если соединение отвалилось — то активируем другое, и подписываемся на всё через него — может новую соту найдёт, и отдуплится быстрее, чем старое прочухает, что оно померло?
Здравствуйте, Marty, Вы писали:
M>Надежность? Так если одно соединение отвалилось, то и остальные скорее всего отвалятся. Латентность? Так вроде у кучи соединений как раз хуже будет, не? Да и протокол по сути потоковый, какая тут латентность?
Ну в принципе, если у тебя много параллельных TCP-соединений, то 1) можно отжать больший процент полосы пропускания, чем это получится сделать у одного соединения 2) пока одно соединение, потеряв пакет, занято ретрансмитом, остальные остаются доступными.
Но все это вряд ли тебе нужно. Так что не парься, и используй одно соединение, особенно если тебе так удобнее.
Re: Зачем может быть нужно несколько параллельных соединений?
Из одной страницы открывать несколько соединений — не представляю зачем. Я даже не уверен, что в мире победившего HTTP/2 браузер вообще откроет ещё соединения, скорей всего TCP-соединение будет одно, а wss-соединения будут как бы виртуальными. Но не пробовал.
А так — во-первых пользователь может открыть несколько табов в браузере и каждый таб откроет своё соединение. Хотя 32 таба это, конечно, довольно много, но всё же. Во-вторых пользователи могут сидеть через NAT и тут ваше ограничение в 32 соединения на IP может оказаться фатальным.
Re: Зачем может быть нужно несколько параллельных соединений?
M>Есть еще какие-нибудь варианты?
Ты индусский код видел? А бывает такой же сетевой код Понадобилось подписаться — нашли пример на SO. Понадобилось подписаться на что-то ещё — скопипастили пример ещё раз. Одно действие = один вебсокет. Для спасения интернета от таких, внутри .NET даже для просто HTTP, весьма замороченная архитектура, в которой кодер делает "просто запрос", а там внутри отслеживается сколько уже открытых коннектов к тому же серверу, и переиспользуются по возможности.
Re[2]: Зачем может быть нужно несколько параллельных соединений?
M>>Надежность? Так если одно соединение отвалилось, то и остальные скорее всего отвалятся. Латентность? Так вроде у кучи соединений как раз хуже будет, не? Да и протокол по сути потоковый, какая тут латентность?
Pzz>Ну в принципе, если у тебя много параллельных TCP-соединений, то 1) можно отжать больший процент полосы пропускания, чем это получится сделать у одного соединения
А какой-нибудь Quality of Service по дороге не будет зажимать все мои соединения, если они пучком пойдут? Когда инет был молодым — возможно это и сработало бы. Но моему протоколу лет пять где-то, от силы
Pzz>2) пока одно соединение, потеряв пакет, занято ретрансмитом, остальные остаются доступными.
Наверное, это актуально для мобильного инета, не? Для проводного тут вряд ли какой-то ощутимый выигрыш будет?
Pzz>Но все это вряд ли тебе нужно. Так что не парься, и используй одно соединение, особенно если тебе так удобнее.
Ну, я так и решил. Просто хочется понять логику разработчиков протокола. Может я что-то очевидное упустил, как обычно
Здравствуйте, vsb, Вы писали:
vsb>Из одной страницы открывать несколько соединений — не представляю зачем. Я даже не уверен, что в мире победившего HTTP/2 браузер вообще откроет ещё соединения, скорей всего TCP-соединение будет одно, а wss-соединения будут как бы виртуальными. Но не пробовал.
А причем тут браузер?
Вебсокеты нынче не только в браузере, и вроде уже довольно давно. Потому что они пролезают в игольное ушко ограничений всего, кроме HTTP/HTTPS.
vsb>А так — во-первых пользователь может открыть несколько табов в браузере и каждый таб откроет своё соединение. Хотя 32 таба это, конечно, довольно много, но всё же.
Причем тут бравзер и его табы?
vsb>Во-вторых пользователи могут сидеть через NAT и тут ваше ограничение в 32 соединения на IP может оказаться фатальным.
И опять не понял. За NAT'ом могут сидеть тыщи пользователей.
Здравствуйте, hi_octane, Вы писали:
M>>Есть еще какие-нибудь варианты? _>Ты индусский код видел? А бывает такой же сетевой код Понадобилось подписаться — нашли пример на SO. Понадобилось подписаться на что-то ещё — скопипастили пример ещё раз. Одно действие = один вебсокет. Для спасения интернета от таких, внутри .NET даже для просто HTTP, весьма замороченная архитектура, в которой кодер делает "просто запрос", а там внутри отслеживается сколько уже открытых коннектов к тому же серверу, и переиспользуются по возможности.
Разрабы протокола — русские из России, и в не последней конторе работают
Здравствуйте, Marty, Вы писали:
Pzz>>Ну в принципе, если у тебя много параллельных TCP-соединений, то 1) можно отжать больший процент полосы пропускания, чем это получится сделать у одного соединения
M>А какой-нибудь Quality of Service по дороге не будет зажимать все мои соединения, если они пучком пойдут? Когда инет был молодым — возможно это и сработало бы. Но моему протоколу лет пять где-то, от силы
Где-то по-дороге тебе дадут дырку такого-то размера. Причем скорее всего, не тебе лично, а целому классу таких, как ты. Но TCP — протокол вежливый, нащупав границы дырки, он попытается подвинуться, чтобы и соседям дышать не мешать. А если у тебя куча TCP-соединений, то вместе вы — сила.
Pzz>>2) пока одно соединение, потеряв пакет, занято ретрансмитом, остальные остаются доступными.
M>Наверное, это актуально для мобильного инета, не? Для проводного тут вряд ли какой-то ощутимый выигрыш будет?
В Интернете есть много причин пакетам теряться. И это не только потери в радиоэфире. Более того, у роутера по дороге может и не быть другого способа притормозить твой передатчик, кроме как дропнуть пакетик-другой; ECN работает далеко не всегда.
У нормально работающего интернета где-то 1% пакетов теряется.
Pzz>>Но все это вряд ли тебе нужно. Так что не парься, и используй одно соединение, особенно если тебе так удобнее.
M>Ну, я так и решил. Просто хочется понять логику разработчиков протокола. Может я что-то очевидное упустил, как обычно
Ну как можно сказать, не зная протокола и не видя, как он используется?
Может, там таким образом организована приоритезация сообщений (чтобы пока по одному сокету лезет бегемот, по другому можно было передать срочную команду пристрелить бегемота по прибытию). А может, там работала команда из 16-и человек, и каждый себе завел по паре сокетов.
Re[3]: Зачем может быть нужно несколько параллельных соединений?
M>Разрабы протокола — русские из России, и в не последней конторе работают
Так ограничение как раз и защищает разрабов серверов от нерадивых клиентов. Или они же и клиент пишут?
Re[4]: Зачем может быть нужно несколько параллельных соединений?
Здравствуйте, Pzz, Вы писали:
M>>А какой-нибудь Quality of Service по дороге не будет зажимать все мои соединения, если они пучком пойдут? Когда инет был молодым — возможно это и сработало бы. Но моему протоколу лет пять где-то, от силы
Pzz>Где-то по-дороге тебе дадут дырку такого-то размера. Причем скорее всего, не тебе лично, а целому классу таких, как ты. Но TCP — протокол вежливый, нащупав границы дырки, он попытается подвинуться, чтобы и соседям дышать не мешать. А если у тебя куча TCP-соединений, то вместе вы — сила.
Так QoS вроде и задуман был, как надсмотрщик над чрезмерно вежливым TCP, когда каждый хитрожопый софт открывал кучу соединений и за счёт этого получал преимущество. Такая хитрожопость вроде вымерла ещё в середине нулевых, не?
Pzz>В Интернете есть много причин пакетам теряться. И это не только потери в радиоэфире. Более того, у роутера по дороге может и не быть другого способа притормозить твой передатчик, кроме как дропнуть пакетик-другой; ECN работает далеко не всегда.
Трафик-то в итоге что по пачке соединений, что по одному — примерно тот же. Это если не дублировать подписки на события на нескольких соединениях. А если дублировать — то только трафика кратно больше, и дропаться будет также кратно больше
Pzz>Ну как можно сказать, не зная протокола и не видя, как он используется?
Pzz>Может, там таким образом организована приоритезация сообщений (чтобы пока по одному сокету лезет бегемот, по другому можно было передать срочную команду пристрелить бегемота по прибытию).
Да вроде нет никаких бегемотов. Посылки байт по 200-300 все. Никаких команд по отстрелу бегемотов в протоколе нет. Есть относительно редкие и не самые важные события, но они редки и не жирны.
Pzz>А может, там работала команда из 16-и человек, и каждый себе завел по паре сокетов.
На поддержке (и возможно развитии) вроде пара-тройка человеков. Один даже отвечал, пока я его своей глупостью не задолбал
Здравствуйте, hi_octane, Вы писали:
M>>Разрабы протокола — русские из России, и в не последней конторе работают _>Так ограничение как раз и защищает разрабов серверов от нерадивых клиентов. Или они же и клиент пишут?
Здравствуйте, Marty, Вы писали:
vsb>>Во-вторых пользователи могут сидеть через NAT и тут ваше ограничение в 32 соединения на IP может оказаться фатальным. M>И опять не понял. За NAT'ом могут сидеть тыщи пользователей.
И все они будут с одного IP адреса. Первым 32 повезет.
Re[4]: Зачем может быть нужно несколько параллельных соединений?
Здравствуйте, /aka/, Вы писали:
vsb>>>Во-вторых пользователи могут сидеть через NAT и тут ваше ограничение в 32 соединения на IP может оказаться фатальным. M>>И опять не понял. За NAT'ом могут сидеть тыщи пользователей.
A>И все они будут с одного IP адреса. Первым 32 повезет.
Здравствуйте, vsb, Вы писали:
vsb>Из одной страницы открывать несколько соединений — не представляю зачем. Я даже не уверен, что в мире победившего HTTP/2 браузер вообще откроет ещё соединения, скорей всего TCP-соединение будет одно, а wss-соединения будут как бы виртуальными. Но не пробовал.
В HTTP/2 нет вебсокетов. И HTTP/2, и Websocket начинаются как HTTP/1.1, и превращаются в то, во что они превращаются, через Protocol Upgrade:
Здравствуйте, Pzz, Вы писали:
vsb>>Из одной страницы открывать несколько соединений — не представляю зачем. Я даже не уверен, что в мире победившего HTTP/2 браузер вообще откроет ещё соединения, скорей всего TCP-соединение будет одно, а wss-соединения будут как бы виртуальными. Но не пробовал.
Pzz>В HTTP/2 нет вебсокетов. И HTTP/2, и Websocket начинаются как HTTP/1.1, и превращаются в то, во что они превращаются, через Protocol Upgrade:
Pzz> HTTP/1.1 -> Upgrade -> HTTP/2 Pzz> HTTP/1.1 -> Upgrade -> Websocket.
Pzz>Т.е., они существуют параллельно друг другу.
Посмотрел из любопытства, для Go нет работающей реализации. Если учесть, что поддержка HTTP в Go находится на переднем рубеже науки, то видимо, в других языках с этим не сильно лучше.
Re: Зачем может быть нужно несколько параллельных соединений?
Здравствуйте, Marty, Вы писали:
M>Надежность? Так если одно соединение отвалилось, то и остальные скорее всего отвалятся. Латентность? Так вроде у кучи соединений как раз хуже будет, не? Да и протокол по сути потоковый, какая тут латентность?
См.: "head-of-line blocking".
Понадобилось подписаться — нашли пример на SO. Понадобилось подписаться на что-то ещё — скопипастили пример ещё раз. Одно действие = один вебсокет. Для спасения интернета от таких, внутри .NET даже для просто HTTP, весьма замороченная архитектура, в которой кодер делает "просто запрос", а там внутри отслеживается сколько уже открытых коннектов к тому же серверу, и переиспользуются по возможности.
