В режиме мульти сервера, и клиент, и сервер может быть инициализатором запроса, это облегчает реализацию, но вносит свои огрехи.
При реализации обычного клиент-сервер, клиент должен все время запрашивать необходимую информацию у сервера, соответ-но большая нагрузка канала связи, а он маленький.
Сообственно хотелось бы услышать советов, что вообще правильнее?
есть многопоточное приложение - клиент, по определенным событиям происходит отправка запросов на сервер и ожидание ответов, на некоторые комманды ответов нет.
Но, иногда сеть ложится и данные сохраняются в БД, потом сеть подымается и нужно отправить данные на сервер, которые не были синхронизированны, если начать их скопом отправлять при установлении соединения с сервером, то это заблокирует отправку данных по событиям, которые в приоритете, нежели синхронизация данных.
При этом, когда установленно постоянное соединение с клиентом, сервер может дать комманду: отключи устройство номер 5.
И тут пришла мысль о том, а мб вообще отказаться от мультисерверной функции? И перейти на непостоянное соединение, как в браузере и хоть в +100500 потоков отправлять данные из нескольких классов сразу?
есть многопоточное приложение - клиент, по определенным событиям происходит отправка запросов на сервер и ожидание ответов, на некоторые комманды ответов нет.
Но, иногда сеть ложится и данные сохраняются в БД, потом сеть подымается и нужно отправить данные на сервер, которые не были синхронизированны, если начать их скопом отправлять при установлении соединения с сервером, то это заблокирует отправку данных по событиям, которые в приоритете, нежели синхронизация данных.
При этом, когда установленно постоянное соединение с клиентом, сервер может дать комманду: отключи устройство номер 5.
И тут пришла мысль о том, а мб вообще отказаться от мультисерверной функции? И перейти на непостоянное соединение, как в браузере и хоть в +100500 потоков отправлять данные из нескольких классов сразу?
Эм.... при архитектуре клиент-сервер, у вас один сервер и кучи клиентов. Клиент соединяется с сервером, происходит создание tcp-соединения иии все. Дальше уже клиент либо посылает данные, либо не посылает... соединение просто висит в пуле.
ДА, но при этом инициатором передачи данных после установления соединения может быть и сам сервер, без запроса клиента при постоянном socket соединении.
Сервер уже реализован и он может отправлять комманды без запроса клиента, например заблокируй дверь. Тут стоит вопрос о том что правильнее? И возможно придется переписать серверную часть, такой подход был сделан ради уменьшения потока данных.
@ilnile ну если у вас пуш сервер то так да, как-то так и должно быть. То есть у вас один главный сервер, который является фронтэндом для всей системы, содержит статусы и прочее и руководит парадом.
Простой
