Вы можете спроектировать свой сервис так, чтобы он порождал «рабочие потоки», которые выполняют тяжелую работу, а он просто прислушивается к дополнительным запросам. Поскольку будущие вызовы, вероятно, будут иметь дело с текущим работником, это может работать лучше, чем, скажем, проектирование его как веб-службы с использованием IIS.
Я бы настроил это так: основной поток службы прослушивает порт или канал для связи. Когда он получает вызов для обработки данных, он порождает рабочий поток, давая ему некоторый «токен состояния» (может быть таким же простым, как ссылка на логическую переменную), который он будет проверять через регулярные промежутки времени, чтобы убедиться, что он все еще работает , Поток запускается, сервис возвращается к прослушиванию (сетевые классы поддерживают буфер принятых данных, поэтому вызовы будут прерываться только в том случае, если они «истекут»).
Если служба получает вызов для прерывания, она устанавливает для токена значение «отмена». Рабочий поток прочитает это значение при следующем опросе, получит сообщение, откатит транзакцию и умрет.
Это можно настроить так, чтобы несколько работников одновременно обрабатывали несколько файлов, принадлежащих вызывающим абонентам, которым назначен их IP-адрес или какой-то уникальный идентификатор "сеанса", который вы передаете взад и вперед.