Dos únicos conductos con nombre en conflicto y InvalidCredentialException

Question

Hay dos problemas que me encontré anoche que he resuelto ahora, pero no estoy 100% seguro de por qué lo que he hecho los resolvió y esperaba que alguien pudiera ofrecer alguno visión ya que he estado dando vueltas a muchas rocas y ¡no he tenido suerte!

primer problema

La primera cuestión es que tenía dos tubos con un nombre único que se encontraban en dos programas separados:

• net.pipe: // localhost/superuniquepipe1
• red. pipe: // localhost/superuniquepipe2

Sin embargo, el segundo programa para lanzar arrojaría una excepción (I beli hasta que fue AddressAlreadyInUseException) al abrir el ServiceHost debido a que la dirección ya está en uso.

La forma en que fue crear instancias de estos ServiceHosts fue el siguiente:

Uri[] baseAddresses = new Uri[] { new Uri("net.pipe://localhost") }; 
this.host = new ServiceHost(this, baseAddresses); 
this.host.AddServiceEndpoint(typeof(IHostType), new NetNamedPipeBinding(), "superuniquepipe1"); 
this.host.Open(); 

Así que yo se especifica la dirección base del localhost en primer lugar, a continuación, especifique el resto de ella cuando se añade el punto final, el camino decidí que esto era para cambiar el código de la siguiente manera:

this.host = new ServiceHost(this); 
this.host.AddServiceEndpoint(typeof(IHostType), new NetNamedPipeBinding(), "net.pipe://localhost/superuniquepipe2"); 
this.host.Open(); 

Estoy en lo correcto al decir la razón de esto funcionó es porque estaba comprobando sólo las direcciones de base y no el punto final yo estaba tratando de agregar? ¿Y está utilizando la segunda muestra de código como una forma válida/segura de tener múltiples programas escuchando en "localhost"?

segundo problema:

En un intento de solucionar lo anterior, había cambiado la dirección de base de localhost a un número de diferentes cadenas únicas, por ejemplo, "Net.pipe: // rawrwhyisntthisworkingsadface", pero cuando se hace esto estaría presenté con un InvalidCredentialException desde el cliente intenta establecer una conexión (véase más abajo el código)

estaba bajo la impresión de una tubería con nombre puede ser, literalmente, nombrado algo, ¿alguien puede arrojar algo de luz sobre este?

ChannelFactory<IHostType> factory = new ChannelFactory<IHostType>(new NetNamedPipeBinding(), new EndpointAddress("net.pipe://rawrwhyisntthisworkingsadface/superuniquepipe2")); 
IHostType proxy = factory.CreateChannel(); 
proxy.CallSomeMethodAndGetAnException(); 

Cualquier entrada sería muy apreciada, como ya he dicho que he resuelto el problema y sólo quieren saber por qué mi solución funcionó, pero si usted ve un defecto en la forma en que he resuelto y puede sugerir una mejor forma de hacerlo por favor hágalo :)

Answer 1

Re problema 1:

el WCF NetNamedPipeBinding utiliza una sección de memoria compartida llamada a publicar a sus clientes el nombre real de la tubería sobre la que el servicio puede ser llamado. El nombre de la tubería en sí es un GUID, generado de nuevo cada vez que se abre el host del servicio. Es el nombre de la sección de memoria compartida utilizada para publicar el servicio que depende de la URL del servicio. Si se define una dirección base, la dirección base se usa para derivar este nombre.

Esto significa que solo puede tener una aplicación de servicio WCF en el momento en que se ejecuta, que utiliza una dirección base particular para sus puntos finales NetNamedPipe.Si intenta iniciar una segunda, falla con AddressAlreadyInUseException porque descubre que el nombre que WCF desea usar para la ubicación de publicación (derivado de la dirección base) ya ha sido tomado por otra aplicación.

Si no especifica una dirección base y otorga a cada servicio una URL de servicio única y absoluta, el nombre de la ubicación de publicación ahora se deriva de la URL absoluta completa y no hay conflicto de nombres entre las aplicaciones. Esta es una forma completamente válida y segura de escuchar varios servicios de tuberías con nombre de WCF.

problema Re 2:

Por el lado de servicio que se puede utilizar cualquier cosa para la parte de nombre de host de la dirección URL del servicio. Esto se debe a la configuración HostNameComparisonMode aplicada por defecto en NetNamePipeBinding, ya que el algoritmo en WCF que deriva el nombre para la ubicación de publicación de memoria compartida sustituye un carácter comodín para el nombre de host see here para permitir la implementación del modo de comparación de nombre de host configurado.

En el lado del cliente, sin embargo, la URL del servicio está restringida: la parte del host debe resolverse genuinamente a localhost (es decir, es localhost, la dirección IP correcta o el nombre correcto de la máquina).