Develop Reference

Creating a Named Pipe sometimes fails, randomly

The problem at hand is to have a "Container" app and a "Child" app communicate via a named pipe. The problem is the pipe sometimes fails to be created.
When things go smoothly, communication works pretty well.
The problem I'm seeing is that sometimes the Pipe server will fail to initialize. I can see why it happens in some instances, namely that the previous version of my app is still running in the background and did not exit properly for some reason so it's hanging on to the pipe. But, I have also seen it fail when I put in a new random name for the pipe that should not be used by any other processes, this is the part that worries me. Perhaps it is a limitation set by the OS on the same process name OR on visual studio debug mode?
To illustrate this, I have some code that tries to create a server steam (the pipe server):
NamedPipeServerStream server = new NamedPipeServerStream(pipeName, PipeDirection.InOut, 1);
The exception I often see is this:
Could not create server:System.IO.IOException: All pipe instances are busy.
I have tried a few variations of this with security options passed to the pipe + increasing the number of allowed servers from 1 to something higher but then the "Child"/Client might connect to what I assume is another process that is not properly closed out, and hence the wrong pipe server.
My ideas are:
figure out a way to "force" take over a pipe.
figure out a way to close out all dead instances of my own app somehow?
negotiate a new pipe to use writing some random pipe name to a file that both apps can read in first? This seems overkill and still not ideal if I'm having the odd behavior when I can't create a pipe even if the name is different.
Since this is hard to recreate, I am simulating the problem by doing:
var pipeName = "myApp22";
NamedPipeServerStream server = new NamedPipeServerStream(pipeName, PipeDirection.InOut, 1);
// Here I would want to catch the exception and then force close, then repeat this:
NamedPipeServerStream server = new NamedPipeServerStream(pipeName, PipeDirection.InOut, 1);
Any input would be appreciated. Thanks.

IBM WebSphere XMS.Net CWSMQ0082E error

On several occasions I have received the following error from a .Net (C#, 4.0) application out of the blue on sending a message thru a producer:
CWSMQ0082E: Failed to send to CompCode: 2, Reason: 2009. A problem was encountered whilst sending a message. See the linked exception for more information.
Of course, the LinkedException (why not use the InnerException IBM???) is null i.e. no more information available.
Code I'm using (pretty straightforward):
var m = _session.CreateBytesMessage();
m.WriteBytes(mybytearray);
m.JMSReplyTo = myreplytoqueue;
m.SetIntProperty(XMSC.JMS_IBM_MSGTYPE, MQC.MQMT_DATAGRAM);
m.SetIntProperty(XMSC.JMS_IBM_REPORT_COA, MQC.MQRO_COD);
m.SetIntProperty(XMSC.JMS_IBM_REPORT_COD, MQC.MQRO_COA);
myproducer.Send(m, DeliveryMode.Persistent, mypriority, myttl);
(Offtopic: I hate the SetIntProperty way of setting properties. Which <expletive deleted> came up with that idea? It takes ages to look up all sorts of constants all over the place and its allowed values.)
The exception is thrown on the .Send method. I'm using XMS.Net (IA9H / 2.0.0.7). The only Google result that turns up turns out to have a different reason code (and even if it were the same, it should be fixed in my version if I understand correctly). This occurs randomly (though it seems to happen more often when it's been a while since a message has been sent/received) and I have no way to reproduce this.
I have ab-so-lute-ly no idea how to troubleshoot this or even where to start looking. Is this something caused by the server-side? Is it caused by XMS.net or some underlying IBM WebSphere MQ infrastructure?
Some results that I found that seem similar are suggesting to set SHARECNV to any value higher than 0 or to "true" / "yes" but the documentation explicitly tells me the default is 10. Also; I have no idea if this is the cause so changing it to another value feels like a shotgun approach.
Anybody any idea on how to go about solving this? I could of course just catch the exception, tear everything (channels, sessions, whatever) down and restart but that's just plain ugly IMHO.

The 2009 return code means "Connection Broken." Basically, the underlying TCP socket is gone and the client finds out about it at the time of the API call. It is possible to tune the channels using heartbeat and keepalive so that WMQ tries harde to keep the socket alive. However if the socket is timed out by the underlying infrastructure, nothing WMQ can do will help. Examples we've seen are that firewalls and load balancers are often set to detect idle connections and sever them.
Modern versions of WMQ client will attempt to reconnect transparently. The application just blocks a bit longer when this occurs.
Short of using the automatic reconnect, the only solution is in fact to rebuild the connection. Since it will get a new connection handle, all the object handles must be rebuilt as well.
Many of the tuning functions described here are available through the client configuration file, available in v7.0 and greater clients. In particular, the TCP stanza of that file enables keepalive. (The TCP spec says that if keepalive is provided, it must be disabled by default.) The QMgr has a similar ini file with configuration stanzas, including one for keepalive. The latest WMQ client is available as SupportPac MQC71 if you need that.

In cases where the main exception is sufficient enough to indicate the error, the inner exception will be null. In your case it's MQ reason code 2009 which means a connection to queue manager has been broken. The socket through which your application and queue manager were communicating was closed for some reason. The reason for socket close could be a network blip.
Along with suggestions T.Rob noted above, You could also run a XMS and Queue manager trace to understand the problem further. Please see the Troubleshooting chapter in XMS InfoCenter.
HTH

