Сообщение Re[2]: Сетевая структура от 01.08.2019 6:34
Изменено 01.08.2019 6:46 AlexGin
Re[2]: Сетевая структура
Здравствуйте, уважаемый Mr.Delphist, Вы писали:
MD>А почему не используются IGMP и мультикасты?
В данном случае, просматривая инфу по IGMP:
https://ru.wikipedia.org/wiki/IGMP
Я не увидел возможности применения данной технологии в нашем продукте:
-видеопотока у нас нет. Сам по себе объем данных, у нас меньше, чем при видеопотоке;
-все данные, курсирующие по сети, достаточно критичны (в т.ч. и к потере пакетов), посему — реализовал идею полного отказа от UDP канала (полностью всё на TCP);
-сама по себе разбивка юзеров на группы неочевидна. Также, (пока?) нет очевидности в необходимости наличия самих пользовательских групп.
MD>Можно решать по-разному:
MD>* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет
Идея интересная, но закрытие сокета не предусмотрено. У меня постоянный канал между сервером и клиентом.
MD>* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)
Также интересно.
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 разруливает, например)
Также интересно.
Вы писали:
MD>А почему не используются IGMP и мультикасты?
В данном случае, просматривая инфу по IGMP:
https://ru.wikipedia.org/wiki/IGMP
Я не увидел возможности применения данной технологии в нашем продукте:
-видеопотока у нас нет. Сам по себе объем данных, у нас меньше, чем при видеопотоке;
-все данные, курсирующие по сети, достаточно критичны (в т.ч. и к потере пакетов), посему — реализовал идею полного отказа от UDP канала (полностью всё на TCP);
-сама по себе разбивка юзеров на группы неочевидна. Также, (пока?) нет очевидности в необходимости наличия самих пользовательских групп.
MD>Можно решать по-разному:
MD>* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет
Идея интересная, но закрытие сокета не предусмотрено. У меня постоянный канал между сервером и клиентом.
MD>* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)
Также интересно.