Какой сетевой протокол использовать для упрощенного уведомления удаленных приложений?

Двумя крупными участниками многоуровневой разработки в Delphi являются component4developers (их продукт kbmMW описан в ответе Марка Робинсона) и RemObjects со своим продуктом RemObjects SDK (у них есть хороший пример, который может быть похож на то, что вам нужно: Push-уведомления для iPhone).

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

Если соединение открыто, его можно использовать в двунаправленном режиме (это также используется удаленным взаимодействием .NET и WCF), но оно сопряжено с дополнительными накладными расходами.

Вам нужно будет найти баланс между поддержанием активных подключений (блокировка ресурсов) и созданием новых подключений (стоимость времени и задержка).

--jeroen

Попробуйте немного «поиграть» с протоколом HTTP, чтобы получить то, что вы хотите, и в то же время иметь возможность проходить через все прокси, NAT и брандмауэры, которые могут быть на стороне клиента.

Пусть каждый отдельный клиент выполняет простой HTTP-запрос на количество сообщений таким образом, чтобы запретить любое кэширование (пример: GET http://yourserver.org/getcount/nodeid/timeofday/sequence). В серверной реализации HTTP-сервер задерживает предоставление ответа, если «счетчик» такой же, как и раньше (т.е. нет новых сообщений).

Я сделал это для приложения в стиле Ajax, которое работало в браузере и вело себя как приложение чата, но ваше решение может быть еще быстрее. Я реализовал материал на стороне сервера, используя сервер TIdHttp, и это позволило мне фактически отложить предоставление ответа на клиентский материал, просто выполнив Sleep() в его потоке. Со стороны клиента это выглядело как сервер, который иногда очень медленно дает ответ.

Псевдокод для серверной части:

function ClientHasMessages(ClientID:Integer; MaxWait:TDateTime):Boolean;
var MaxTime:TDateTime;
begin
  if ClientActuallyHasMessage(ClientID) then Result := True
  else
    begin
      MaxTime := Now + MaxWait;
      while Now < MaxTime do
      begin
        if ClientActuallyHasMessage(ClientID) then
          begin
            Result := True;
            Exit;
          end
        else
          Sleep(1000);
      end;
      Result := False; // TimeOut
    end;
end;

Идея этого кода: он работает в потоке на вашем собственном сервере, где он может проверить количество сообщений, по-видимому, за очень небольшие деньги:

• Это не вызывает сетевого трафика во время ожидания.
• Он не использует процессор во время сна.
• Это позволит пользователю узнать о своем сообщении очень быстро.
• Он позволяет клиенту контролировать, как долго может длиться ожидание (клиент увеличивает время, на которое сервер может задерживать ответ до тех пор, пока он больше не получит ответ, а затем немного отступает — таким образом протокол адаптируется к любым ошибкам NAT). маршрутизатор, который использует клиент).
• Вы можете избавиться от длительных периодов отсутствия связи по протоколу TCP/IP и при этом иметь возможность мгновенно предоставить ответ. 30 секунд легко сделать, а для клиентов с хорошими маршрутизаторами NAT это может быть намного дольше.

Уменьшенный размер этого будет требованиями к серверу, но я склонен сказать, что они выполнимы:

• Серверная реализация TCP/IP должна отслеживать большое количество одновременных подключений (у каждого клиента всегда будет активен HTTP-запрос). Моя машина Linux NAT прямо сейчас отслеживает 15 000 подключений и в основном простаивает, так что это может сработать.
• На сервере всегда будет открыт поток для каждого HTTP-запроса клиента: Опять же, «Рабочая станция» Server 2008, которую я использую для написания этого (спасибо MSDN за то, что позволили мне делать такие возмутительные вещи), имеет около 1500 потоков. активен, и он также в основном бездействует ...
• В зависимости от технологии, которую вы используете для серверного кода, ограничивающим фактором может быть ПАМЯТЬ.

Я бы посмотрел на kbmMW

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

(По крайней мере, так я понимаю работу MS Exchange)

Вы можете попробовать позвонить на сервер и подождать некоторое время (1 минуту?), пока у вас не появятся обновления. Таким образом, вам не нужно обратное соединение с сервера на клиент, и вы получаете почти мгновенные результаты для клиента (если у вас есть обновления в течение 1 минуты, вы завершаете вызов ожидания). Это относительно простой и широко (?) используемый веб-приложениями (например, Gmail: у него есть фоновое соединение, подобное этому: если приходит новое электронное письмо, вы сразу же видите его в своем почтовом ящике!). Я использую что-то вроде этого (RemObjects):

function TLoggingViewService.GetMessageOrWait: TLogMessageArray;
begin
  if (Session.Outputbuffer.Count > 0) or
     //or wait till new message (max 3s)
     Session.Outputbuffer.WaitForNewObject(3 * 1000)
  then
    //get all messages from list (without wait)
    Result := PeekMessage;
end;

Отрицательный момент: вы держите соединение открытым в течение относительно долгого времени (что, если соединение потеряно из-за Wi-Fi и т. д.?) И высокая «нагрузка» сервера (каждое соединение имеет поток, остается открытым: если у вас много клиентов, вы можете получить из ресурсов).

Мы используем здесь RemObjects и используем TCP + Binmessage, который имеет НАМНОГО меньше накладных расходов, чем SOAP + HTTP, и очень быстрый! Так что, если вы можете использовать это, я действительно могу рекомендовать это! (в вашем случае нужны Remobjects для Delphi и RemObjects для .Net). Используйте SOAP только в том случае, если вам нужно подключить третьи стороны, и используйте HTTP, только если вам это нужно из-за Интернета/брандмауэра. SOAP хорош, но имеет высокие накладные расходы и проблемы с производительностью.