Cannot get Socket.Poll and Socket.Connected to work as desired

Okay I know there is lots of info out there on this and I promise you I have read it all and tried umpteen different methods to get this working!!
I have a socket server program which runs on a laptop. I then have up to 50 laptops connected wirelessly via the same LAN to the server. The client laptops all connect to the server (using Socket.ConnectAsync) and the server uses async methods as well to send and receive data. The server shows a list of connected client laptops to the user and this list seems to be accurate and picks up whenever a client disconnects and connects. However, the client laptops never seem to detect when connection to the server has been lost under certain circumstances (ie if server program crashes, if server laptop goes in to standby mode etc.) I have got a timer on the client laptops which polls the connection every 5 seconds as follows:
bool SocketConnected(Socket s)
{
bool part1 = s.Poll(0, SelectMode.SelectWrite);
bool part2 = (s.Available == 0);
if (!part1 && part2)
{
return false;
}
else
{
return true;
}
}
I have tried using all selectmodes (SelectWrite,SelectRead,SelectError) and have tried using different time out values. I have tried checking s.Connected value after these operations and have tried all manners of other methods to determine the connection state and nothing seems to produce reliable results!! I think I can achieve the result I desire by sending dummy information every 5 seconds and checking s.Connected after doing so, however I don't really want to do this as each laptop is already sending lots of data to the server as it is. Any help at all is massively appreciated! Thanks

The only reliable way to check if a connection is alive is to send something to the other end and see if it arrives. You can do this either manually by sending and receiving a "ping" value from time to time, or automatically by enabling the KeepAlive socket option.

The MSDN documentation for Socket.Poll is very explicit about the exact situations (server crashes, standby) you mentioned:
This method cannot detect certain kinds of connection problems, such
as a broken network cable, or that the remote host was shut down
ungracefully. You must attempt to send or receive data to detect these
kinds of errors.

When P2P Won't Connect, How to "Restart" it in the Client

I have implemented a wcf P2P setup in a simple application.
My question is the result of testing this with multiple clients. Nine times out of ten, all the clients will synch up in the mesh and connect without issue.
However, depending on which client I close and then re-open, it will not reconnect to the mesh. The other clients do not see it.
My question is how can I perhaps close and re-open the p2p on this client so it can attempt to connect again? I'd set a timer perhaps that every minute or so if it isn't connected, it might assume there is an issue so it would close it's p2p endpoint or whatever and then re-open it to refresh the whole thing.
I ask this since if I close this client, then re-open it, it will reconnect to the mesh.
I want fool-proof connections. Such as, you open a client and the client will figure out if it has to restart or it isn't getting connection after a certain amount of time so it attempts to "flush" the connection and rebuild it.
Does this make sense?

It's going to be difficult to determine that you're not connected to the mesh because of some unknown fault condition rather than simply being alone.
The IOnlineStatus property on the peer channel can tell you if you're alone in the mesh (false), or if you have connected peers (true). You can get this property by registering for the status change event like so:
IOnlineStatus status = myPeerChannel.GetProperty<IOnlineStatus>();
status.Online += new EventHandler(MyOnlineEventHandler);
status.Offline += new EventHandler(MyOfflineEventHandler);
So I suppose one way to do this would be to have a timer that checks your online status and if you go more than X amount of time being offline, dispose of your channel and create a new one.

client-server question

If i have a client that is connected to a server and if the server crashes, how can i determine, form my client, if the connection is off ? the idea is that if in my client's while i await to read a line from my server ( String a = sr.ReadLine(); ) and while the client is waiting to recieve that line , the server crashes , how do i close that thread that contains my while ?
Many have told me that in that while(alive) { .. } I should just change the alive value to true , but if my program is currently awaiting for a line to read, it won't get to exit the while because it will be trapped at sr.ReadLine() .
I was thinking that if i can't send a line to the server i should just close the client thread with .abort() . Any Ideas ?

Have a TimeOut parameter in ReadLine method which takes a TimeSpan value and times out after that interval if the response is not received..
public string ReadLine(TimeSpan timeout)
{
// ..your logic.
)
For an example check these SO posts -
Implementing a timeout on a function returning a value
Implement C# Generic Timeout

Is the server app your own, or something off the shelf?
If it's yours, send a "heart beat" every couple of seconds to let the clients know that the connection and service are still alive. (This is a bit more reliable than just seeing if the connection is closed since it may be possible for the connection to remain open while the server app is locked.)

That the server crashes has nothing to do with your clients. There are several external factors that can make the connection go down: The client is one of them, internet/lan problems is another one.
It doesn't matter why something fails, the server should handle it anyway. Servers going down will make your users scream ;)
Regarding multi threading, I suggest that you look at the BeginXXX/EndXXX asynchronous methods. They give you much more power and a more robust solution.

Try to avoid any strategy that relies on thread abort(). If you cannot avoid it, make sure you understand the idiom for that mechanism, which involves having a separate appdomain and catching ThreadAbortException

If the server crashes I imagine you will have more problems than just fixing a while loop. Your program may enter an unstable state for other reasons. State should not be overlooked. That being said, a nice "server timed out" message may suffice. You could take it a step further and ping, then give a slightly more advanced message "server appears to be down".