I have a Windows Service that takes the name of a bunch of files and do operations on them (zip/unzip, updating db etc). The operations can take time depending on size and number of files sent to the service.
(1) The module that is sending a request to this service waits until the files are processed. I want to know if there is a way to provide a callback in the service that will notify the calling module when it is finished processing the files. Please note that multiple modules can call the service at a time to process files so the service will need to provide some kind of a TaskId I guess.
(2) If a service method is called and is running and another call is made to the same service, then how will that call be processed(I think there is only one thread asociated with the service). I have seen that when the service is taking time in processing a method, the threads associated with the service begin to increase.
WCF does indeed offer duplex bindings which allow you to specify a callback contract, so that the service can call back to the calling client to notify.
However, in my opinion, this mechanism is rather flaky and not really to be recommended.
In such a case, when the call causes a fairly long running operation to happen, I would do something like this:
If you want to stick to HTTP/NetTcp bindings, I would:
drop off the request with the service, and then "let go" - this would be a one-way call, you just drop off what you want to have done, and then your client is done
have a status call that the client could call after a given time to find out whether or not the results of the request are ready by now
if they are, there should be a third service call to retrieve the results
So in your case, you could drop off the request to zip some files. The service would go off and do its work and store the resulting ZIP in a temporary location. Then later on the client could check to see whether the ZIP is ready, and if so, retrieve it.
This works even better over a message queue (MSMQ) which is present in every Windows server machine (but not a lot of people seem to know about it or use it):
your client drops off the request on a request queue
the service listens on that request queue and fetches request after request and does it works
the service can then post the results to a result queue, on which your callers in turn are listening
Check out how to do all of this efficiently by reading the excellent MSDN article Foudnations: Build a queue WCF Response Service - highly recommended!
A message-queue based systems tends to be much more stable and less error-prone that a duplex-/callback-contract based system, in my opinion.
(1) The simplest way to achieve this is with a taskId as you note, and then have another method called IsTaskComplete with which client can check whether the task has been completed.
(2) Additional calls made to the service will start new threads.
edit: the default service behaviour is to start new threads per call. The configurable property is Instance Context Mode, and can be set to PerCall, PerSession, or Shareable.
The question has a solution, but I'm using a WCF duplex service to get the result of a long operation, and even though I found a problem that has cost me several hours to solve (and that's why I searched this question earlier), now it works perfectly, and I believe it is a simple solution within the WCF duplex service framework.
What is the problem with a long operation? The main problem is blocking the client interface while the server performs the operation, and with the WCF duplex service we can use a call back to the client to avoid the blockage (It is an old method to avoid blocking but it can easily be transformed into the async/await framework using a TaskCompletionSource).
In short, the solution uses a method to start the operation asynchronously on the server and returns immediately. When the results are ready, the server returns them by means of the client call back.
First, you have to follow any standard guide to create WCF duplex services and clients, and I found these two useful:
msdn duplex service
Codeproject Article WCF Duplex Service
Then follow these steps adding your own code:
Define the call back interface with an event manager method to send results from the server and receive them in the client.
public interface ILongOperationCallBack
{
[OperationContract(IsOneWay = true)]
void OnResultsSend(....);
}
Define the Service Interface with a method to pass the parameters needed by the long operation (refer the previous ILongOperationCallBack interface in the CallBackContractAttribute)
[ServiceContract(CallbackContract=typeof(ILongOperationCallBack))]
public interface ILongOperationService
{
[OperationContract]
bool StartLongOperation(...);
}
In the Service class that implements the Service Interface, first get the proxy of the client call back and save it in a class field, then start the long operation work asynchronously and return the bool value immediately. When the long operation work is finished send the results to the client using the client call back proxy field.
public class LongOperationService:ILongOperationService
{
ILongOperationCallBack clientCallBackProxy;
public ILongOperationCallBack ClientCallBackProxy
{
get
{
return OperationContext.Current.GetCallbackChannel<ITrialServiceCallBack>());
}
}
public bool StartLongOperation(....)
{
if(!server.IsBusy)
{
//set server busy state
//**Important get the client call back proxy here and save it in a class field.**
this.clientCallBackProxy=ClientCallBackProxy;
//start long operation in any asynchronous way
......LongOperationWorkAsync(....)
return true; //return inmediately
}
else return false;
}
private void LongOperationWorkAsync(.....)
{
.... do work...
//send results when finished using the cached client call back proxy
this.clientCallBackProxy.SendResults(....);
//clear server busy state
}
....
}
In the client create a class that implements ILongOperationCallBack to receive results and add a method to start the long operation in the server (the start method and the event manager don't need to be in the same class)
public class LongOperationManager: ILongOperationCallBack
{
public busy StartLongOperation(ILongOperationService server, ....)
{
//here you can make the method async using a TaskCompletionSource
if(server.StartLongOperation(...)) Console.WriteLine("long oper started");
else Console.Writeline("Long Operation Server is busy")
}
public void OnResultsSend(.....)
{
... use long operation results..
//Complete the TaskCompletionSource if you used one
}
}
NOTES:
I use the bool return in the StartLongOperation method to indicate that the server is Busy as opposed to down, but it is only necessary when the long operation can't be concurrent as in my actual application, and maybe there are best ways in WCF to achieve non concurrency (to discover if the server is down, add a Try/Catch block as usual).
The important quote that I didn't see documented is the need to cache the call back client proxy in the StartLongOperation method. My problem was that I was trying to get the the proxy in the working method (yes, all the examples use the call back client proxy in the service method, but it isn't explicity stated in the documentation, and in the case of a long operation we must delay the call back until the operation ends).
Do not get and cache twice the call back Proxy after a service method has returned and before the next one.
Disclaimer: I haven't added code to control errors, etc.
Related
For various reasons, over the years the company I work for have invested considerably into using Windows Communication Foundation (WCF). We are currently in the process of upgrading our main development platform from Visual Studio 2015 to Visual Studio 2022. Sadly, we are discovering that our WCF client and server applications need more work than we expected to upgrade them to Visual Studio 2022 and newer .NET frameworks; they certainly are not as slick as they used to be. We are planning on keeping our existing applications that use WCF as they are but are considering other options for new applications. The main option that seems to be the one being pushed is gRpc, however, from what I have learnt about it so far, for some of the kinds of things we want to do, it would seem to be a very poor substitute. For us some of the key things we value in WCF are:
One way function calls (i.e. a call that so long as we know gets
delivered, we do not need to wait until it completes). I understand
that this is achievable with gRpc.
Full two way communication (i.e.
clients can make calls onto the server, and also the other way
around; the server can make calls onto the clients). I understand
that using “streams” this can be approximated to with gRPC, but not
easily.
To illustrate, consider a simplified scenario involving three application types:
Sound Requester. An application that requests the playing of different sounds at different locations, and also change the sound parameters.
Sound Player. An application that can play requested sounds and change their parameters. It can give notification that a sound has finished.
Sound Handler Proxy. An application that sits between sound requesters and sound players.
Our WCF implementation of this has the Sound Handler Proxy as the WCF server, the Sound Requester and Sound Player applications are clients that connect to the server. This suits us nicely; the proxy does not need to know which players and requesters to connect to, they connect to it (and can do so at any time). The proxy just provides a ‘marshalling’ service. Below is a simplified sequence diagram to illustrate the kind of calls that could be made:
My question is “If implementing this using gRpc, how would we implement the calls on SoundPlayer (e.g. CreateSound, PlaySound etc.)?” If my understanding is correct, since SoundPlayer is a client (not a server), we would need to implement these as streams that come as ‘returns’ from a call from the player to the server. Is there an easier way? (I appreciate that we could make the SoundPlayer a server that the SoundHandlerProxy could connect to as a client – but that would mean the proxy would need to know about all the players it is going to connect to, something we would rather avoid.)
Alternatively, is there something other than gRpc that we could migrate to (preferably, something that is going to be stable for at least the next decade)?
I'm not a .Net expert, so I may get some details wrong. But I think the gist is right.
One-way services aren't all that interesting on-the-wire, as they are still use HTTP request/response. From the One-Way Sample
When the operation is called, the service returns an HTTP status code of 202 before the service operation has executed... The client that called the operation blocks until it receives the 202 response from the service.
So they are more of a stub feature and can be emulated without too much trouble in gRPC. In gRPC, you'd define the method to return google.protobuf.Empty, and on server-side start long-running work in another thread and return immediately.
service Foo {
rpc Bar(BarRequest) returns (google.protobuf.Empty);
}
public class FooService : Foo.FooBase
{
public override Task<Empty> Bar(BarRequest request,
ServerCallContext context)
{
startProcessingInAnotherThread(request);
return Task.FromResult(new Empty {});
}
}
Full two way communication seems to be the same as Duplex Services. These work by configuring the client to know how the server can reach it (its host:port). Then the client sends that information to the server for the server send RPCs back to it in the future. There are definitely security impacts of such a design and you should look into the security model you are using.
This would be emulated in gRPC by the client just sending the server a channel address string and then the server creating a channel to that address.
service SoundHandler {
rpc Connect(ConnectRequest) returns (google.protobuf.Empty);
}
message ConnectRequest {
enum Type {
TYPE_UNKNOWN = 0;
TYPE_SOUND_REQUESTER = 1;
TYPE_SOUND_PLAYER = 2;
};
string channelAddress = 1;
Type type = 2;
}
service SoundPlayer {
rpc CreateSound(CreateSoundRequest) returns (CreateSoundResponse);
// ...
}
service SoundEventReceiver {
rpc SoundFinished(SoundFinishedRequest) returns (SoundFinishedResponse);
}
Then, in the service you'd create a channel to the provided address for callbacks.
public class SoundHandlerService : SoundHandler.SoundHandlerBase
{
public override Task<Empty> Bar(ConnectRequest request,
ServerCallContext context)
{
var channel = GrpcChannel.ForAddress(request.channelAddress);
if (request.type == TYPE_SOUND_PLAYER) {
var channel = GrpcChannel.ForAddress(request.channelAddress);
var client = new SoundPlayer.SoundPlayerClient(channel);
registerSoundPlayer(channel, client);
} // ...
return Task.FromResult(new Empty {});
}
}
I'm trying to write this question for the fourth time, as I'm unfortunately not sure what I actually want. Please excuse me being vague or a bit off.
I have a command line .NET4.5 C# application. I'll run it at the same time at two geographically distant locations. I want to be able to turn one instance into host and the other into client.
In the heart of it, I want a TextReader implementation, that upon Read/ReadLine awaits for an input from a remote client. I also want a TextWriter that upon Write/WriteLine will call a remote client and pass text to it.
The TextWriter is of course fairly simple matter, as I basically do that: on write, call client.SendText(s); to the other instance.
How do I go about implementing TextReader.ReadLine() in that scenario? A naive aproach would be to have, in the WCF service, a method:
class Service : IService{
void SendText(string s){
Console.WriteLine(s); // or whatever is the destination TextWriter
}
string ReadLine(){
return Console.ReadLine(); // or whatever is the source TextReader
}
}
but is keeping the WCF operation call open for minutes or even hours a good idea?
Another way I can see is to have:
class Service : IService{
void RegisterClient(string url){/* url points to an IService endpoint in client*/}
void SendString(string s){...}
}
And then host it in both instances, call RegisterClient from client providing own endpoint url and then if host wants to return some data to client - just calls SendString, no problem. But if hosts must wait for input from client, how to solve that reasonably?
class WCFTextReader : TextReader{
public override string ReadLine(){
// what here? it should return whatever comes in the next SendString call from client...
}
}
I could have a Queue<string> of incoming messages and then do a while(true) and either return first from Queue or Thread.Sleep for a short while and re-check, but every time I feel that I need while(true) and Thread.Sleep I'd rather come here, because I think I'm missing something....
The default WCF message pattern is request/response; a client sends a request, and the server responds to it.
There is, however, a duplex message pattern, in which the service interface contract identifies another interface as its callback interface contract; the client must implement this callback interface contract, similar to how the service must implement the service interface contract.
This message pattern should allow your server to arbitrarily send a message to the client without the client having to prompt it to do so.
http://msdn.microsoft.com/en-us/library/ms731064%28v=vs.110%29.aspx
http://msdn.microsoft.com/en-us/library/ms731184%28v=vs.110%29.aspx
** Fair warning: in my experience, you potentially still have to deal with the issue of keeping the connection alive, in case you plan to have the server send a message back to the client after a significant period of inactivity.
If keeping the connection open is acceptable to you, then you can implement some kind of keep-alive mechanism.
If keeping the connection open is not acceptable, then I think you'd need to look at a more complex approach that would involve the client periodically checking in with the server in order to give the server an opportunity to send the client any queued up messages that it has for the client.
I have a .net Webservice. It has a method that does a task that takes 60 seconds and after that, returns the string result to client.
In some networks especially low band widths I get timeout error in 40 seconds before webservice method do its task in 60 second.
Now I want to implement webservice Async call to support low band width networks.
In Async webservice call an approach is using a thread that runs webservice method and returns webservice result to main thread that is shown in the following picture.
But my problem will not be solved in this approach because that thread uses one connection.
I need another approach. A thread in my client call webservice method and method starts its operation and when the task is done, 1) webservice sends a message that your response is ready or, 2) client checks if the webservice response is ready (I think polling mechanism) like the following picture.
How can I implement the second approach in .net? Is it possible?
Thanks.
Create a table on your database to store the state of the process.
UniqClientId, ProcessId, StartTime, EndTime and any other state if required.
Client sends a request to the server by passing its unique id.
Server logs the process on the above table and initiates the process.
Clients contacts the server instantly(2-3 sec or 15-20 sec depending on your application) to check the process completion.
If the client get a response that process has been completed, then it requests the server to send the response.
In between, the server does the following job.
When the process completes, stores the EndTime on above table.
Provides a method to send the process state by checking the above table.
Provides a method to send the response.
I'm not sure what exactly your service is doing, but if the operation of your process is just to modify some table on the database, then is is not difficult to implement this.
.NET 3.5, VS2008, WCF service using BasicHttpBinding
I have a WCF service hosted in a Windows service. When the Windows service shuts down, due to upgrades, scheduled maintenance, etc, I need to gracefully shut down my WCF service. The WCF service has methods that can take up to several seconds to complete, and typical volume is 2-5 method calls per second. I need to shut down the WCF service in a way that allows any previously call methods to complete, while denying any new calls. In this manner, I can reach a quiet state in ~ 5-10 seconds and then complete the shutdown cycle of my Windows service.
Calling ServiceHost.Close seems like the right approach, but it closes client connections right away, without waiting for any methods in progress to complete. My WCF service completes its method, but there is no one to send the response to, because the client has already been disconnected. This is the solution suggested by this question.
Here is the sequence of events:
Client calls method on service, using the VS generated proxy class
Service begins execution of service method
Service receives a request to shut down
Service calls ServiceHost.Close (or BeginClose)
Client is disconnected, and receives a System.ServiceModel.CommunicationException
Service completes service method.
Eventually service detects it has no more work to do (through application logic) and terminates.
What I need is for the client connections to be kept open so the clients know that their service methods completed sucessfully. Right now they just get a closed connection and don't know if the service method completed successfully or not. Prior to using WCF, I was using sockets and was able to do this by controlling the Socket directly. (ie stop the Accept loop while still doing Receive and Send)
It is important that the host HTTP port is closed so that the upstream firewall can direct traffic to another host system, but existing connections are left open to allow the existing method calls to complete.
Is there a way to accomplish this in WCF?
Things I have tried:
ServiceHost.Close() - closes clients right away
ServiceHost.ChannelDispatchers - call Listener.Close() on each - doesn't seem to do anything
ServiceHost.ChannelDispatchers - call CloseInput() on each - closes clients right away
Override ServiceHost.OnClosing() - lets me delay the Close until I decide it is ok to close, but new connections are allowed during this time
Remove the endpoint using the technique described here. This wipes out everything.
Running a network sniffer to observe ServiceHost.Close(). The host just closes the connection, no response is sent.
Thanks
Edit: Unfortunately I cannot implement an application-level advisory response that the system is shutting down, because the clients in the field are already deployed. (I only control the service, not the clients)
Edit: I used the Redgate Reflector to look at Microsoft's implementation of ServiceHost.Close. Unfortunately, it calls some internal helper classes that my code can't access.
Edit: I haven't found the complete solution I was looking for, but Benjamin's suggestion to use the IMessageDispatchInspector to reject requests prior to entering the service method came closest.
Guessing:
Have you tried to grab the binding at runtime (from the endpoints), cast it to BasicHttpBinding and (re)define the properties there?
Best guesses from me:
OpenTimeout
MaxReceivedMessageSize
ReaderQuotas
Those can be set at runtime according to the documentation and seem to allow the desired behaviour (blocking new clients). This wouldn't help with the "upstream firewall/load balancer needs to reroute" part though.
Last guess: Can you (the documention says yes, but I'm not sure what the consequences are) redefine the address of the endpoint(s) to a localhost address on demand?
This might work as a "Port close" for the firewall host as well, if it doesn't kill of all clients anyway..
Edit: While playing with the suggestions above and a limited test I started playing with a message inspector/behavior combination that looks promising for now:
public class WCFFilter : IServiceBehavior, IDispatchMessageInspector {
private readonly object blockLock = new object();
private bool blockCalls = false;
public bool BlockRequests {
get {
lock (blockLock) {
return blockCalls;
}
}
set {
lock (blockLock) {
blockCalls = !blockCalls;
}
}
}
public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) {
}
public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters) {
}
public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) {
foreach (ChannelDispatcher channelDispatcher in serviceHostBase.ChannelDispatchers) {
foreach (EndpointDispatcher endpointDispatcher in channelDispatcher.Endpoints) {
endpointDispatcher.DispatchRuntime.MessageInspectors.Add(this);
}
}
}
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) {
lock (blockLock) {
if (blockCalls)
request.Close();
}
return null;
}
public void BeforeSendReply(ref Message reply, object correlationState) {
}
}
Forget about the crappy lock usage etc., but using this with a very simple WCF test (returning a random number with a Thread.Sleep inside) like this:
var sh = new ServiceHost(new WCFTestService(), baseAdresses);
var filter = new WCFFilter();
sh.Description.Behaviors.Add(filter);
and later flipping the BlockRequests property I get the following behavior (again: This is of course a very, very simplified example, but I hope it might work for you anyway):
// I spawn 3 threads
Requesting a number..
Requesting a number..
Requesting a number..
// Server side log for one incoming request
Incoming request for a number.
// Main loop flips the "block everything" bool
Blocking access from here on.
// 3 more clients after that, for good measure
Requesting a number..
Requesting a number..
Requesting a number..
// First request (with server side log, see above) completes sucessfully
Received 1569129641
// All other messages never made it to the server yet and die with a fault
Error in client request spawned after the block.
Error in client request spawned after the block.
Error in client request spawned after the block.
Error in client request before the block.
Error in client request before the block.
Is there an api for the upstream firewall? The way we do this in our application is to stop new requests coming in at the load balancer level, and then when all of the requests have finished processing we can restart the servers and services.
My suggestion is to set an EventHandler when your service goes into a "stopping state", use the OnStop method. Set the EventHandler indicating that your service is going into a stopping state.
Your normal service loop should check if this event is set, if it is, return a "Service is stopping message" to the calling client, and do not allow it to enter your normal routine.
While you still have active processes running, let it finish, before the OnStop method moves on to killing the WCF host (ServiceHost.Close).
Another way is to keep track of the active calls by implementing your own reference counter. you will then know when you can stop the Service Host, once the reference counter hits zero, and by implementing the above check for when the stop event has been initiated.
Hope this helps.
I haven't implemented this myself, so YMMV, but I believe what you're looking to do is pause the service prior to fully stopping it. Pausing can be used to refuse new connections while completing existing requests.
In .NET it appears the approach to pausing the service is to use the ServiceController.
Does this WCF Service authenticate the user in any way?
Do you have any "Handshake" method?
I think you might need to write your own implementation with a helper class that keeps track of all running requests, then when a shutdown is requested, you can find out if anything is still running, delay shutdown based on that... (using a timer maybe?)
Not sure about blocking further incoming requests... you should have a global variable that tells your application whether a shutdown was requested and so you could deny further requests ...
Hope this may help you.
Maybe you should set the
ServiceBehaviorAttribute and the OperationBehavior attribute. Check this on MSDN
In addition to the answer from Matthew Steeples.
Most serious load balancers like a F5 etc. have a mechanism to identify if a node is alive. In your case it seems to check whether a certain port is open. But alternative ways can be configured easily.
So you could expose e.g. two services: the real service that serves requests, and a monitoring "heart beat"-like service. When transitioning into maintenance mode, you could first take the monitoring service offline which will take the load away from the node and only shutdown the real service after all requests finished processing. Sounds a bit weird but might help in your scenario...
I want to create a simple client-server example in WCF. I did some testing with callbacks, and it works fine so far. I played around a little bit with the following interface:
[ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof(IStringCallback))]
public interface ISubscribeableService
{
[OperationContract]
void ExecuteStringCallBack(string value);
[OperationContract]
ServerInformation Subscribe(ClientInformation c);
[OperationContract]
ServerInformation Unsubscribe(ClientInformation c);
}
Its a simple example. a little bit adjusted. You can ask the server to "execute a string callback" in which case the server reversed the string and calls all subscribed client callbacks.
Now, here comes the question: If I want to implement a system where all clients "register" with the server, and the server can "ask" the clients if they are still alive, would you implement this with callbacks (so instead of this "stringcallback" a kind of TellTheClientThatIAmStillHereCallback). By checking the communication state on the callback I can also "know" if a client is dead. Something similar to this:
Subscribers.ForEach(delegate(IStringCallback callback)
{
if (((ICommunicationObject)callback).State == CommunicationState.Opened)
{
callback.StringCallbackFunction(new string(retVal));
}
else
{
Subscribers.Remove(callback);
}
});
My problem, put in another way:
The server might have 3 clients
Client A dies (I pull the plug of the laptop)
The server dies and comes back online
A new client comes up
So basically, would you use callbacks to verify the "still living state" of clients, or would you use polling and keep track "how long I havent heard of a client"...
You can detect most changes to the connection state via the Closed, Closing, and Faulted events of ICommunicationObject. You can hook them at the same time that you set up the callback. This is definitely better than polling.
IIRC, the Faulted event will only fire after you actually try to use the callback (unsuccessfully). So if the Client just disappears - for example, a hard reboot or power-off - then you won't be notified right away. But do you need to be? And if so, why?
A WCF callback might fail at any time, and you always need to keep this in the back of your mind. Even if both the client and server are fine, you might still end up with a faulted channel due to an exception or a network outage. Or maybe the client went offline sometime between your last poll and your current operation. The point is, as long as you code your callback operations defensively (which is good practice anyway), then hooking the events above is usually enough for most designs. If an error occurs for any reason - including a client failing to respond - the Faulted event will kick in and run your cleanup code.
This is what I would refer to as the passive/lazy approach and requires less coding and network chatter than polling or keep-alive approaches.
If you enable reliable sessions, WCF internally maintains a keep-alive control mechanism. It regularly checks, via hidden infrastructure test messages, if the other end is still there. The time interval of these checks can be influenced via the ReliableSession.InactivityTimeout property. If you set the property to, say, 20 seconds, then the ICommunicationObject.Faulted event will be raised about 20 to 30 (maximum) seconds after a service breakdown has occurred on the other side.
If you want to be sure that client applications always remain "auto-connected", even after temporary service breakdowns, you may want to use a worker thread (from the thread pool) that repeatedly tries to create a new proxy instance on the client side, and calls a session-initiating operation, after the Faulted event has been raised there.
As a second approach, since you are implementing a worker thread mechanism anyway, you might also ignore the Faulted event and let the worker thread loop during the whole lifetime of the client application. You let the thread repeatedly check the proxy state, and try to do its repair work whenever the state is faulted.
Using the first or the second approach, you can implement a service bus architecture (mediator pattern), guaranteeing that all client application instances are constantly ready to receive "spontaneous" service messages whenever the service is running.
Of course, this only works if the reliable session "as such" is configured correctly to begin with (using a session-capable binding, and applying the ServiceContractAttribute.SessionMode, ServiceBehaviorAttribute.InstanceContextMode, OperationContractAttribute.IsInitiating, and OperationContractAttribute.IsTerminating properties in meaningful ways).
I had a similar situation using WCF and callbacks. I did not want to use polling, but I was using a "reilable" protocol, so if a client died, then it would hang the server until it timed out and crashed.
I do not know if this is the most correct or elegant solution, but what I did was create a class in the service to represent the client proxy. Each instance of this class contained a reference to the client proxy, and would execute the callback function whenever the server set the "message" property of the class. By doing this, when a client disconnected, the individual wrapper class would get the timeout excetpion, and remove itself from the server's list of listeners, but the service would not have to wait for it. This doesn't actually answer your question about determining if the client is alive, but it is another way of structuring the service to addrss the issue. If you needed to know when a client died, you would be able to pick up when the client wrapper removed itself from the listener list.
I have not tried to use WCF callbacks over the wire but i have used them for interprocess communication. I was having a problem where call of the calls that were being sent were ending up on the same thread and making the service dead lock when there were calls that were dependant on the same thread.
This may apply to the problem that you are currently have so here is what I had to do to fix the problem.
Put this attribute onto the server and client of the WCF server implemetation class
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
public class WCFServerClass
The ConcurrencyMode.Multiple makes each call process on its own thread which should help you with the server locking up when a client dies until it timesout.
I also made sure to use a Thread Pool on the client side to make sure that there were no threading issues on the client side