none
the message contains an invalid or expired security context token or because there is a mismatch between bindings..... RRS feed

  • Question

  • I hosted WCF as windows service and calling wcf service in a windows app. initially they are communicated well but after around 20 mins i am getting following error:

    The message could not be processed. This is most likely because the action 'http://tempuri.org/ICommandService/StopSendingCommands' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.

    An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail., Error Message Track : 
    Server stack trace: 
       at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.ProcessReply(Message reply, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)
       at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.Request(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    Here's client's config file, 

    <system.serviceModel>
        
        <bindings>
          <wsHttpBinding>
            <binding name="WSHttpBinding_ICommandService" closeTimeout="00:01:00"
              openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
              bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
              maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text"
              textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
              <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                maxBytesPerRead="4096" maxNameTableCharCount="16384" />
              <reliableSession ordered="true" inactivityTimeout="00:10:00"
                enabled="false" />
              <security mode="Message">
                <transport clientCredentialType="Windows" proxyCredentialType="None"
                  realm="" />
                <message clientCredentialType="Windows" negotiateServiceCredential="true"
                  algorithmSuite="Default" />
              </security>
            </binding>
          </wsHttpBinding>
        </bindings>
        <client>
          <endpoint address="http://localhost:8732/CommandServiceLibrary"
            binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ICommandService"
            contract="CommandServiceReference.ICommandService" name="WSHttpBinding_ICommandService">
            <identity>
              <dns value="localhost" />
            </identity>
          </endpoint>
        </client>
      </system.serviceModel>

    manojkshukla

    Thursday, January 17, 2013 6:05 AM

Answers

  • Hi,

    >>To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.

    As mentioned in the error message, please compare the binding setting(e.g security mode setting, it need be mode="Message" as same with client) between client and service, and try increase the value of recieveTimeout of the binding for the service.

    Best Regards.


    Haixia
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 18, 2013 6:09 AM
    Moderator