Шаблон для реализации пульса между сервером и клиентом

Question

Я бы хотел реализовать на сервере функциональность пульса, которая бы периодически оповещала оконных клиентов о его жизнеспособности. Есть несколько идей, которые я рассматриваю, но буду признателен за предложения и примеры / ссылки

• имеет отдельный поток, который будет отправлять пульс подключенным клиентам

• имеют различные типы сердцебиения для указания различных состояний сервера (медленно, быстро, перегружено клиентами, готово и готово)

• возможно, разрешить клиентам подписываться на разные уровни, по умолчанию отправляется пульс

Мне бы очень хотелось посмотреть, как это делается на практике, примеры лучше.

РЕДАКТИРОВАТЬ 1 клиенты и сервер не являются веб-интерфейсом! (сервер может мигрировать в сеть, но я не думаю, что это сильно изменит протокол)

Answer 1

Использование модели тяги, упомянутой Джошем, - самый простой подход. Прежде всего, вы преодолеете множество проблем с безопасностью. Не нужно беспокоиться о клиентских брандмауэрах. Кроме того, вам не нужно беспокоиться о необходимости открытия одного и того же порта на каждом клиенте или открытия динамических портов и уведомления сервера о том, какой порт на каком клиенте используется.

Кроме того, вам не нужно будет вести список подписчиков на сервере. Кроме того, вам не нужно беспокоиться об очистке списка подписчиков, если клиент отключается не очень чистым способом (сбой приложения, сбой питания и т. Д.).

По сути, простой опрос клиента на службу на сервере - это самый простой и чистый подход, ИМХО. Я использовал это несколько раз. Вы даже можете настроить интервал опроса, если захотите.

Edit:

Хотя я не могу предоставить ссылку или пример кода, я опишу, что я делал в прошлом.

По сути, у меня был веб-сервис, который при запросе возвращал бы состояние системы. Этот веб-сервис явно работает на сервере. При запуске клиенты запускают отдельный поток, который каждые 30 секунд будет запрашивать веб-службу, чтобы узнать состояние серверной системы. Затем пользовательский интерфейс будет обновлен, чтобы указать это состояние. После выполнения этой задачи поток вернется в режим ожидания на 30 секунд. Время обновления можно было настроить с помощью файла конфигурации. Просто убедитесь, что ошибки перехватываются, чтобы в случае сбоя запроса к службе по причине, не связанной с отключением сервера, все приложение не зависало.

Answer 2

Это почти наверняка излишне, но есть целая (и очень живая) дисциплина, которая рассматривает классы детекторов отказов, какие виды гарантий они могут предоставить и как они могут быть практически реализованы. Для тех, кто хочет пойти немного дальше, чем подразумевает этот спрашивающий, взгляните на:

Book Series - 
Book Title  - Distributed Computing
Chapter Title  - On the Impact of Fast Failure Detectors on Real-Time Fault-Tolerant Systems
First Page  - 354
Last Page  - 369
Copyright  - 2002
Author  - Marcos K. Aguilera
Author  - Gérard Le Lann
Author  - Sam Toueg
DOI  - 10.1007/3-540-36108-1_24
Link  - <a href="http://www.springerlink.com/content/e03yf4etbnle9728" rel="nofollow noreferrer">http://www.springerlink.com/content/e03yf4etbnle9728</a>

Book Title  - Distributed Algorithms
Chapter Title  - Heartbeat: A timeout-free failure detector for quiescent reliable communication
First Page  - 126
Last Page  - 140
Copyright  - 1997
Author  - Marcos Kawazoe Aguilera
Author  - Wei Chen
Author  - Sam Toueg
DOI  - 10.1007/BFb0030680
Link  - http://www.springerlink.com/content/dj5n71hl17841416

Кроме того, из вопроса не ясно, но если речь идет о Java, отличный ресурс по этой теме: Введение в надежное распределенное программирование , с большим количеством превосходного примера кода.

Answer 3

О каком клиенте мы говорим? Windows-клиент или asp.net? Есть два очень общих шаблона для этого. Вы можете нажать или потянуть данные. Нажатие не работает, если в Интернете вы столкнетесь с брандмауэрами и натсами. Таким образом, вы получаете третий вариант, когда клиент инициирует соединение, а сервер оставляет соединение открытым для отправки информации туда и обратно.

Вы должны предоставить гораздо больше информации, мы говорим об Интернете или интранете? На какие .net Framework вы ориентируетесь? Сколько клиентов вы говорите? Решение, которое может обслуживать дюжину клиентов (особенно в модели push или третьей модели), может сильно отличаться от решения, которое может масштабироваться до тысяч клиентов.

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

Редактировать

Хорошо, вы указали сокеты, вы действительно уверены, что хотите заняться программированием сетевого типа более низкого уровня? Почему бы не использовать существующие сетевые стратегии, такие как HTTP. Вы можете сделать простой сервис удаленного взаимодействия через HTTP, который позволит вам обходить межсетевые экраны. Или даже лучше, если ваш сервер является веб-сервером, тогда просто установите старый старый сервис XML.

У меня нет примеров, которыми я мог бы поделиться, но их должно быть много.