Двухсторонняя связь с WCF - стоит ли использовать обратные вызовы или просто использовать два канала?

Question

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

В настоящее время мы используем WCF с каналами NamedPipe или Tcp и регистрируем ProcessA в ProcessB. В нашем контракте WCF указан интерфейс обратного вызова, поэтому ProcessB может затем вызывать методы для ProcessA.

Мой вопрос: что из следующего имеет смысл, является более простым и более надежным?

1. Пусть ProcessB использует интерфейс обратного вызова (поддерживаемый WCF) для вызова методов в ProcessA.
2. При регистрации ProcessA передает ProcessB необходимую информацию для ProcessB, чтобы зарегистрироваться в ProcessA, используя новый канал?

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

Answer 1

Ваш вариант 2 - это просто описание того, что WCF делает для вас в варианте 1.

Когда ваш клиент открывает соединение, он регистрирует канал обратного вызова в службе. Этот канал остается открытым до тех пор, пока вы его не закроете - либо явно вызвав Close, либо удалив его.

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

Answer 2

Вариант 2 описывает, что делает вариант 1, но он реализует свои способы, которые вы не могли сделать сами. Например, если вы используете каналы TCP, он будет использовать сокет, который клиент открывает на сервере для отправки данных обратно.

Это означает, что он будет работать за брандмауэром и NAT.

Checkout

http://diagonaltechblog.blogspot.com/2009/12/wcf-duplex-channels-firewalls-and-nats.html

Не очень подробно рассказывается о том, как создать дуплексный канал, но, похоже, вам это удалось.

Приветствия