Информация об изменениях

Сообщение Re[2]: Сетевая структура от 01.08.2019 6:34

Изменено 01.08.2019 7:04 AlexGin

Re[2]: Сетевая структура
Здравствуйте, уважаемый Mr.Delphist, спасибо за попытки помочь и за подсказки!

Вы писали:

MD>А почему не используются IGMP и мультикасты?


В данном случае, просматривая инфу по IGMP:
https://ru.wikipedia.org/wiki/IGMP

Я не увидел возможности применения данной технологии в нашем продукте:
-видеопотока у нас нет. Сам по себе объем данных, у нас меньше, чем при видеопотоке;
-все данные, курсирующие по сети, достаточно критичны (в т.ч. и к потере пакетов), посему — реализовал идею полного отказа от UDP канала (полностью всё на TCP);
-сама по себе разбивка юзеров на группы неочевидна. Также, (пока?) нет очевидности в необходимости наличия самих пользовательских групп.

MD>Можно решать по-разному:

MD>* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет

Идея интересная, но закрытие сокета не предусмотрено. У меня постоянный канал между сервером и клиентом.

MD>* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)


Также интересно.
Re[2]: Сетевая структура
Здравствуйте, уважаемый Mr.Delphist, спасибо за попытки помочь и за подсказки!

Вы писали:

MD>А почему не используются IGMP и мультикасты?


В данном случае, просматривая инфу по IGMP:
https://ru.wikipedia.org/wiki/IGMP

Я не увидел возможности применения данной технологии в нашем продукте:
-видеопотока у нас нет. Сам по себе объем данных, у нас меньше, чем при видеопотоке;
-все данные, курсирующие по сети, достаточно критичны (в т.ч. и к потере пакетов), посему — реализовал идею полного отказа от UDP канала (полностью всё на TCP);
-сама по себе разбивка юзеров на группы неочевидна. Также, (пока?) нет очевидности в необходимости наличия самих пользовательских групп.

MD>Можно решать по-разному:

MD>* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет

Идея интересная, но закрытие сокета не предусмотрено. У меня постоянный канал между сервером и клиентом.

MD>* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)


Также интересно.

P.S. На хабре есть интересные метареалы:
https://habr.com/ru/post/217585/#Multicast_Basics

Но, повторюсь, пока применеие на практике всего этого в моём текущем проекте, IMHO, не очевидно.