WCF Named Pipes AddressAlreadyInUseException - c#

I am using named pipes to communicate between multiple different apps. I have two named pipe hosts which I am trying to get to listen on different addresses.
If I start either app on its own it will run. When i run the second app it will throw and exception telling me that the address is already in use.
System.ServiceModel.AddressAlreadyInUseException: 'Cannot listen on pipe name
'net.pipe://dfb679124c82453888842928c37c6dae/' because another pipe endpoint is
already listening on that name.'
The two services are not using the same address.
I have even setup one of the services with the following code:
Host = new ServiceHost(
this,
new Uri[]
{
new Uri("net.pipe://"+Guid.NewGuid().ToString("N"))
});
var binding = new NetNamedPipeBinding();
Host.AddServiceEndpoint(typeof(IService),
binding, Guid.NewGuid().ToString());
In this code I am generating a random address when the service is created and it still throws the AddressAlreadyInUseException.
I am not using any config configuration to setup the named pipes, everything is code based.
What am I doing wrong?

Related

Azure service bus paired namespace - simulate failover

I am working with azure service bus paired namespace and need to be able to simulate a failover to the secondary namespace. I did kind of have this working by entering an incorrect connection string for the primary namespace and saw it fail over and send the message to the secondary namespace. This no longer seems to do the trick. I can not find a way through the azure management portal or anywhere else to take a namespace offline. Anyone any ideas how to do this?
Here is my code for reference
var pairedNamespaceConfiguration = this.pairedNamespaceConfigurationDictionary[configurationKey];
MessagingFactory factory = MessagingFactory.CreateFromConnectionString(pairedNamespaceConfiguration.PrimaryNamespace.ConnectionString);
MessagingFactory secondaryMessagingFactory = MessagingFactory.CreateFromConnectionString(pairedNamespaceConfiguration.SecondaryNamespace.ConnectionString);
NamespaceManager secondaryNamespaceManager = NamespaceManager.CreateFromConnectionString(pairedNamespaceConfiguration.SecondaryNamespace.ConnectionString);
SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions = new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondaryMessagingFactory, pairedNamespaceConfiguration.BacklogQueueCount, TimeSpan.FromSeconds(pairedNamespaceConfiguration.FailoverIntervalSeconds), false);
factory.PairNamespaceAsync(sendAvailabilityOptions).Wait();
MessageSender messageSender = factory.CreateMessageSender(pairedNamespaceConfiguration.PathName);
string messageContent = JsonConvert.SerializeObject(message);
using(BrokeredMessage brokeredMessage = new BrokeredMessage(messageContent))
{
messageSender.Send(brokeredMessage);
}
Modify your \Windows\system32\drivers\etc\hosts file to point the original namespace to something like 127.0.0.1. This will make the original namespace connection fail.
I'm using this example Geo-replication with Service Bus Relayed Messages to implement the same think. Maybe it's useful for you also.
All Service Bus entities reside in a namespace. A namespace is affiliated to a datacenter. To allow for a failover between datacenters, the user must create one Service Bus and ACS namespace (in case ACS is used) per datacenter. Any Service Bus relay that needs to remain accessible in the presence of datacenter failures must be created in both namespaces.
The server opens two NetTcp relay endpoints, one in each of the two namespaces. The server processes any request that is received via one of these endpoints. Note that the two relays have to have different names (.e.g, address of primary relay is sb://myPrimaryNamespace.servicebus.windows.net/myService-primary and b://mySecondaryNamespace.servicebus.windows.net/myService-secondary).
The client considers one of the two replicated relays as the active relay and the other one as a backup. It opens a channel to the active relay and invokes methods on the service. If the invocation fails with any exception that is not part of the service contract, the client abandons the channel, opens a channel to the backup relay, and invokes the service method again. The client will consider the new channel to be the active channel and continues to use that channel until the next fault occurs.

Limit WCF service calls to local clients

I am trying to open WCF Service for local use only.
I cant seem to find a way to make it listen on localhost only (not allow remote connections to my WCF host)
Here is an example code :
var baseUri = new Uri("http://127.0.0.1:9001");
var webHost = new WebServiceHost(typeof(MyService), baseUri);
webHost.AddServiceEndpoint(typeof(MyService), new WebHttpBinding(), string.Empty);
webHost.Open();
Console.WriteLine("press any key to exit");
Console.ReadLine();
looking on the resource Monitor shows that it listen to "unspecified ip".
How can i force it to listen on localhost only ?
You can set HostNameComparisonMode on your WebHttpBinding to Exact, this includes the host name in endpoint matching.
The HostnameComparisonMode value that indicates whether the hostname is used to reach the service when matching on the URI. The default value is StrongWildcard, which ignores the hostname in the match.
But using Named Pipes is better in this case. For more info see msdn.

How to use NetTcpBinding in code?

Not a duplicate! - The suggested duplicate deals with one using netTcpBinding and one using mexTcpBinding. Read on to see that that is not the case here:
Here's my code:
ServiceHost host = new ServiceHost(class1Type, new Uri(uri));
host.AddServiceEndpoint(interface1Type, new NetTcpBinding(SecurityMode.None), uri);
host.Open();
I have made a copy of the project and am running two instances with one difference - the last character in the uri string. There is nothing in the configuration file. All is in code.
The uri is of the form:
net.tcp://localhost/abc/def
I'm getting an error:
There is already a listener on IP endpoint 0.0.0.0:808. This could
happen if there is another application already listening on this
endpoint or if you have multiple service endpoints in your service
host with the same IP endpoint but with incompatible binding
configurations.
I don’t understand this error, both services are the same, so how can they be incompatible?
All I was missing was:
PortSharingEnabled = true
(I don't think the error message is clear enough.)

WCF error "no endpoint listening" with named pipes

I'm using WCF with .NET 3.5 I am using named pipes but keep getting the error
There was no endpoint listening at
net.pipe://localhost/Test that could
accept the message. This is often
caused by an incorrect address or SOAP
action.
I followed the tutorial http://www.switchonthecode.com/tutorials/wcf-tutorial-basic-interprocess-communication but the problem remains. The endpoints on both the client and server are the same (I checked spelling etc). There is no config file for this project but the config is in the code.
EDIT: Code (client):
ChannelFactory<ITest> pipeFactory =
new ChannelFactory<ITest>(
new NetNamedPipeBinding(),
new EndpointAddress(
"net.pipe://localhost/test"));
ITest test= pipeFactory.CreateChannel();
test.doStuff();
SERVER:
serviceHost = new ServiceHost(typeof(Test), new Uri("net.pipe://localhost"));
serviceHost.AddServiceEndpoint(typeof(ITest), new NetNamedPipeBinding(), "test");
File.Create(#"C:\test.txt");
serviceHost.Open();
Thanks
On the server side don't include base addresses when you create the ServiceHost instance. Instead, provide the fully qualified endpoint address when you add the service endpoint:
serviceHost = new ServiceHost(typeof(Test));
serviceHost.AddServiceEndpoint(typeof(ITest), new NetNamedPipeBinding(), new EndpointAddress("net.pipe://localhost/test"));
File.Create(#"C:\\test.txt");
serviceHost.Open();
This could be:
You are running it as a windows service and the service is not running
You are running it as a console app and there is no console.readline, so it just exists
You are running client and server on two different machines so that localhost is not going to the machine with the service.
Another possibility to fix this root issue if you are getting an error that no net.pipe address can be found at your url (i.e. http://localhost:1234/MyService/etc/) is to make sure that the Net.Pipe Listener Adapter Windows Service is started. (I also started Net.Tcp Listener Adapter)
The service does not seem to be enabled or started in some scenarios especially when deploying out to a remote server that might not of had a lot of the development tools installed that actively use these services. Starting the service fixed the issue.

C# 3.5 - Connecting named pipe across network

What is the correct way to setup a named pipe in C# across a network?
Currently I have two machines, 'client' and 'server'.
Server sets up its pipe in the following manner:
NamedPipeServerStream pipeServer = new NamedPipeServerStream(
"pipe",
PipeDirection.InOut,
10,
PipeTransmissionMode.Byte,
PipeOptions.None)
pipeServer.WaitForConnection();
//... Read some data from the pipe
The client sets up its connection in the following manner:
NamedPipeClientStream pipeClient = new NamedPipeClientStream(
"server",
"pipe",
PipeDirection.InOut);
pipeClient.Connect(); //This line throws an exception
//... Write some data to the pipe
The 'server' machine can be accessed on the network by going to "\\server".
Whenever I run the program, I get a System.UnauthorizedAccessException that says "Access to the path is denied." The code works fine when I run the server and client on my local machine and attempt to connect to "." with the client.
You need to set permissions on the NamedPipeServerStream so that the client will have permissions to access the pipe.
I would look at the SetAccessControl method of your NamedPipeServerStream.
Look in the System.Runtime.Remoting namespace. IIRC, named pipes are one option for the protocol used by remoting channels.
It is not possible to used named pipes between machines.
"The WCF-NetNamedPipe adapter provides cross-process communication on the same computer"
http://msdn.microsoft.com/en-us/library/bb226493.aspx

Categories