Зачем вам нужно поддерживать открытое соединение в течение недель / месяцев?Это приведет к большой сложности, обработке тайм-аутов, обработке ошибок, воссозданию соединения и т. Д. Я даже сомневаюсь, что это будет работать.
Соединения Net.tcp используют транспортный сеанс, что приводит к PerSession созданию экземпляра службы WCF - один экземпляр службы обслуживает все запросы и живет в течение всей продолжительности сеанса (в вашем случае недели или месяцы) = экземпляри все его содержание все еще в памяти.Любое прерывание или необработанное исключение сломает канал и закроет сеанс = все локальные данные сеанса потеряны, и клиент должен создать новый прокси-сервер, чтобы начать новый сеанс снова.Также любой тайм-аут (по умолчанию 20 минут бездействия) закроет сеанс.Для последнего - в зависимости от сложности бизнес-логики вы можете обнаружить, что если даже несколько сотен клиентов нуждаются в обработке в одно и то же время, один сервер не может обслуживать их всех, и некоторые клиенты отключаются (снова прерывает сеанс).Разрешение балансировки нагрузки с помощью net.tcp требует алгоритма балансировки нагрузки с липкими сессиями (сходство сессий), и вся архитектура становится еще более сложной и хрупкой.Масштабируемость в net.tcp означает, что служба может быть развернута на нескольких серверах, но весь сеанс клиента должен обрабатываться одним сервером (если сервер умирает, все сеансы, обслуживаемые сервером, также умирают).
Хостинг в IIS / WAS / AppFabric имеет несколько преимуществ, два из которых - мониторинг работоспособности и переработка процессов.Мониторинг работоспособности постоянно проверяет, что рабочий процесс все еще активен и может обрабатывать запрос - если он этого не делает, он молча запускает новый рабочий процесс и направляет новые входящие запросы этому процессу.Регулярное повторное использование процессов (настройка по умолчанию - через 29 часов) домен приложения, что делает процесс работоспособным и уменьшает утечки памяти.Побочным эффектом является то, что воссоздание процесса или домена приложения уничтожит все сеансы.После того, как вы самостоятельно принимаете услугу, вы теряете их все, поэтому вам самим приходится иметь дело со здоровьем службы.
Редактировать:
ИМХО информация о состоянии здоровья недолжны быть отправлены через TCP.Это информация, которая не требует все модные вещи.Если вы потеряете некоторую информацию, это ни на что не повлияет = вы можете использовать UDP для передачи состояния здоровья.
При использовании TCP вам не нужно поддерживать прокси / сеанс открытым только для того, чтобы поддерживать открытое соединение.TCP соединение не закрывается сразу при закрытии прокси.Он остается открытым в пуле в течение короткого промежутка времени, и если любому другому прокси-серверу требуется подключение к тому же серверу, он используется повторно (время простоя по умолчанию в пуле должно составлять 2 минуты) - Я обсуждал транспорт Net.Tcp в WCF вдругой ответ .
Я не фанат обратных вызовов - вся эта концепция в WCF злоупотребляется и злоупотребляется.Сохранение 10.000 TCP-соединения открытым в течение нескольких месяцев на случай, если иногда будет возможность отправлять данные на несколько ПК, звучит нелепо.Если вам нужно связаться с ПК, выставьте сервис на ПК и позвоните, когда вам нужно будет отправить несколько команд.Просто добавьте функциональность, которая будет вызывать сервер, когда компьютер запускается и когда компьютер собирается завершить работу, + добавлять передаваемую информацию мониторинга.
В любом случае 10.000 компьютеров, отправляющих информацию каждую минуту - это может привести к тому, что вы получите 10.000 запросов одновременно - это может иметь тот же эффект, что и атака типа «отказ в обслуживании».В зависимости от времени обработки ваш сервер (-ы) может быть не в состоянии обработать их, и для многих запросов произойдет тайм-аут.Вы также можете подумать о протоколах очередей сообщений или публикации-подписки.Сообщения будут передаваться в очередь или тему, и серверы будут обрабатывать их непрерывно.