Здравствуйте, Mihas, Вы писали:

M>Здравствуйте, AlexGin, Вы писали:

AG>>Сервер — загружен некоторой работой, предполагается в основном расчетная работа (точнее — моделирование).
AG>>Клиенты должны периодически (в любой произвольный момент времени) получать результаты работы.
M>Результаты работы не зависят от запросов клиентов? Клиенты получают всего лишь текущую версию рассчитанного?

Пока планируется именно так. Обший массив данных (пакетов) для всех клиентов.
В будущем может что-то и меняться (например каждому из клиентов — свой массив данных).

AG>>Предполагается, что TCP канал (между сервером и клиентом) всё время установлен.
M>Зачем? Клиент не может обойтись схемой запрос-ответ и отвалился?

Кстати да, может. Возможно — это даже правильнее.
Почему я взял вариант с постоянным соединением — из соображений что так быстрее (не тратим время на re-connect).

AG>>Но мне почему-то кажется, что наличие дополнительного UDP канала обеспечит более быстрое (хотя и менее надежное, нежели TCP) оповещение клиентов.
AG>>Если же вводить тайм-аут, как я писал выше, то приимушества от UDP-Notify канала теряются. Как в этом случае быть?
M>Не понятны требования к быстродействию системы в целом. С одной стороны оповещение через широковещательные UDP, с другой и таймауты допустимы.

Смотря какие тай-ауты. Три-четыре секунды — допустимы.
Полчаса (или даже 10 минут) НЕДОПУСТИМО.

Здравствуйте, Mihas, Вы писали:

M>Здравствуйте, AlexGin, Вы писали:

AG>>Сервер — загружен некоторой работой, предполагается в основном расчетная работа (точнее — моделирование).
AG>>Клиенты должны периодически (в любой произвольный момент времени) получать результаты работы.
M>Результаты работы не зависят от запросов клиентов? Клиенты получают всего лишь текущую версию рассчитанного?

Пока планируется именно так. Обший массив данных (пакетов) для всех клиентов.
В будущем может что-то и меняться (например каждому из клиентов — свой массив данных).

AG>>Предполагается, что TCP канал (между сервером и клиентом) всё время установлен.
M>Зачем? Клиент не может обойтись схемой запрос-ответ и отвалился?

Кстати да, может. Возможно — это даже правильнее.
Почему я взял вариант с постоянным соединением — из соображений что так быстрее (не тратим время на re-connect).

AG>>Но мне почему-то кажется, что наличие дополнительного UDP канала обеспечит более быстрое (хотя и менее надежное, нежели TCP) оповещение клиентов.
AG>>Если же вводить тайм-аут, как я писал выше, то приимушества от UDP-Notify канала теряются. Как в этом случае быть?
M>Не понятны требования к быстродействию системы в целом. С одной стороны оповещение через широковещательные UDP, с другой и таймауты допустимы.

Смотря какие тайм-ауты. Три-четыре секунды — допустимы.
Полчаса (или даже 10 минут) НЕДОПУСТИМО.

P.S. А применение схемы запрос-ответ как-то решит проблему нотификации о новых данных на сервере?