Здравствуйте, Kernan, Вы писали:
AG>>Сделать pooling — периодически опрос со сервера стороны клиентов? K>Не надо. У тебя же ТСП. Отвалится — узнаешь.
TCP может очень долго не осонавать, что он уже отвалился. Лучше бы в прикладном протоколе предусмотреть периодическое пингование сервера. И быть готовым к тому, что разрыв соединения с последуюшим успешным реконнектом — вполне штатная ситуация, хоть и нечастая.
Здравствуйте, AlexGin, Вы писали:
AG>Интересная мысль... AG>То есть — обойтись ТОЛЬКО TCP соединением?
Да. А если ты собираешься раздавать своего клиента широкому кругу пользователей, то лучше вообще использовать HTTP (или websock поверх HTTP). Бывают такие места, откуда местные фаирволы по абы какому TCP не пускают.
Здравствуйте, Pzz, Вы писали:
Pzz>Да. А если ты собираешься раздавать своего клиента широкому кругу пользователей, то лучше вообще использовать HTTP (или websock поверх HTTP). Бывают такие места, откуда местные фаирволы по абы какому TCP не пускают.
Нет, круг пользователей скорее узкий и специфичный.
В общем — пока я убрал UDP и оставил только один TCP.
Вроде все нормально работает
Здравствуйте, Pzz, Вы писали:
Pzz>А если эта датагдама потеряется? С UDB датаграммами это нередко случается, особенно с широковещательными.
+100500
Отказался я от UDP и датаграмм. Оставил только TCP (всё при этом нормально функционирует).
По крайней мере, я понял, что в UDP нет необходимости в контексте данной задачи.
Pzz>А "много" — это сколько?
Пока — сколько точно будет клентов — сам не знаю.
Может пару десятков, а может пару сотен.
Для Заказчика нужно подготовить масштабируемое решение.
Вполне допускаю, что придется делать балансировку нагрузки на серверах — в общем жизнь покажет.
Здравствуйте, AlexGin, Вы писали:
AG>Для Заказчика нужно подготовить масштабируемое решение. AG>Вполне допускаю, что придется делать балансировку нагрузки на серверах — в общем жизнь покажет.
Ну вообще-то, на этапе постановки задачи неплохо бы понимать, насколько оно будет массштабируемое. Ну или быть готовым к тому, что сейчас вы делаете прототип, а потом все перепишете нафиг. Потому что степень массштабируемости оказывает существенное влияние на общую архитектуру, да и в прикладном протоколе, возможно, придется потом это учитывать. Не каждая конструкция хорошо массштабируется, если просто добавить серверов.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну вообще-то, на этапе постановки задачи неплохо бы понимать, насколько оно будет массштабируемое. Ну или быть готовым к тому, что сейчас вы делаете прототип, а потом все перепишете нафиг.
+100500
Это в принцыпе вполне возможный вариант.
Тем более, что переписывать придется не всё: алгоритмы и формулы всё-таки будут отработаны, GUI — также частично проработан.
Сетевой уровень, сервисные службы — да похоже, что кардинально изменятся, но прсматриваться к проблеме, ИМХО, нужно и важно уже теперь (на дальних подступах).
Pzz>Потому что степень массштабируемости оказывает существенное влияние на общую архитектуру, да и в прикладном протоколе, возможно, придется потом это учитывать. Не каждая конструкция хорошо массштабируется, если просто добавить серверов.
+100500
Здесь еще имеет место тот факт, что архитектура завязана на контект задач Заказчика, и пока его _не_понимеешь_/_не_видишь_, проще заниматься "кирпичиками", из которых в дальнейшем бедем строить дом.
И вполне возможно, что какие-нибудь "кирпичики" придётся выбросить и заменить на другие. Как-то так
Важно:
Оснастить наши "кирпичики" такими интерфейсами, чтобы замена/апгрейд одного, не оказывали (кардинального?) влияния на все остальные.
Именно с этой целью я при разработке стараюсь уменьшать связность между компонентами наших проектов.
Как показала практика — это очень верный выбор (даже если данный шаг вызовет некоторую избыточность, он оправдывает себя).
А почему не используются IGMP и мультикасты? У меня стойкое ощущение, что будет самое то.
AG>Каждый новый клиент "прописывается" в этой структуре (используюя TCP запрос к серверу), и с этого момента сервер (сервера) знают о нём и обслуживают его.
Т.е. клиент посылает join-запрос в группу
AG>Если на уровне этих серверов что-либо изменилось (например, получен результат расчётов или выявлено, что дальнейший расчёт навозможен) - AG>генерируется широковещательная UDP датаграмма...
Мультикаст как он есть. Только, в отличие от широковещалки, оно
* доставляется только заинтересованным сторонам
* умеет проходить через маршрутизаторы (если там явно не запрещено)
* будет работать на IPv6
AG> ...приняв которую, клиенты начинают опрос сервера (серверов). AG>Этот опрос реализован через посылки рабочих TCP запросов к серверу (серверам) приложения.
Ну, тут уже на свой вкус — как по мне, вплоне себе рабочее решение.
AG>И здесь у меня возникает такой вопрос: не "ляжет" ли сервер, если клиентов много? AG>Может быть, следовало бы настраивать тайм-ауты с разной (для каждого клиента — своё время ожидания) время-выдержкой. AG>Этот тайм-аут будет отмеряться на каждом из клиентов — от поступления широковещательной UDP датаграммы, до генерации рабочего TCP запроса.
Можно решать по-разному:
* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет
* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)
* или serverless-подход в облаке, тогда нет проблем с автоскейлингом, были б деньги
Здравствуйте, Kernan, Вы писали:
K>Не надо. У тебя же ТСП. Отвалится — узнаешь.
А вот не факт. Достаточно одного дурного маршрутизатора, который не отпустил у себя туннель, и всё — готова чёрная дыра. Поэтому для гарантий "отавлится узнаешь" — только heartbit на уровне прикладного протокола. Двойной интервал истёк — дропаем у себя коннект не взирая на.
AG>>Или же просто в TCP-сокете (объект типа QTcpSocket) вызывать write(...) при готовности данных? K>Сервер легко может уведомлять клиента о наличии данных и даже их сразу же отдавать. Вопрос в том, готов ли клиент их принять поэтому пинг-понг + ГЕТ модель неплоха. AG>>Возможно, что будет дополнительный геморрой за счёт UDP. Может даже придется выбросить этот самый UDP канал... K>Тебе не нужен ЮДП, он внесёт только проблемы. AG>>Ну броузер здесь вроде как совсем не в тему. Но вот вариант — сделать HTTP и раздавать JSON-строки — возможно даже и неплохой. K>На схеме браузер был. Я думал клиенты это приложения в браузере.
Я не увидел возможности применения данной технологии в нашем продукте:
-видеопотока у нас нет. Сам по себе объем данных, у нас меньше, чем при видеопотоке;
-все данные, курсирующие по сети, достаточно критичны (в т.ч. и к потере пакетов), посему — реализовал идею полного отказа от UDP канала (полностью всё на TCP);
-сама по себе разбивка юзеров на группы неочевидна. Также, (пока?) нет очевидности в необходимости наличия самих пользовательских групп.
MD>Можно решать по-разному: MD>* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет
Идея интересная, но закрытие сокета не предусмотрено. У меня постоянный канал между сервером и клиентом.
MD>* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)
