CF app two way communications with server

Users in field with PDA's will generate messages and send to the server; users at the server end will generate messages which need to be sent to the PDA.

Messages are between the app and server code; not 100% user entered data. Ie, we'll capture some data in a form, add GPS location, time date and such and send that to the server.

Server may send us messages like updates to database records used in the PDA app, messages for the user etc.

For messages from the PDA to server, that's easy. PDA initiates call to server and passes data. Presently using web services at the server end and "add new web reference" and associated code on the PDA.

I'm coming unstuck trying to get messages from the the server to the PDA in a timely fashion. In some instances receiving the message quickly is important.

If the server had a 开发者_如何学Gomessage for a particular PDA, it would be great for the PDA to receive that within a few seconds of it being available. So polling once a minute is out; polling once a second will generate a lot of traffic and, maybe draim the PDA battery some ?

This post is the same question as mine and suggests http long polling: Windows Mobile 6.0/6.5 - Push Notification

I've looked into WCF callbacks and they appear to be exactly what I want however, unavailable for compact framework.

This next post isn't for CF but raises issues of service availability:

To poll or not to poll (in a web services context)

In my context i'll have 500-700 devices wanting to communicate with a small number of web services (between 2-5).

That's a lot of long poll requests to keep open.

Is sockets the way to go ? Again that's a lot of connections.

I've also read about methods using exchange or gmail; i'm really hesitant to go down those paths.

Most of the posts i've found here and in google are a few years old; something may have come up since then ?

What's the best way to handle 500-700 PDA CF devices wanting near-instant communication from a server, whilst maintaing battery life ? Tall request i'm sure.

Socket communication seems like the easiest approach. You say you're using webservices for client-server comms, and that is essentially done behind the scenes by the server (webservice) opening a socket and listening for packets arriving, then responding to those packets.

You want to take the same approach in reverse, so each client opens a socket on its machine and waits for traffic to arrive. The client will basically need to poll its own socket (which doesnt incur any network traffic). Client will also need to communicate its ip address and socket to the server so that when the server needs to communicate back to the client it has a means of reaching it. The server will then use socket based comms (as opposed to webservices) to send messages out as required. Server can just open a socket, send message, then close socket again. No need to have lots of permanently open sockets.

There are potential catches though if the client is roaming around and hopping between networks. If this is the case then its likely that the ip address will be changing (and client will need to open a new socket and pass the new ip address/socket info to the server). It also increases the chances that the server will fail to communicate with the client.

Sounds like an interesting project. Good luck!

Ages ago, the CF team built an application called the "Lunch Launcher" which was based on WCF store-and-forward messaging. David Kline did a nice series on it (here the last one, which has a TOC for all earlier articles).

There's an on-demand Webcast on MSDN given by Jim Wilson that gives an outline of store-and-forward and the code from that webcast is available here.

This might do what you want, though it got some dependencies (e.g. Exchange) and some inherent limitations (e.g. no built-in delivery confirmation).

Ok, further looking and I may be closer to what I want; which I think i a form of http long poll anyway.

This article here - http://www.codeproject.com/KB/IP/socketsincsharp.aspx - shows how to have a listener on a socket. So I do this on the server side.

Client side then opens a socket to the server at this port; sends it's device ID. Server code first checks to see if there is a response for that device. If there is, it responds.

If not, it either polls itself or subscribes to some event; then returns when it's got data.

I could put in place time out code on the server side if needed.

Blocking on the client end i'm not worried about because it's a background thread and no data is the same as blocking at the app level; as to CPU & batter life, not sure.

I know what i've written is fairly broad, but is this a strategy worth exploring ?