WCF, Дуплексный обратный вызов, recieveTimeout netTcpBinding

Question

WCF, Дуплексный обратный вызов, recieveTimeout netTcpBinding

У меня есть Хост / Клиент Сервис WCF и клиент, который использует netTcpBinding и метод обратного вызова.

<bindings>
      <netTcpBinding>
        <binding name="tcp_Unsecured" receiveTimeout="00:01:00" sendTimeout="00:01:00">
          <security mode="None" />
          <reliableSession enabled="true" ordered="true" inactivityTimeout="00:10:00"/>
        </binding>
      </netTcpBinding>
</bindings>

Прокси

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://dotnetaddict.dotnetdevelopersjournal.com/wcf.samples", ConfigurationName="AlarmServer", CallbackContract=typeof(AlarmServerCallback), SessionMode=System.ServiceModel.SessionMode.Required)]
public interface AlarmServer
{

    [System.ServiceModel.OperationContractAttribute(IsOneWay=true, Action="http://dotnetaddict.dotnetdevelopersjournal.com/wcf.samples/AlarmServer/RegisterAlarm")]
    void RegisterAlarm(System.DateTime alarmTime, string clientName, string reminderMessage);

    [System.ServiceModel.OperationContractAttribute(IsOneWay = true, Action = "http://dotnetaddict.dotnetdevelopersjournal.com/wcf.samples/AlarmServer/unRegisterAlarm")]
    void unRegisterAlarm(string clientName);

    [System.ServiceModel.OperationContractAttribute(IsOneWay = true, Action = "http://dotnetaddict.dotnetdevelopersjournal.com/wcf.samples/AlarmServer/broadcastMessage")]
    void broadcastMessage(string msg);
}

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
public interface AlarmServerCallback
{

    [System.ServiceModel.OperationContractAttribute(IsOneWay=true, Action="http://dotnetaddict.dotnetdevelopersjournal.com/wcf.samples/AlarmServer/SignalAlarm")]
    void SignalAlarm(string reminderMessage);

    [System.ServiceModel.OperationContractAttribute(IsOneWay = true, Action = "http://dotnetaddict.dotnetdevelopersjournal.com/wcf.samples/AlarmServer/displayMessage")]
    void displayMessage(string msg);
}

клиентский экземпляр с обратным вызовом

public MainForm()
{
    InitializeComponent();
    InstanceContext context = new InstanceContext(new AlarmCallback());
    client = new AlarmServerClient(context);
}

Проблема, которую я имею, состоит в том, что после привязки recieveTimeout триггеры, клиент входит в неработающее состояние и закрывает клиенты, слушающие обратный вызов.

Я вижу, что отбрасывание порта прослушивания использует TCPVIEW от sysinternals.

Если я заставляю канал напряженно трудиться, время не инициировало, таким образом, не отказ в сообщении WCF к Серверу/Клиенту, поскольку несколько сообщений будут течь через хорошо.

Я думал, что receiveTimeout был разработан, чтобы позволить обнаруживать, если ответ от WCF обменивается сообщениями по отказавшему TCP? Почему это дает сбой соединение. Почти кажется, что, если нет никакого объекта обратного вызова, созданного в течение периода тайм-аута, канал затем закрывается?

Что я делаю неправильно?

5

wcf nettcpbinding

задан Dan J 23 November 2010 в 00:23

2 ответа

Другие вопросы по тегам:

wcf nettcpbinding

Похожие вопросы:

score 3 · Answer 1

Пробовали ли вы использовать DuplexChannelFactory, при создании прокси (клиент)? Вот как это используется (замените создание с помощью new AlarmServerClient(context)):

AlarmServer proxy = new DuplexChannelFactory<AlarmServer>(context,"YourAlarmServerEndpoint").CreateChannel();

EDIT: Включение лога для анализа трассы:

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

<system.diagnostics>
<sources>
  <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
    <listeners>
      <add type="System.Diagnostics.DefaultTraceListener" name="Default">
        <filter type="" />
      </add>
      <add name="ServiceModelMessageLoggingListener">
        <filter type="" />
      </add>
    </listeners>
  </source>
  <source name="System.ServiceModel" switchValue="Information,ActivityTracing"
    propagateActivity="true">
    <listeners>
      <add type="System.Diagnostics.DefaultTraceListener" name="Default">
        <filter type="" />
      </add>
      <add name="ServiceModelTraceListener">
        <filter type="" />
      </add>
    </listeners>
  </source>
</sources>
<sharedListeners>
  <add initializeData="Your_svclog_file_here"
    type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
    <filter type="" />
  </add>
  <add initializeData="Your_svclog_file_here"
    type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
    <filter type="" />
  </add>
</sharedListeners>
<trace autoflush="true" />

В этом случае трасса способна записывать "информацию". Важно видеть создание каналов.

Для анализа файла svclog, вы можете использовать Service Trace Viewer - Microsoft Windows SDK, обычно в C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcTraceViewer.exe

score 6 · Answer 2

Похоже, время приема приводит к сбою службы узла обратного вызова после того, как она достигает максимального количества . Это 23,59 часа или 1 минута по умолчанию. Я могу решить проблему тайм-аута, установив для приема тайм-аут значение Infinate

 <bindings>
      <netTcpBinding>
        <binding name="NetTcpBinding_AlarmServer" receiveTimeout="infinite" >
          <security mode="None" />        
        </binding>
      </netTcpBinding>
    </bindings>

. Но теперь я задаюсь вопросом, действительно ли я использую правильный инструмент в WFC для связи между сервером и клиентом. . Я хочу, чтобы хост / сервер работал на файловом сервере и к нему подключалось несколько удаленных клиентов. Клиент будет пинговать сервер с тактовым импульсом, и иногда сервер может отправить команду клиенту. Я делал это с помощью удаленного взаимодействия или tcpsockets и с использованием «метода опроса клиента», где команды помещались в базу данных и когда клиент опрашивал сервер для команды каждые 10 минут, если была ожидающая команда для этого уникального клиента, который он получил Это. Это работало нормально и имело то преимущество, что НЕ было 1000 открытых соединений TCP-сокетов с сервером, поскольку клиент мог подключаться и отключаться только случайным образом. НО я решил попробовать WCF (в конце концов, это не последняя новинка в мире. заменяет удаленное взаимодействие?) и когда я нашел Duplex, я подумал, я бы его использовал .... СЕЙЧАС я думаю, что мне не хватает смысла в том, для чего нужен WCF Duplux ???

Помогите, мне не хватает концепций здесь ???