Как продвинуть данные клиенту CF.NET?
Хотя опрос веб-сервиса возможен, Вы знаете о другом методе для продвижения изменений в мобильном клиенте кроме использования передачи почты Exchange Server?
3 ответа
Как Марк Симан: Однажды, когда я работал в команде Microsoft Dynamics Mobile, я делал POC системы клиентских уведомлений для .NET CF.
В то время я не нашел никаких Out-Of-The-Box решений, которые могли бы это сделать, и я не хотел переписываться с сервером Exchange, так как предполагаемые пользователи не имели учетной записи AD, и большинство из них не использовали Exchange-сервер. Поэтому я оказался в той же ситуации, что и вы сейчас. Я начал искать возможные решения...
Я понял, что сервер не должен подключаться к клиенту, так как IP-адрес этого постоянно меняется (переход с 3G на WiFi, потеря соединения и т.д.). Клиент должен был подключиться к серверу. Более того, я обнаружил, что большинство сетей разрешают HTTP соединения, но не всегда пользовательские TCP соединения через пользовательские порты.
Я использовал "Comet" для выполнения длительных http запросов от клиента (.NET CF) к серверу (IIS) и подталкивал уведомления к клиенту, используя это соединение. Если бы клиент получил таймаут до того, как было дано уведомление, он просто сделал бы новый запрос.
На стороне сервера я использовал комбинацию AsyncHttpHandler и потоков ожидания, которые проверяли сообщения подключенным клиентам каждую секунду. Важно использовать AsyncHttpHandler, иначе вы заблокируете сервер IIS.
POC работал хорошо и оказался надежным решением. В этом есть некоторые недостатки: если вы не будете осторожны, то довольно быстро разрядите батарею.
К сожалению, здесь просто слишком много строк кода, чтобы я мог разместить его здесь, но если вам нравится, вы можете связаться со мной, и я отправлю вам по электронной почте свой POC.
Когда я работал в команде Microsoft Dynamics Mobile (до января 2009 года) не было другого встроенного способа сделать это на . NET CF, кроме как через почтовый транспорт сервера Exchange.
Однако, один из моих коллег сделал всплеск, когда мобильный клиент открывал HTTP-соединение со службой и держал его открытым, при этом служба имела открытый канал, по которому она могла проталкивать.
AFAIK, это, по сути, то, что делает почтовый транспорт сервера Exchange. IIRC, он заставил его работать нормально, но я напишу ему в твиттере и посмотрю, смогу ли я заставить его перезвонить
.Вот некоторые опции для использования во внутренней сети:
- MSQM
- TcpListener
Для варианта 1 вам нужно установить другую часть инфраструктуры, но вы получите стандартный API и протокол.
Для второго варианта вам нужно реализовать собственный протокол.
Обе опции работают только в закрытом окружении!