WCF, BasicHttpBinding: Остановите новые соединения, но позвольте существующим соединениям продолжаться

Предположение:

Вы пытались захватить привязку во время выполнения (из конечных точек), преобразовать ее в BasicHttpBinding и (пере) определить свойства там?

Лучшие предположения от меня :

• OpenTimeout
• MaxReceivedMessageSize
• ReaderQuotas

Они могут быть установлены во время выполнения в соответствии с документацией и, кажется, допускают желаемое поведение (блокирование новых клиентов). Это не помогло бы с частью "восходящий брандмауэр / балансировщик нагрузки должен перенаправить".

Последнее предположение: можете ли вы (в документе сказано да, но я не уверен, каковы будут последствия) переопределить адрес конечные точки на адрес localhost по запросу? Это может работать как «закрытие порта» для хоста брандмауэра, если оно все равно не убивает всех клиентов ..

Редактировать: Играя с предложениями выше и ограниченным тестом, я начал играть с инспектором сообщений Комбинация / behavior, которая пока выглядит многообещающей:

public class WCFFilter : IServiceBehavior, IDispatchMessageInspector {
    private readonly object blockLock = new object();
    private bool blockCalls = false;

    public bool BlockRequests {
        get {
            lock (blockLock) {
                return blockCalls;
            }
        }
        set {
            lock (blockLock) {
                blockCalls = !blockCalls;
            }   
        }

    }

    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) {          
    }

    public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters) {         
    }

    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) {
        foreach (ChannelDispatcher channelDispatcher in serviceHostBase.ChannelDispatchers) {
            foreach (EndpointDispatcher endpointDispatcher in channelDispatcher.Endpoints) {
                endpointDispatcher.DispatchRuntime.MessageInspectors.Add(this);
            }
        } 
    }

    public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) {
        lock (blockLock) {
            if (blockCalls)
                request.Close();
        }
        return null;
    }

    public void BeforeSendReply(ref Message reply, object correlationState) {           
    }
}

Забудьте об использовании дрянных блокировок и т. д., но используйте это с очень простым тестом WCF (возвращающим случайное число с Thread.Sleep внутри), например:

var sh = new ServiceHost(new WCFTestService(), baseAdresses);

var filter = new WCFFilter();
sh.Description.Behaviors.Add(filter);

и более поздние версии перевернув свойство BlockRequests, я получаю следующее поведение (опять же: это, конечно, очень, очень упрощенный пример, но я надеюсь, что он все равно может сработать для вас):

// Я создаю 3 потока Запрос номера…
Запрос номера…
Запрос номера ..
// Журнал на стороне сервера для одного входящего запроса
Входящий запрос на номер.
// Основной цикл переворачивает "все блокировать" bool
Блокировка доступа с этого момента.
// Для удобства после этого еще 3 клиента
Запрос номера…
Запрос номера…
Запрос номера…
// Первый запрос (с журналом на стороне сервера, см. Выше) завершается успешно
Поступило 1569129641
// Все остальные сообщения еще не дошли до сервера и умирают с ошибкой
Ошибка в запросе клиента, возникшем после блока.
Ошибка в клиентском запросе, порожденном после блока.
Ошибка в клиентском запросе, возникшем после блока.
Ошибка клиентского запроса перед блокировкой.
Ошибка в запросе клиента перед блоком.