Client-Server

Снова в школу
Дата: 07.06.2017 10:06:10
Помогите разобраться в азах. Не понимаю - как должно быть.

Вариант 1.
Клиент подключается к серверу - создаётся сокет.
Клиент отсылает запрос на сервер.
Сервер возвращает код выполнения.
Если код успешный - клиент читает responce от сервера (набор некой информации).
Клиент периодически, с заданным интервалом (каким???) опрашивает сервер, на наличие новой информации для него.

Вариант 2.
Клиент подключается к серверу - создаётся сокет.
Создаётся отдельный поток для чтения на клиенте.
Клиент отсылает запрос в основном потоке на сервер.
В основном потоке клиент читает вернувшийся код выполнения.
В читающем потоке приходит responce.
Если серверу надо что-то отослать клиенту - он просто отсылает (сокет открыт - всё ок).
На клиенте читающий поток должен разобраться сам, что ему пришло, ответ на запрос, или информация от сервера.
Клиент не опрашивает сервер.

Как правильно?
Akina
Дата: 07.06.2017 10:30:44
Термин "сокет" в данном случае явно не по делу. Вместо него лучше использовать термин "канал передачи данных", который состоит из 2 сокетов (один на клиенте и один на сервере) и коммуникаций между ними.

Во втором варианте Вы вообще свалили всё в одну кучу. При чём тут потоки? какая разница, как реализована программная обработка на клиенте?

И я не понимаю, какой тип обмена Вы рассматриваете. Пассивный? push? активный?
Dima T
Дата: 07.06.2017 10:39:44
Снова в школу
Как правильно?

Как надо так и правильно.

Если сервер должен по собственной инициативе что-то отправлять клиенту, то клиент устанавливает постоянное соединение, а сервер просто пишет в него тогда когда появляется что писать.
Снова в школу
Дата: 07.06.2017 10:44:17
Я не знаю какие типы обмена бывают.
Тут - та самая история, когда я не знаю, чего я не знаю.
Пожалуйста посоветуйте где посмотреть. Сейчас пороюсь сам.

Про "канал передачи данных" вы конечно правы.
Честно говоря, я вообще смутно пока представляю, как мне решать задачу.

У меня есть устройства, которые надо периодически опрашивать и информацию по ним отсылать на клиенты.
Клиент - обычная виндовая прога (скорее всего на C Builder - Delphi)
Скорее всего, как-то так. Пытаюсь подступиться к задаче хоть с какой-то стороны.

Отсюда туплю - клиент всегда должен слушать сервер и работать по событию от сервера, или опрашивать?
Опыта написания ни сервера, ни клиента, ни протокола обмена нет вообще.

Тыкните хотя бы куда посмотреть. По крохам собираю информацию откуда могу.

Спасибо
Akina
Дата: 07.06.2017 11:07:11
Снова в школу
У меня есть устройства, которые надо периодически опрашивать и информацию по ним отсылать на клиенты.

Разделите задачу на независимые части.

Первая - это работа сервера с устройствами. Сервер в данном случае выполняет роль клиента, а устройство - роль сервера. Т.е. сервер создаёт клиентский сокет и обращается к устройству. Получив запрос, устройство формирует серверный сокет. Образуется канал передачи данных, по которому устройство отсылает на сервер необходимые данные и получает от сервера команды. По завершении сеанса канал разрывается по инициативе одной из сторон, а сокеты расформируются. Сервер накапливает полученные от приборов данные.

Вторая - это работа сервера с клиентами. Тут возможны три варианта.

Первый - push-технология. На сервере имеется список клиентов, формируемый статически (настройками сервера, регистрацией на нём клиентов) или динамически (клиент анонсирует своё наличие, сервер его регистрирует, клиент периодически подтверждает своё наличие). По заданным правилам (по времени, по факту получения данных от приборов) сервер отсылает информацию зарегистрированным клиентам (использовать при этом создание канала к клиенту сервером или использовать, например, мультикастовую рассылку - решайте сами).

Второй - пассивная технология. Клиент подключается к серверу и по установленному каналу получает данные, после чего отключается. Потребуется следующая порция - клиент опять подключится. Альтернативно - канал не разрывается, а держится постоянно, и клиент периодически по нему запрашивает новые данные, а если перерыв велик, то просто подтверждает своё присутствие, соединение либо закрывается по инициативе клиента (выгрузка), либо разрывается сервером по тайм-ауту.

Третий - активная технология. используются два подключения. Клиент подключается к серверу и по установленному каналу передаёт данные для обратного подключения и команды. Сервер по переданным параметрам устанавливает обратное соединение с клиентом и по нему передаёт данные и ответы на команды.
Снова в школу
Дата: 07.06.2017 11:24:48
Akina - спасибо большое.

Стало намного понятней.
Dima T
Дата: 07.06.2017 11:43:12
Снова в школу
У меня есть устройства, которые надо периодически опрашивать и информацию по ним отсылать на клиенты.
Клиент - обычная виндовая прога (скорее всего на C Builder - Delphi)
Скорее всего, как-то так. Пытаюсь подступиться к задаче хоть с какой-то стороны.

ИМХО тут тебе надо использовать какую-нибудь *MQ (очередь сообщений).

Как вариант ZeroMQ. Облегченный вариант, для твоей задачи вполне хватит. Бесплатная библиотека в виде DLL, куда спрятана вся транспортная часть (сокеты, установка и поддержание соединений и т.д.).
Если на дельфях писать будешь, то в форуме по дельфям документацию переводили и примеры под делфи.
Снова в школу
Дата: 07.06.2017 11:45:56
Dima T,
Спасибо большое.
Буду разбираться.
Dadont
Дата: 07.06.2017 13:04:18
Напиши бота для телеграмма. Он будет отсылать сообщения в группу клиентов. Дешево и сердито.
Minatavr
Дата: 07.06.2017 14:50:45
Ребята, которые разрабатывают WAMP, разместили на своем сайте сравнительную таблицу разных протоколов.


Снова в школу
Клиент отсылает запрос на сервер.
Сервер возвращает код выполнения.
Если код успешный - клиент читает responce от сервера (набор некой информации).

В их терминологии эта возможность называется RPC (Remote Procedure Calls)

Снова в школу
Клиент периодически, с заданным интервалом (каким???) опрашивает сервер, на наличие новой информации для него.

А для этого придумали PubSub (Publish & Subscribe)

Снова в школу
Если серверу надо что-то отослать клиенту - он просто отсылает (сокет открыт - всё ок).
На клиенте читающий поток должен разобраться сам, что ему пришло, ответ на запрос, или информация от сервера.

По-моему, именно это и надо правильно разделить между RPC и PubSub, чтобы клиенту не приходилось "разбираться самому, что же пришло".