А почему не используются IGMP и мультикасты? У меня стойкое ощущение, что будет самое то.
AG>Каждый новый клиент "прописывается" в этой структуре (используюя TCP запрос к серверу), и с этого момента сервер (сервера) знают о нём и обслуживают его.
Т.е. клиент посылает join-запрос в группу
AG>Если на уровне этих серверов что-либо изменилось (например, получен результат расчётов или выявлено, что дальнейший расчёт навозможен) - AG>генерируется широковещательная UDP датаграмма...
Мультикаст как он есть. Только, в отличие от широковещалки, оно
* доставляется только заинтересованным сторонам
* умеет проходить через маршрутизаторы (если там явно не запрещено)
* будет работать на IPv6
AG> ...приняв которую, клиенты начинают опрос сервера (серверов). AG>Этот опрос реализован через посылки рабочих TCP запросов к серверу (серверам) приложения.
Ну, тут уже на свой вкус — как по мне, вплоне себе рабочее решение.
AG>И здесь у меня возникает такой вопрос: не "ляжет" ли сервер, если клиентов много? AG>Может быть, следовало бы настраивать тайм-ауты с разной (для каждого клиента — своё время ожидания) время-выдержкой. AG>Этот тайм-аут будет отмеряться на каждом из клиентов — от поступления широковещательной UDP датаграммы, до генерации рабочего TCP запроса.
Можно решать по-разному:
* клиент бросает кубик и выбирает себе рандомную задержку перед началом запроса к серверу, равно как и сервер может ответить "сейчас не могу, повтори запрос через N времени" и закрыть сокет
* сервер не один, а прячется целая ферма за Load balancer (которую тот же nGinx разруливает, например)
* или serverless-подход в облаке, тогда нет проблем с автоскейлингом, были б деньги
