CF приложение двусторонняя связь с сервером

Question

Пользователи в поле с КПК будут генерировать сообщения и отправлять на сервер; пользователи на стороне сервера будут генерировать сообщения, которые необходимо отправить на КПК.

Сообщения находятся между приложением и кодом сервера; не 100% введенные пользователем данные. То есть мы собираем некоторые данные в форме, добавляем местоположение GPS, дату и т. Д. И отправляем их на сервер.

Сервер может отправлять нам сообщения, такие как обновления записей базы данных, используемых в приложении для КПК, сообщения для пользователя и т. Д.

Для сообщений с КПК на сервер это просто. КПК инициирует вызов на сервер и передает данные. В настоящее время с помощью веб-служб на стороне сервера и «добавить новую веб-ссылку» и связанный код на КПК.

Я отклеиваюсь, пытаясь своевременно получать сообщения с сервера на КПК. В некоторых случаях важно быстро получить сообщение.

Если на сервере есть сообщение для конкретного КПК, было бы здорово, чтобы КПК получил его в течение нескольких секунд после его доступности. Таким образом, опрос раз в минуту закончен; Опрос один раз в секунду будет генерировать много трафика и, возможно, разрядить батарею КПК?

Этот пост является тем же вопросом, что и мой, и предлагает длинный опрос http: Windows Mobile 6.0 / 6.5 - Push-уведомление

Я посмотрел на обратные вызовы WCF, и они, похоже, как раз то, что я хочу, недоступные для компактной среды.

Этот следующий пост не для CF, но поднимает вопросы доступности услуг:

Опрашивать или не опрашивать (в контексте веб-служб)

В моем контексте у меня будет 500-700 устройств, желающих общаться с небольшим количеством веб-сервисов (между 2-5).

Это много длинных запросов на опрос, чтобы оставаться открытыми.

Разве сокеты - это путь? Опять же, это много связей.

Я также читал о методах, использующих exchange или gmail; я действительно не решаюсь идти по этим путям.

Большинству постов, которые я нашел здесь и в Google, несколько лет; что-то могло всплыть с тех пор?

Каков наилучший способ работы с 500-700 КПК-устройствами, которым требуется почти мгновенная связь с сервером при сохранении заряда батареи? Высокий запрос, я уверен.

Answer 1

Давным-давно команда CF создала приложение под названием "Lunch Launcher", которое было основано на обмене сообщениями в режиме хранения и пересылки WCF.Дэвид Клайн написал замечательную серию статей ( здесь последняя , в которой есть оглавление для всех предыдущих статей).

На MSDN есть веб-трансляция по запросу.предоставленный Джимом Уилсоном, который дает общее представление о хранении и пересылке, а код из этой веб-трансляции доступен здесь .

Это может делать то, что вы хотите, хотя у него есть некоторые зависимости (например,Обмен) и некоторые присущие ограничения (например, нет встроенного подтверждения доставки).

Answer 2

Ладно, дальше смотреть, и я могу быть ближе к тому, что хочу;который я считаю формой http long poll в любом случае.

Эта статья здесь - http://www.codeproject.com/KB/IP/socketsincsharp.aspx - показывает, как подключить прослушиватель к сокету.Поэтому я делаю это на стороне сервера.

Затем клиентская сторона открывает сокет для сервера на этом порту;отправляет идентификатор устройства.Код сервера сначала проверяет, есть ли ответ для этого устройства.Если есть, он отвечает.

Если нет, он либо опрашивает себя, либо подписывается на какое-то событие;затем возвращается, когда у него есть данные.

Я мог бы поставить код тайм-аута на стороне сервера, если это необходимо.

Блокировка на стороне клиента, я не беспокоюсь, потому что это фоновый поток и никакие данные не являются такими же, как блокировка на уровне приложения;Что касается ресурса процессора и тестера, не уверен.

Я знаю, что я написал достаточно широко, но стоит ли исследовать эту стратегию?

Answer 3

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

Вы хотитеиспользовать тот же подход в обратном порядке, поэтому каждый клиент открывает сокет на своей машине и ожидает поступления трафика.Клиенту в основном нужно будет опрашивать свой собственный сокет (который не несет никакого сетевого трафика).Клиент также должен будет сообщить свой IP-адрес и сокет серверу, чтобы, когда серверу нужно было связаться с клиентом, у него были средства для его достижения.Затем сервер будет использовать сокеты на основе сокетов (в отличие от веб-сервисов) для отправки сообщений по мере необходимости.Сервер может просто открыть сокет, отправить сообщение, а затем снова закрыть сокет.Не нужно иметь много постоянно открытых сокетов.

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

Походит на интересный проект.Удачи!