We Keep Coding

C# threading help needed

I've been asked to write a method that will allow a caller to send a command string to a hardware device via the serial port. After sending the command the method must wait for a response from the device, which it then returns to the caller.
To complicate things the hardware device periodically sends unsolicited packets of data to the PC (data that the app must store for reporting). So when I send a serial command, I may receive one or more data packets before receiving the command response.
Other considerations: there may be multiple clients sending serial commands potentially at the same time as this method will form the basis of a WCF service. Also, the method needs to be synchronous (for reasons I won't go into here), so that rules out using a callback to return the response to the client.
Regarding the "multiple clients", I was planning to use a BlockingCollection<> to queue the incoming commands, with a background thread that executes the tasks one at a time, thus avoiding serial port contention.
However I'm not sure how to deal with the incoming serial data. My initial thoughts were to have another background thread that continually reads the serial port, storing data analysis packets, but also looking for command responses. When one is received the thread would somehow return the response data to the method that originally sent the serial command (which has been waiting ever since doing so - remember I have a stipulation that the method is synchronous).
It's this last bit I'm unsure of - how can I get my method to wait until the background thread has received the command's response? And how can I pass the response from the background thread to my waiting method, so it can return it to the caller? I'm new to threading so am I going about this the wrong way?
Thanks in advance
Andy

First of all: When you use the SerialPort class that comes with the framework, the data received event is asynchronous already. When you send something, data is coming in asynchronously.
What I'd try is: queue all requests that need to wait for an answer. In the overall receive handler, check whether the incoming data is the answer for one of the requests. If so, store the reply along with the request information (create some kind of state class for that). All other incoming data is handled normally.
So, how to make the requests wait for an answer? The call that is to send the command and return the reply would create the state object, queue it and also monitor the object to see whether an answer was received. If an answer was received, the call returns the result.
A possible outline could be:
string SendAndWait(string command)
{
StateObject state = new StateObject(command);
state.ReplyReceived = new ManualResetEvent(false);
try
{
SerialPortHandler.Instance.SendRequest(command, state);
state.ReplyReceived.WaitOne();
}
finally
{
state.ReplyReceived.Close();
}
return state.Reply;
}
What's SerialPortHandler? I'd make this a singleton class which contains an Instance property to access the singleton instance. This class does all the serial port stuff. It should also contain an event that is raised when "out of band" information comes in (data that is not a reply to a command).
It also contains the SendRequest method which sends the command to the serial device, stores the state object in an internal list, waits for the command's reply to come in and updates the state object with the reply.
The state object contains a wait handle called ReplyReceived which is set by the SerialPortHandler after it has changed the state object's Reply property. That way you don't need a loop and Thread.Sleep. Also, instead of calling WaitOne() you could call WaitOne(timeout) with timeout being a number of milliseconds to wait for the reply to come in. This way you could implement some kind of timeout-feature.
This is how it could look in SerialPortHandler:
void HandlePossibleCommandReply(string reply)
{
StateObject state = FindStateObjectForReply(reply);
if (state != null)
{
state.Reply = reply;
state.ReplyReceived.Set();
m_internalStateList.Remove(state);
}
}
Please note: This is what I'd try to start with. I'm sure this can be very much optimized, but as you see there's not much "multithreading" involved where - only the SendAndWait method should be called in a way so that multiple clients can issue commands while another client is still waiting for its response.
EDIT
Another note: You're saying that the method should form the basis for a WCF service. This makes things easier, as if you configure the service right, a instance of the service class will be created for every call to the service, so the SendAndWait method would "live" in its own instance of the service and doesn't even need to be re-entrant at all. In that case, you just need to make sure that the SerialPortHandler is always active (=> is created and running independently from the actual WCF service), no matter whether there's currently an instance of your service class at all.
EDIT 2
I changed my sample code to not loop and sleep as suggested in the comments.

If you really want to block until the background thread has received your command response, you could look into having the background thread lock an object when you enqueue your command and return that to you. Next, you wait for the lock and continue:
// in main code:
var locker = mySerialManager.Enquee(command);
lock (locker)
{
// this will only be executed, when mySerialManager unlocks the lock
}
// in SerialManager
public object Enqueue(object command)
{
var locker = new Object();
Monitor.Enter(locker);
// NOTE: Monitor.Exit() gets called when command result
// arrives on serial port
EnqueueCommand(command, locker);
return locker;
}

A couple things. You need to be able to tie up serial responses to the commands that requested them. I assume that there's some index or sequence number that goes out with the command and comes back in the response?
Given that, you should be OK. You need some sort of 'serialAPU' class to represent the request and response. I don't know what these are, maybe just strings, I don't know. The class should have an autoResetEvent as well. Anyway, in your 'DoSerialProtocol()' function, create a serialAPU, load it up with request data, queue it off to the serial thread and wait on the autoResetEvent. When the thread gets the serialAPU, it can store an index/sequence number in the serialAPU, store the serialAPU in a vector and send off the request.
When data comes in, do you protocol stuff and, if the data is a valid response, get the index/sequence from the data and look up the matching value in the serialAPU's in the vector. Remove the matching serialAPU from the vector, load it up with the response data and signal the autoResetEvent. The thread that called 'DoSerialProtocol()' originally will then run on and can handle the response data.
There are lots of 'wiggles' of course. Timeouts is one. I would be tempted to have a state enum in the serialAPU, protected by a CritcalSection or atomicCompareandSwap, initialized ot 'Esubmitted'. If the oringinating thread times out its wait on the autoResetEvent, it tries to set the state enum in its serialAPU to 'EtimedOut'. If it succeeds, fine, it returns an error to the caller. Simlarly, in the serial thread, if it finds a serialAPU whose state is EtimedOut, it just removes it from the container. If it finds the serialAPU that matches response data, it tries to change the state to 'EdataRx' and if it succeeds. fires the autoRestEvent.
Another is the annoying OOB data. If that comes in, create a serialAPU, load in the OOB data, set the state to 'EOOBdata' and call some 'OOBevent' with it.

I would advise you to look at the BackgroundWorker-Class
Ther is a Event in this class (RunWorkerCompleted) which is fired when the worker has finished his job.

CommunicationObjectFaulted when using a NamedPipe WCF service

Our .NET app uses 2 AppDomains. The secondary domain needs access to a Logger object that was created in the main appdomain.
This logger is exposed via a WCF service with a named pipe binding.
This is how i create the "client" for this service:
private void InitLogger()
{
if (loggerProxy != null)
{
Logger.Instance.onLogEvent -= loggerProxy.Log;
}
// Connect to the logger proxy.
var ep = new EndpointAddress("net.pipe://localhost/app/log");
var binding = new NetNamedPipeBinding(NetNamedPipeSecurityMode.None);
//Logger.Debug("Creating proxy to Logger object.");
var channelFactory = new ChannelFactory<ILogProvider>(binding, ep);
loggerProxy = channelFactory.CreateChannel();
channelFactory.Faulted += (sender, args) => InitLogger();
channelFactory.Closed += (sender, args) => InitLogger();
Logger.Instance.onLogEvent += loggerProxy.Log;
}
Recently we are getting random CommunicationObjectFaultedException - i suppose this occurs since the channel times out or due to some other reason that i am missing.
This is the reason i have added the handling of the Closed and Faulted events, which seem to not work properly (perhaps i have not used them appropriately).
EDIT: These events are on the Factory object as suggested, so this explains why they are not being raised.
My question is -- how can i avoid these errors?
Our scenario is we need to keep this channel open at all times throughout the application's lifetime, and the access to this Logger service is needed at all times, and shouldn't time out under any circumstance.
Is there any safe practice of handling this type of situation?

Your code is currently handling Closed and Faulted events raised by the ChannelFactory, but it is the state of the Channel itself you need to worry about.
The ChannelFactory is an artefact which encapsulates the translation of the WCF service contract into an instance of the channel runtime: once you have successfully created your channel (loggerProxy), the closing of the ChannelFactory isn't going to affect communications via the channel - the events you are listening for are irrelevant to your problem.
State transitions of the Channel to Closed or Faulted will go unnoticed to this code, with the result that they will surface in Logger.Instance as exceptions thrown when loggerProxy.Log is invoked, and the event you are trying to log will be lost.
Instead of registering loggerProxy.Log directly as the event handler you should consider registering a wrapper function implementing an exception handler and retry loop around the call to loggerProxy.Log. The existing channel should be closed (or if that fails, aborted) in the exception handler, to ensure it is Disposed properly. The retry loop should reinitialise the channel and try the call again.

I'll comment on two things (i) the timeout and (ii) catching the Faulted events.
Firstly the timeout. By default, channels enter the faulted state if they haven't had a communication during the default time period (around 10 minutes). You can either poke the channel frequently with a recurring event, or reset the timeout to something large. I do the latter as follows:
NetNamedPipeBinding binding = new NetNamedPipeBinding();
// Have to set the receive timeout to be big on BOTH SIDES of the pipe, otherwise it gets faulted and can't be used.
binding.ReceiveTimeout = TimeSpan.MaxValue;
DuplexChannelFactory<INodeServiceAPI> pipeFactory =
new DuplexChannelFactory<INodeServiceAPI>(
myCallbacks,
binding,
new EndpointAddress(
"net.pipe://localhost/P2PSN.Node.Service.Pipe"));
myCallbacks is an instance of a class that deals with callbacks in the duplex pipe and INodeServiceAPI is the interface that describes my API.
Secondly you're right in the the factory events will not be fired. You can catch the events on the channel itself. I use the following code.
proxy = pipeFactory.CreateChannel();
if (proxy is IClientChannel)
{
(proxy as IClientChannel).Faulted += new EventHandler(this.proxy_Faulted);
}
Not pleasant, but something I picked up from StackOverflow elsewhere that works. You must include System.ServiceModel to pick up the IClientChannel interface.
HTH.

WCF Wait for operations to finish when closing ServiceHost

I create a WCF SOAP server with an operation that takes some time to perform:
[ServiceContract]
public interface IMyService
{
[OperationContract]
string LongRunningOperation();
}
[ServiceBehavior(
ConcurrencyMode = ConcurrencyMode.Multiple,
UseSynchronizationContext = false,
InstanceContextMode = InstanceContextMode.Single)]
class MyService : IMyService
{
public string LongRunningOperation()
{
Thread.Sleep(20000);
return "Hey!";
}
}
class Program
{
static void Main(string[] args)
{
MyService instance = new MyService();
ServiceHost serviceHost = new ServiceHost(instance);
BasicHttpBinding binding = new BasicHttpBinding();
serviceHost.AddServiceEndpoint(typeof(IMyService), binding, "http://localhost:9080/MyService");
serviceHost.Open();
Console.WriteLine("Service running");
Thread.Sleep(10000);
serviceHost.Close();
Console.WriteLine("Service closed");
Thread.Sleep(30000);
Console.WriteLine("Exiting");
}
}
The ServiceHost is opened, and after 10 seconds I close it.
When calling serviceHost.Close(), all clients currently connected, waiting for LongRunningOperation to finish, are inmediately disconnected.
Is there a wait of closing the ServiceHost in a cleaner way? That is, I want to disable the service listeners, but also wait for all currently connected clients to finish (or specify a maximum timeout).

Im surprised calling ServiceHost.Close is not letting LongRunningOperation complete.
The whole architecture is setup to allow things time to gracefully shut down (e.g. the difference between Close and Abort transitions.). According to MSDN docs:
This method causes a
CommunicationObject to gracefully
transition from any state, other than
the Closed state, into the Closed
state. The Close method allows any
unfinished work to be completed before
returning.
Also there is a CloseTimeout on the ServiceHost for precisely this. Have you tried setting the CloseTimeout to be greater than 20 seconds? (According to Reflector the default CloseTimeout for ServiceHost is 10 seconds...)

In principle, I think something like the following should be possible, though I haven't implemented it to confirm all the details:
Implement a custom IOperationInvoker
wrapping the Dispatcher's normal
OperationInvoker (you'll want an IServiceBehavior to install the wrapped invoker when the service dispatcher runtime is built)
the custom invoker would mostly delegate to the real one, but would also provide
"gate-keeper" functionality to turn away
new requests (e.g. raise a some kind of exception) when the service host is about
to be shut down.
it would also keep track of operation invocations still in
progress and set an event when the last operation invocation finishes or times out.
the main hosting thread would then wait on the invoker's "all finished" event before calling serviceHost.Close().

What you are doing seems all wrong to me. The ServiceHost should never close abruptly. It is a service and should remain available. There is no real way to close gracefully without some participation from the client. When I say close gracefully, this also subjective from a clients perspective.
So I dont think I understand your requirements at all, however one way would be to implement a publish/subscribe pattern and when the host is ready to close, notify all subscribers of this event so that all connections could be closed by each respective client. You can read more about this here http://msdn.microsoft.com/en-us/magazine/cc163537.aspx
Again, this approach to hosting a service is not standard and thats why you are finding it hard to find a solution to this particular problem of yours. If you could elaborate on your use case/usage scenario, it would probably help to find a real solution.

You are describing client side functionality. Sounds like you should wrap the servicehost object and then have your proxy rejecting new requests when it "is closing". You don't close the real servicehost until all calls have been serviced.
You should also take a look at the asynch CTP. To put this kind of logic inside a consumer side "Task" object will be much easier with the upcoming TaskCompletionSource class.
Check this video from dnrtv out. It's not about wcf, but rather about the upcoming language and class support for asynchrony.

How to determine that a WCF Service is ready?

I have the following scenario:
My main Application (APP1) starts a Process (SERVER1). SERVER1 hosts a WCF service via named pipe. I want to connect to this service (from APP1), but sometimes it is not yet ready.
I create the ChannelFactory, open it and let it generate a client. If I now call a method on the generated Client I receive an excpetion whitch tells me that the Enpoint was not found:
var factory = new ChannelFactory<T>(new NetNamedPipeBinding(), new EndpointAddress("net.pipe//localhost/myservice");
factory.Open()
var Client = factory.CreateChannel();
Client.Foo();
If I wait a little bit before calling the service, everything is fine;
var Client = factory.CreateChannel();
Thread.Sleep(2000);
Client.Foo();
How can I ensure, that the Service is ready without having to wait a random amount of time?

If the general case is that you are just waiting for this other service to start up, then you may as well use the approach of having a "Ping" method on your interface that does nothing, and retrying until this starts responding.
We do a similar thing: we try and call a ping method in a loop at startup (1 second between retries), recording in our logs (but ultimately ignoring) any TargetInvocationException that occur trying to reach our service. Once we get the first proper response, we proceed onwards.
Naturally this only covers the startup warmup case - the service could go down after a successfull ping, or it we could get a TargetInvocationException for a reason other than "the service is not ready".

You could have the service signal an event [Edited-see note] once the service host is fully open and the Opened event of the channel listener has fired. The Application would wait on the event before using its proxy.
Note: Using a named event is easy because the .NET type EventWaitHandle gives you everything you need. Using an anonymous event is preferable but a bit more work, since the .NET event wrapper types don't give you an inheritable event handle. But it's still possible if you P/Invoke the Windows DuplicateHandle API yourself to get an inheritable handle, then pass the duplicated handle's value to the child process in its command line arguments.

If you're using .Net 4.0 you could use WS-Discovery to make the service announce its presence via Broadcast IP.
The service could also send a message to a queue (MSMQ binding) with a short lifespan, say a few seconds, which your client can monitor.
Have the service create a signal file, then use a FileSystemWatcher in the client to detect when it gets created.
Just while (!alive) try { alive = client.IsAlive(); } catch { ...reconnect here... } (in your service contract, you just have IsAlive() return true)

I have had the same issue and when using net.pipe*://localhost/serviceName*, I solved it by looking at the process of the self-hosted application.
the way i did that was with a utility class, here is the code.
public static class ServiceLocator
{
public static bool IsWcfStarted()
{
Process[] ProcessList = Process.GetProcesses();
return ProcessList.Any(a => a.ProcessName.StartsWith("MyApplication.Service.Host", StringComparison.Ordinal));
}
public static void StartWcfHost()
{
string path = System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var Process2 = new Process();
var Start2 = new ProcessStartInfo();
Start2.FileName = Path.Combine(path, "Service", "MyApplication.Service.Host.exe");
Process2.StartInfo = Start2;
Process2.Start();
}
}
now, my application isn't called MyApplication but you get my point...
now in my client Apps that use the host i have this call:
if (!ServiceLocator.IsWcfStarted())
{
WriteEventlog("First instance of WCF Client... starting WCF host.")
ServiceLocator.StartWcfHost();
int timeout=0;
while (!ServiceLocator.IsWcfStarted())
{
timeout++;
if(timeout> MAX_RETRY)
{
//show message that probably wcf host is not available, end the client
....
}
}
}
This solved 2 issues,
1. The code errors I had wend away because of the race condition, and 2
2. I know in a controlled manner if the Host crashed due to some issue or misconfiguration.
Hope it helps.
Walter

I attached an event handler to client.InnerChannel.faulted, then reduced the reliableSession to 20 seconds. Within the event handler I removed the existing handler then ran an async method to attempt to connect again and attached the event handler again. Seems to work.

C# Stopping TCP File Transfer

I'm programming simple TCP file transfer using TcpListener on reciever side and TcpClient on sender side. I have 2 options - synchronnous or asynchronnous. If I use synchronnous, I have to put sending/recieving methods into BackgroundWorker, to prevent freezing GUI thread. Asynchronnous version is without problems...
My question is, how to stop running file transfer?
In synchronnous version I tried to use BackgroundWorker.CancelAsync() method, and in every loop iteration check BackgroundWorker.CancellationPending property, but it doesn't seems to work (CancelAsync is probably not setting CancellationPending property) :(
In asynchronnous version I tried to use volatile variable Indicator and in every Callback check its value. Problem is, when I change its value in Stop() method, and than I check it in Callback, callback still reads its previous value :(

CancelASync should work; did you set:
backgroundWorker.WorkerSupportsCancellation = true:

Are you saying that you aren't reading the correct "cancel state" when you check it? This suggests you're not synchronising the flag between your threads correctly.
Or is it just that you won't ever check for the "cancel state" unless you receive some new data? (From the way you describe your tx/rx "loops", in both sync and async cases you will have to receive a new datagram before you will get a chance to check the 'cancel' flag)
If you are in control of both ends of the data transfer, then whichever end (client or server) wishes to abort should ideally send a special datagram to the other end to stop the transfer - otherwise the other end will attempt to continue sending/receiving, not knowing that it's on its own. So perhaps a better approach would be to actually send/receive a "cancel transfer" datagram, which would inform the TCP code at both ends that you wish to cancel. (i.e. you wouldn't need to have a special cancel flag, you would simply check if the datagram you are about to send or have just received is a "cancel transfer" datagram). This would allow both ends to gracefully and cleanly close down.