Сообщение Re[4]: Сетевая структура от 26.07.2019 12:11
Изменено 26.07.2019 12:13 AlexGin
Re[4]: Сетевая структура
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
AG>>Сервер — загружен некоторой работой, предполагается в основном расчетная работа (точнее — моделирование).
AG>>Клиенты должны периодически (в любой произвольный момент времени) получать результаты работы.
M>Результаты работы не зависят от запросов клиентов? Клиенты получают всего лишь текущую версию рассчитанного?
Пока планируется именно так. Обший массив данных (пакетов) для всех клиентов.
В будущем может что-то и меняться (например каждому из клиентов — свой массив данных)ю
AG>>Предполагается, что TCP канал (между сервером и клиентом) всё время установлен.
M>Зачем? Клиент не может обойтись схемой запрос-ответ и отвалился?
Кстати да, может. Возможно — это даже правильнее.
Почему я взял вариант с постоянным соединением — из соображений что так быстрее (не тратим время на re-connect).
AG>>Но мне почему-то кажется, что наличие дополнительного UDP канала обеспечит более быстрое (хотя и менее надежное, нежели TCP) оповещение клиентов.
AG>>Если же вводить тайм-аут, как я писал выше, то приимушества от UDP-Notify канала теряются. Как в этом случае быть?
M>Не понятны требования к быстродействию системы в целом. С одной стороны оповещение через широковещательные UDP, с другой и таймауты допустимы.
Смотря какие тай-ауты. Три-четыре секунды — допустимы.
Полчаса (или даже 10 минут) НЕДОПУСТИМО.
M>Здравствуйте, AlexGin, Вы писали:
AG>>Сервер — загружен некоторой работой, предполагается в основном расчетная работа (точнее — моделирование).
AG>>Клиенты должны периодически (в любой произвольный момент времени) получать результаты работы.
M>Результаты работы не зависят от запросов клиентов? Клиенты получают всего лишь текущую версию рассчитанного?
Пока планируется именно так. Обший массив данных (пакетов) для всех клиентов.
В будущем может что-то и меняться (например каждому из клиентов — свой массив данных)ю
AG>>Предполагается, что TCP канал (между сервером и клиентом) всё время установлен.
M>Зачем? Клиент не может обойтись схемой запрос-ответ и отвалился?
Кстати да, может. Возможно — это даже правильнее.
Почему я взял вариант с постоянным соединением — из соображений что так быстрее (не тратим время на re-connect).
AG>>Но мне почему-то кажется, что наличие дополнительного UDP канала обеспечит более быстрое (хотя и менее надежное, нежели TCP) оповещение клиентов.
AG>>Если же вводить тайм-аут, как я писал выше, то приимушества от UDP-Notify канала теряются. Как в этом случае быть?
M>Не понятны требования к быстродействию системы в целом. С одной стороны оповещение через широковещательные UDP, с другой и таймауты допустимы.
Смотря какие тай-ауты. Три-четыре секунды — допустимы.
Полчаса (или даже 10 минут) НЕДОПУСТИМО.
Re[4]: Сетевая структура
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
AG>>Сервер — загружен некоторой работой, предполагается в основном расчетная работа (точнее — моделирование).
AG>>Клиенты должны периодически (в любой произвольный момент времени) получать результаты работы.
M>Результаты работы не зависят от запросов клиентов? Клиенты получают всего лишь текущую версию рассчитанного?
Пока планируется именно так. Обший массив данных (пакетов) для всех клиентов.
В будущем может что-то и меняться (например каждому из клиентов — свой массив данных).
AG>>Предполагается, что TCP канал (между сервером и клиентом) всё время установлен.
M>Зачем? Клиент не может обойтись схемой запрос-ответ и отвалился?
Кстати да, может. Возможно — это даже правильнее.
Почему я взял вариант с постоянным соединением — из соображений что так быстрее (не тратим время на re-connect).
AG>>Но мне почему-то кажется, что наличие дополнительного UDP канала обеспечит более быстрое (хотя и менее надежное, нежели TCP) оповещение клиентов.
AG>>Если же вводить тайм-аут, как я писал выше, то приимушества от UDP-Notify канала теряются. Как в этом случае быть?
M>Не понятны требования к быстродействию системы в целом. С одной стороны оповещение через широковещательные UDP, с другой и таймауты допустимы.
Смотря какие тай-ауты. Три-четыре секунды — допустимы.
Полчаса (или даже 10 минут) НЕДОПУСТИМО.
M>Здравствуйте, AlexGin, Вы писали:
AG>>Сервер — загружен некоторой работой, предполагается в основном расчетная работа (точнее — моделирование).
AG>>Клиенты должны периодически (в любой произвольный момент времени) получать результаты работы.
M>Результаты работы не зависят от запросов клиентов? Клиенты получают всего лишь текущую версию рассчитанного?
Пока планируется именно так. Обший массив данных (пакетов) для всех клиентов.
В будущем может что-то и меняться (например каждому из клиентов — свой массив данных).
AG>>Предполагается, что TCP канал (между сервером и клиентом) всё время установлен.
M>Зачем? Клиент не может обойтись схемой запрос-ответ и отвалился?
Кстати да, может. Возможно — это даже правильнее.
Почему я взял вариант с постоянным соединением — из соображений что так быстрее (не тратим время на re-connect).
AG>>Но мне почему-то кажется, что наличие дополнительного UDP канала обеспечит более быстрое (хотя и менее надежное, нежели TCP) оповещение клиентов.
AG>>Если же вводить тайм-аут, как я писал выше, то приимушества от UDP-Notify канала теряются. Как в этом случае быть?
M>Не понятны требования к быстродействию системы в целом. С одной стороны оповещение через широковещательные UDP, с другой и таймауты допустимы.
Смотря какие тай-ауты. Три-четыре секунды — допустимы.
Полчаса (или даже 10 минут) НЕДОПУСТИМО.