I am using WCF with duplex netTcpBinding and I want to send a message to all users connected currently to my service. I thought I could just create a callback contract and it would send a message to all the clients but it seems I am mistaken, and there isn't a single server/service, each client gets its own service?
I have service with the name 'Server'. Here is how I access the server from the client -
ServerClient client = new ServerClient();
string result = client.SendMessage(messageTextBox.Text);
client.Close();
I thought the 'Server' was a single object that handled all calls by my clients but then I've started a thread in the Server constructor and I found out that multiple threads get started because every time a client calls the Server, a new Server object is created.
So it seems each client has it's own service/server.
With that in mind how do I send a message to all my clients from the server?
I thought the standard practise for accessing the server from the client was to get a proxy object, call the service functions, and then Close the proxy object like in the code above...but if I close the proxy object doesn't it mean I have closed the connection between client and server and now the server won't be able to make duplex callbacks to the client?
1) If you want all clients to share the same server, you need to make your service a singleton. Add this attribute to the class implementing your service (not the interface):
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
That said, I suspect that what you really want is a synchronized, static (thread-shared) instance of a List<ServerClient>. Then you would iterate over that to send a message to each client. With that design, you wouldn't need a singleton server (just some good thread safety around the list).
2) If the clients close their server proxies, the server will not be able to send them any messages. You need to keep the proxy open and stash them somewhere in the client. This design will of course significantly limit scalability.
By default each client will get its own instance of the service. You can however make your service a singleton (which will than process requests from all client).
You may also want to skim through this Instance management article
Related
I have an client server software that uses WCF duplex channel to connect them.
Most of the communication is done from the client to the server but i also have some callbacks from the server to the client.
My problem begins with the fact that i need to allow flash client to consume that data from the server.
I added another endPoint with basicHttpBinding so the flash client will be able to connect to it and now i am stuck without a solution to the callback.
What is the best solution to allow duplex connection between the flash client and the server ?
I managed to find a solution and now i am testing to see if it will fit my needs,
Long Puling between the flash client and my WCF service,
It means that the client will need to make a call to the server and the server will hold that connection and wont return until he will have an update (or if i will define some timeout for the connection)
After the client will receive an answer (return value) from that function he will make that call again.
This way i can simulate a callback from the server to the client,
Hope it will help someone.
When i will be done i will upload some code
I'm creating a WCF service (to be run in IIS) that a client can talk to. Periodically I want my server to send a heartbeat to a Master server.
At the moment the only way I see to do this is to create a second Windows Service that will send out the heartbeat.
Is there any way to get my original WCF service to run an event periodically so that I can get everything done with just one service?
Not really a good way in a WCF service
If the service is going to get some use you may be able to store the NextHeartBeat timestamp and every request check if it's time to send out a message to the master server.
What you want to do may be achieved with server push or full-duplex approaches. But for heartbeat you might get around with a simple http ping using a WebClient as described here. When self-hosting (non IIS) you can override ServiceBase.OnStart/OnStop and start/stop a timer to periodically trigger the ping.
However, hosting a WCF service in IIS usually means that your service is instantiated on a per-request basis so there is no service instance hanging around to send an enduring ping.
It depends on the purpose you need the heartbeat to the Master Server. Could you instead let the master server periodically do a request on the WCF service?
If you really are in the need for a long running service then hosting WCF in a Windows Service instead of IIS might be an option.
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.
I have a WCF webservice that acts as a data provider for my ASP.NET web page.
Throughout the web page a number of calls are made to the web service via the auto-generated ServiceClient.
Currently I create a new ServiceClient and open it for each request i.e. Get Users, Get Roles, Get Customer list etc.... Each one of these would create a new ServiceClient and open a new connection.
Can I make my ServiceClient class a global or statically available class so that all functions within my ASP.NET web page can use the same client. This would seem to be far more efficient. Are there any issues with doing it this way? Any advice I should take into account when doing this?
What happens if I make multiple requests to a client? Presumably it is all synchronous so it shouldn't matter if I make 1 or 50 calls to it?
Thanks
When session (wsHttp with security context or reliable session) or connection (net.tcp, net.pipe) oriented binding is used you have to handle your proxy in the way you want to handle the session. So if you share the proxy, all calls will be handled in single WCF session (by default handled by single service instance). But you have to deal with additional complexity like: Unhandled service exception will terminate your channel and following call from client will result in exception.
When session-less HTTP binding (basicHttp, webHttp) is used you can share your proxy or even make it static. Each call is handled separately, exception on a service will not fault the channel and it transparently reuses opened HTTP persistent connections. But because of this, there should be no big overhead to creating new proxy / channel.
So my suggestion is: When you need several calls to your service in single request processing in your ASP.NET application, use the same proxy / channel. But don't share proxy / channel among different requests.
I think using a ChannelFactory could take of your problem. If I'm right the ChannelFactory has a pool of your connection and re-uses the channels. The advantage of this is that the channels don't get instatiated each time, only the first.
Read more here: ChannelFactory
To handle the disposing of the channels you need some special handling since the channel can throw exception in dispose. I wrote a mapper to handle this, you can read about it here: http://blog.tomasjansson.com/2010/12/disposible-wcf-client-wrapper/
I am a newbie in remoting concepts(C# Remoting).Actually i done some projects using
remoting concepts, i need to employ a proxy between the client and server , if client
wants to communicate with the server or vice-versa it should be done through this proxy
only.i saw a namespace Remoting.Proxy ,will it help? anyone giveme some suggestions on
how to do this it will be very useful for me.
I heard that if the request is through proxy it will be more secure.if my server address is(182.575.069.67) and my proxy runs in 192.168.0.8 then all my clients must send their messages to the proxy and the proxy server must forward this to the actual server.This is what i am trying to do
The "Proxy" namespace refers to the idea that there needs to be a local object, working en-proxy for the remoting client.
If you need all traffic to the server to go through a proxy, you should create two executables: the server, and the proxy server.
The server could accept requests only from the proxy service, while the proxy service itself could be promiscuous.
However, I'm not sure why you would need to set up a proxy service, since you should be able to put any of your autorization / authentication code directly into the server service anyways.
Proxies in C# (especially in the System.Remoting namespace) are local, in-process objects that represent an object in a different process.
They're named after the Proxy Object pattern, not after proxy servers.