Лучшая практика для дуплексного клиента WCF

Я не могу отрицать преимущества дуплексного асинхронного вызова в производительности, но некоторые вещи заставляют меня насторожиться.

Меня беспокоит, что при создании экземпляра клиентского объекта сможет ли WCF определить, какой конкретный экземпляр клиентской службы получит аргумент обратного вызова?

Может ли кто-нибудь сказать мне, хорошая ли это идея? Если нет, то почему?

new DuplexChannelFactory<IServerWithCallback>(
   new ClientService(), 
   new NetTcpBinding(), 
   new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid()))

1. Если указанный выше виртуальный путь зарезервирован, как его можно отбросить. Я хочу, чтобы срок службы клиентского сервиса был достаточно коротким. IE делает запрос и получает ответ, а когда его завершают, убивает его. Насколько велико снижение производительности при сокращении срока службы клиентского сервиса по сравнению с его объединением и продлением срока службы.

   Идея состоит в том, чтобы избежать проблемы с тайм-аутом. Когда вы закончите получение, отправку, утилизируйте как можно скорее.По условию - нельзя обходить стороной клиентские сервисы. Если вам нужна информация, создайте новую, просто - точно так же, как EF / L2S и т. Д.

2. Как мне завершить сеанс с клиентом изнутри самой службы WCF. т.е. Я не хочу, чтобы клиент завершал сеанс - я знаю, что могу соответствующим образом украсить свою операцию, но я хочу, чтобы служба завершала себя программно при выполнении определенных условий.

3. Я могу прикрепить порт и переадресовать соответствующим образом, чтобы решить любую проблему с брандмауэром, но меня беспокоит то, что клиент будет сидеть за балансировщиком нагрузки. Как служба узнает, на какой именно сервер следует позвонить?