Наконец-то разобрались, надеюсь, это сэкономит время другим.
Я думаю, что критическим изменением была активация.
но я упомянул другие настройки, которые я изменил на всякий случай
В IIS, используя теги местоположения в файле web.config, я установил время выполнения для заданного значения ashx равным 2 часам (спасибо Джону Ханне и Томасу Варачеку за указание на это) Не уверен, что это абсолютно необходимо, но если у вас есть процесс, который занимает до 2 часов, тогда кажется, что время выполнения должно быть не менее 2 часов.
Ожидаемое продолжение в IIS отключено.
На стороне клиента значение по умолчанию для точки обслуживания wait100continue равно true.
Я установил это в ложь;
Я установил максимальное время обслуживания: 2 часа.
Не уверен, считается ли соединение, ожидающее ответа, свободным или нет.
Я думаю, что это относится к точке обслуживания, которая не связана с соединением, поэтому, вероятно, не относится к моей проблеме
Я всегда использую версии шаблона начала / конца (асинхронные), если они доступны
особенно начинай и читай. Это необходимо для того, чтобы избежать необходимости расшифровывать много тайм-аутов по запросу / потоку
Значением по умолчанию для точки обслуживания.
Я установил service_point SetTcpKeepAlive (true, 1000 * 60, 1000);
Я думаю, это означает, что после 1 минуты бездействия (в ожидании ответа) клиент посылает «пробу» проверки активности, чтобы напомнить серверу, что он все еще ждет. Если он не получает ответ на зонд, он отправляет другой через секунду. Надеюсь, после того, как он получит ответ на проверку активности, он вернется к 1 минуте ожидания, но я не уверен. Обратите внимание, что существует не более 10 зондов, которые нельзя изменить.
Обратите внимание, что, конечно, интервал тайм-аута должен быть меньше, чем connectionTimout, настроенный для сайта в расширенных настройках соединения сайта IIS, иначе время ожидания соединения будет превышено, прежде чем будет отправлен первый пакет подтверждения активности.
Другим способом решения этой проблемы было согласие с тем, что система препятствует открытию соединений, которые просто ожидают, поэтому перед тем, как запустить длительный процесс, я запускаю задачу, которая выполняет ответ. Писать так часто (1 минута).
Я сбрасываю запись, и буферизация в ответе отключена, и для сайта отключена привязка, и хотя сообщение маленькое (1 байт), оно все равно возвращается обратно к клиенту за 3000 миль)
В этом сценарии:
IIS не считает соединение бездействующим, httpwebrequest не считает соединение бездействующим, и запрос продолжает ждать так, как я этого хочу.
У меня эта схема работала несколько часов без проблем
Конечно, еще одним способом было бы заставить сервер запустить процесс и немедленно вернуться, а также периодически проверять запросы сервера, чтобы убедиться, что он завершен. Кто-то скажет, что это больше по традиции методологии http запрос / ответ. Я могу все еще сделать это, но я хотел бы использовать эту опцию в качестве запасного при необходимости