Вы также можете использовать их комбинацию: простое (RemObjects) TCP-соединение (с небольшими накладными расходами) в фоновом потоке, опрашивая каждые 10 секунд и ожидая 5 секунд для новых данных.

Я провел тестирование производительности на системах, даже больших, чем ваши 10 000 клиентов, и когда вы достигнете указанного количества запросов в секунду, вы, скорее всего, столкнетесь с проблемами с подключениями в секунду, одновременными открытыми соединениями, медленными брандмауэрами и т. д. (почти то же самое). проблемы, с которыми может столкнуться торрент-трекер).

Если клиентам нужно только «спросить, есть ли что-нибудь новое», самым легким протоколом, который легко реализовать, является UDP, следующим самым легким будет чистый TCP, оба с использованием клиентов Indy.

Сам протокол на самом деле может быть таким же простым, как отправка «Что-нибудь новое с [гггг-мм-дд чч:мм:сс]» на сервер, и он отвечает однобайтовым числом (возможны 256 ответов).

С TCP у вас будет дополнительное преимущество: держать «канал» открытым в течение нескольких минут, и вы можете отправлять сообщение «что-нибудь новое» каждые x секунд. Также с TCP сервер может «проталкивать» информацию в канал (клиент(ы)), когда что-то происходит, учитывая, что клиент периодически проверяет данные в канале.

Я бы постарался максимально распределить нагрузку между несколькими серверами. Для этого я бы сделал следующее:

1. Клиенты регистрируются в вашем сервисе, чтобы получать уведомления. Они получают идентификатор сеанса, действительный в течение заданного периода времени (15 минут).
2. Серверы будут периодически проверять, какой зарегистрированный клиент имеет входящее сообщение, и генерировать список таких клиентов (технически я бы вообще отправил это в другую БД в вашей демилитаризованной зоне).
3. Вы запускаете несколько серверов «push-уведомлений», которые следуют очень и очень простому протоколу: они получают URL-запрос, содержащий идентификатор сеанса, и отвечают коротким HTTP-ответом: либо 404, либо 200 с (подписанным) URL-адресом SOAP-сервер, к которому нужно обращаться, чтобы получать сообщения. Для дополнительной производительности вы можете использовать HTTP 1.1 и постоянные соединения.
4. Клиент будет объединять эти серверы push-уведомлений так часто, как захочет. Поскольку они очень просты и строго доступны только для чтения, они могут очень быстро отвечать на запросы и их легко масштабировать.
5. Если клиент получает ответ 302, он может подключиться к правильному серверу SOAP (вы также можете использовать его для распределения нагрузки, если хотите) и получить сообщения.

Здесь вам придется позаботиться о безопасности. Во-первых, я предлагаю вам НЕ использовать HTTPS для ваших серверов push-уведомлений. Вместо этого вы можете подписать содержимое ответа сеансовым ключом, которым обмениваются, когда клиент запрашивает уведомления. Затем клиент несет ответственность за проверку ответа. Не забывайте, что вам нужно подписать не только статус, но и URL сервиса SOAP.

Это немного сложно, но, разделив статус и фактический трафик сообщений, вы можете гораздо проще масштабировать свое решение. Кроме того, вам не нужно будет проходить дорогостоящее согласование SSL, пока вы действительно не захотите обмениваться данными.

Для этого мы используем «события» RemObjects SDK, но это может вам не подойти, потому что

a: Он работает только с собственным бинарным протоколом RemObjects, а не с SOAP (т.е. клиенты должны включать код RO)

b: По сути, это подход «держать линию открытой». поэтому масштабируемость до 10 000 клиентов является потенциальной проблемой.

Я бы попробовал несколько тестов, чтобы увидеть, какие накладные расходы на поддержание открытых сокетов 10K на самом деле. Если все, что вам нужно, это пара гигабайт дополнительной серверной памяти, это будет дешевое решение. И поскольку сокет открывается со стороны клиента, это не должно вызывать проблем с брандмауэром. Худшее, что может сделать брандмауэр, — это закрыть сокет, поэтому вашему клиенту потребуется снова открыть его, когда это произойдет.

Push-уведомления для iPhone работают, только если вашими удаленными устройствами являются iPhone. Единственными другими вариантами являются сохранение соединения открытым (хотя в основном бездействующим) или опрос клиента.

Возможно, вы сможете уменьшить накладные расходы на опрос, упростив вызов. Используйте простое веб-действие, чтобы вернуть клиенту самый высокий номер сообщения, и пусть клиент выполнит простой HTTP GET для получения этого номера. Это уменьшает объем полосы пропускания и делает его простым. Если затем клиенту необходимо получить обновленные данные, можно выполнить полный вызов мыла.

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

Если вы пытаетесь передать данные с сервера клиенту, который в данный момент не подключен, удачи, если у вас нет контроля над средами клиентов. Звучит для меня так, как будто вы вынуждены устанавливать соединения, инициированные клиентом.

Что-то немного не в левом поле.

Почему аутентификация требуется только для получения флага о готовности обновлений? Почему бы не иметь машину за пределами брандмауэра аутентификации... или даже в облаке... которая ничего не делает, кроме как обрабатывает эти запросы "есть ли что-нибудь доступное". Затем, если что-то доступно, попросите клиента пройти через обручи, чтобы получить реальные данные. Этот сервер запросов может выполнять 7-секундный getcount с реального сервера.

Сейчас мы говорим об очень небольшом количестве данных и очень небольшом времени установки для простого «флажка», даже не считая.

Это по-прежнему тысячи запросов, но тысячи запросов с минимальными накладными расходами по сравнению с полностью аутентифицированным запросом.