WCF Descubrimiento vuelve rígida URL

Question

El gran proyecto es la siguiente:

1. Hay cierta aplicación que se instala como un servicio de Windows
2. Puede haber varios de estos en la red
3. Cada de ellos expone alguna interfaz a la red (piénselo como "control remoto" o "configuración" - ese tipo de cosas)
4. Luego hay otra aplicación que actúa como cliente para esa interfaz (usando las mismas analogías - "remote controlador "o" herramienta de configuración ")
5. El objetivo de este último es detectar todas las instancias de las primeras en la red, mostrarlas como una lista para el usuario y permitir que el usuario las introduzca en diferentes lugares utilizando esa interfaz expuesta (es decir, "control remoto" o "configurarlos")
6. En aras de la simplicidad, supongamos que todos están en la misma red, es decir, todos pueden escuchar las transmisiones UDP de los demás.

Bastante sencillo, ¿eh? Solía ​​construir este tipo de cosas por docenas en los viejos tiempos, usando un mecanismo de descubrimiento basado en transmisión UDP roll-my-own.

Pero ahora pensé que sería genial y moderno, y voy con el maravilloso WCF Discovery en modo Ad hoc. ¡Y funciona! ¿Quién podría decir? :-)

Pero no del todo. Como mencioné anteriormente here y there, el descubrimiento devuelve la URL codificada de la configuración del servicio. Es decir, si el servicio tiene <baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses> en su archivo de configuración, eso es exactamente lo que obtendré del cliente de descubrimiento, incluida la parte "localhost".

No hace falta decir que, si trato de llamar al servicio utilizando esa URL, el resultado no es emocionante.

Entonces la pregunta es: ¿cómo hago que el cliente de descubrimiento me proporcione la URL utilizable en lugar de esa basura localhost-ish?

Para guardar el tiempo de todos, un par de pensamientos que no funcionan:

1. Cambiar archivo de configuración del servicio en tiempo de despliegue, la codificación es verdadera dirección IP o el nombre de la máquina.
   No funciona, porque tanto la IP como el nombre de la máquina pueden cambiar.
2. Configure el servicio desde el código (al menos parcialmente), usando la IP actual o el nombre de la máquina para construir la URL.
   No funciona. El nombre de la máquina es inútil, porque es posible que no haya un DNS en la red. La IP es inútil, porque la computadora puede estar en varias redes a la vez, y por lo tanto, tiene varias direcciones IP (esto no es hipotético, de hecho tenemos tenemos esta situación). ¿Cuál usar entonces?

En otras palabras, no necesito modificar el servicio, sino hacer que el cliente de descubrimiento me proporcione la dirección de donde provino la respuesta de descubrimiento.

Answer 1

usted debería ser capaz de solucionar este problema mediante la sustitución de localhost con un comodín:

<baseAddresses><add baseAddress="net.tcp://*:1234/My/Service" /></baseAddresses> 

Answer 2

No utilice la configuración.

Ejecute el servicio de forma programática.

He aquí un ejemplo de cómo agregar puntos finales programtically: Programmatic_Endpoint_Configuration

Y esto, para la comparación: Self-hosting_and_base_addresses

Answer 3

Otro Otra opción que no sea comodín es usar el nombre de host resoluble por DNS de la máquina en el sitio localhost.