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

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

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

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

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

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

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

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