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

Question

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

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

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

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

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

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

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

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

Answer 1

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

Слишком много недостатков:

1) Использование сеанса для установления клиентского слушателя сервером,Это информация о сеансе хранится в памяти.Следовательно, сам сервер не может быть сбалансирован по нагрузке.Или, если бы он был сбалансирован по нагрузке, вам нужно включить ip affinity, но теперь, если один из серверов засыпан, вы не можете просто добавить другой и ожидать, что все эти сеансы автоматически перенесутся на новый сервер.

2) Для каждого клиента, сидящего за маршрутизатором / брандмауэром / распределителем нагрузки, необходимо создать новую конечную точку с определенным портом.В противном случае маршрутизатор не сможет правильно направить сообщения обратного вызова соответствующему клиенту.Альтернативой является наличие маршрутизатора, который позволяет пользовательскому программированию перенаправлять определенный путь к определенному серверу.Опять высокий заказ.Или другой способ - для клиента с обратным вызовом разместить свою собственную базу данных и обмениваться данными через базу данных <- Может работать в некоторых ситуациях, когда лицензионные сборы не являются проблемой ... но это создает много сложностей и так обременительно дляклиент плюс он смешивает прикладной и сервисный уровни вместе (что может быть приемлемо в некоторой исключительной ситуации, но не сверх огромных затрат на установку) </p>

3) Все это в основном говорит о том, что дуплекс практически бесполезен.Если вам нужно перезвонить, то вы хорошо настроите хост wcf на стороне клиента.Это будет проще и гораздо более масштабируемым.Кроме того, существует меньшая связь между клиентом и сервером.

Лучшее дуплексное решение для масштабируемой архитектуры, в конце концов, не использует его.

Answer 2

1. Это будет зависеть от того, насколько коротким вам нужны новые клиенты и как долго они будут работать. Объединение в пул не будет вариантом, если вам каждый раз требуется новый клиент, но если клиенты продолжают делать то же самое, почему бы не иметь пул, ожидающий использования, если они отказывают, воссоздайте тот же клиент снова.

2. В действительности в сценарии обратного вызова, если служба перезванивает клиенту (действительно вызывает функцию на клиенте) для передачи информации, служба теперь является клиентом, и наоборот. У вас может быть служба, которая выполняет обратный вызов .Close () соединение, но оно будет открыто до тех пор, пока GC не сможет избавиться от него, по моему опыту, это может занять больше времени, чем ожидалось. Таким образом, короче говоря, клиент должен нести ответственность (клиент, который делает вызов чему-либо) за отключение или отключение, служба должна только возвращать ответы или принимать данные от клиента.

3. В дуплексных обратных вызовах служба, теперь перезванивающая клиенту, получит адрес клиента, абстрагированный от фабрики дуплексного канала. Если служба не может перезвонить клиенту, я не думаю, что многое можно сделать, вы должны убедиться, что порт, к которому ваши клиенты обращаются к службе, открыт для приема обратных вызовов, я бы предположил.