We want to implement a client server application. here is the scenario.
Server listens for client 24/7.
Server accept request for client and save it in DB for further process.
Once processing is done (it may take few hours), Server will response back to client.
in short , client and server listens for each other 24/7.
I want to implement it in C# but i also want that it should be accessibly from all platforms.
Also is it possible in WCF?
I agree with Yuck, this is a basic WCF scenario. There a few articles, videos and tutorials to get you started here http://msdn.microsoft.com/en-us/netframework/dd939784
Related
I'm trying to create PHP server to communicate with multiple WPF applications (c#), I want it similar to signalR working, where client will subscribe and server broadcast the updates to all clients subscribe with the server.
Please suggest how to start this, I have WPF application running, I need to create the PHP server, i think socket will be used here, as client application will be running all the time and listening to any update from the server.
Any Hint is appreciable.
As you guessed you need to implement sockets to enable communication between your server and the clients. Find a explanation and code example in this youtube video (C#). For the beginning this should help you with your server (php) implementation.
Typically the server is listening for incoming connections and will then deal with them (like it is explained in the video). As I do not know enough of your environment I suggest two options:
One: You make your clients listen for incoming connections. In reference to the video you need to switch the implementations of the server and client socket. For establishing a connection between the server and the client the server needs an address which is normally the ip address.
Two: You can use the typical approach and let the server listen for connections. To imitate the function of the server pushing to the client, you could use a timer at client site and recurringly ask the server for an update. This approch is handy in the case that you can not address your clients from the server as you may not know their ip address for example.
You may want to improve your performance with threading. Find further information here
I am trying to write a monitoring tool to monitor some information
It will gonna work on azure normally. So i gonna host the database on azure also the webservice will be hosted at azure.
On the client's i read from the config file how many time's he need to update the information to the azure database ( with the webservice on azure ).
Now i want to send also some commands to the client itself. Like start service, .... what is the best way to do that?
How can i send it from a website that is hosted on the azure platform?
I think you should consider implementing a WCF service at the client as well. The Azure side of your software could call operations from this service when it needs to instruct the client to do something.
The WCF service at the client should be something simple,hosted in a Windows Service or in your actual client (whatever it is... win forms, console, etc).
Since you have no VPN, it sounds like you may have a problem with hosting a WCF service on the client. If the client is behind a firewall, you would have to modify the firewall configuration to allow your server to connect to this service.
Last time I had to do a service like this, I used Comet. The server maintains a queue of messages to be sent to the client. Your client connects to the web service and requests any available messages. If messages are available, the server returns them. If not, the server leaves the request open for some time. As soon as a message arrives, the server sends it down the already-open connection. The client will either periodically time out/reconnect or send a keep-alive message (perhaps once per minute) in order to keep the connection alive in the intervening firewalls.
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 message 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 ?
I have a task to do and I am new to networking, so like to discuss before coding down. I have to write down server side UDP application. Server listens for connection request from many clients (could be 100 or more). When it receives it then it does some handshake, by sending acknowledge back and forth couple of times, with the client application to know its identity. When connection is established it receives different types of data from the clients which it does processing and put in the sql database and send acknowledge back to client. Periodically send command to clients for specific information it requires.
I am using C# with Visual Studio 2005. Should I use multi threading? threadpool? Asynchronous or sync UDP Server?
Thanks in advance.
Are you sure what you want is a UDP server? Terms such as "connections", "handshakes" are all TCP related.
I would use asynchronous methods in both the server and the client. It will complicate things, especially in the client.
The reason is that you write that the server will send stuff to the client sometimes. This makes a simple request/reply type of communication impossible (the client calls Send and then uses Receive until a proper answer have been received).
If you can scrap that requirement I would use synchronous clients (do some polling instead) which would make stuff a lot easier for you to understand.
If you have .Net 3.5, why don't you create a WCF service instead? It supports TCP and callbacks (server can call stuff in the client).
After looking into WCF, I don't believe it can do what I need it to. What would be the appropriate way (if I have a server and client application, both C# .NET Console apps) to basically instruct the client to execute functions?
For example, if the client application has functions such as DownloadFTPFile(), CreateWindowsService(), IsServiceRunning(), etc. what would be the standard approach to telling them to execute this from the client?
I was initially just going to have the client interpret messages sent from the server, such as "downloadfile ftp://filename.zip" but I am wondering if there is a better way.
Client has Agent.
Agent connects to server, polls for cmomands
Agend executes comands.
THe server sending is tricky unless you control the environment. NAT for example makes "client sends" a nightmare. You also then open up the client for additional attacks with client polling the clietn firewall does not have tp open external access to the agent.
It is possible.
Use the callback functions along with duplexes in the WCF. You will be limited to the intranet usage or azure though, since only NetTcpBinding and NetTcpRelayBinding support it (WsHttpBinding is deprecated).
With WCF, any client can self-host a WCF service. This can make the client be a service. Add a little extra protocol between the client and the service, and you've got your wish.