none
Named Pipe Timeout Issue

    Question

  • Hello,

    I have a named pipe duplex channel, and it seems that if I don't send a message across it approximately every 10 seconds, the channel faults with an IO.PipeException stating that the pipe was ended. Sending a message on a regular interval prevents this from happening. Is this the intended default behevior of named pipes, and if so, is there a particular setting I need to configure to change it? I thought inactivityTimeout might be the issue, but I didn't notice any configuration tags to configure the reliableSession as some of the other transports have.

    Thanks,
    Aaron

    Tuesday, October 03, 2006 11:41 PM

Answers

  • SendTimeout governs the entire Request/Reply operation--both sending a message and waiting for the reply.  A Request/Reply operation is not subject to two different timeouts.

    ReceiveTimeout does not affect operation timeouts at all.  It only affects how long a session will stay alive if no messages are transmitted.

    You can safely raise ReceiveTimeout in your scenario, and your clients will still return within the smaller SendTimeout.

    mjm

     

    Wednesday, October 04, 2006 10:02 PM

All replies

  •  

    Check ReceiveTimeout. Here is a snippet from the SDK docs

    <bindings>
      <!--
            Following is the expanded configuration section for a NetNamedPipeBinding.
            Each property is configured with the default value.
         -->
      <netNamedPipeBinding>
        <binding name="Binding1"
                 closeTimeout="00:01:00"
                 openTimeout="00:01:00"
                 receiveTimeout="00:10:00"
                 sendTimeout="00:01:00"
                 transactionFlow="false"
                 transferMode="Buffered"
                 transactionProtocol="OleTransactions"
                 hostNameComparisonMode="StrongWildcard"
                 maxBufferPoolSize="524288"
                 maxBufferSize="65536"
                 maxConnections="10"
                 maxReceivedMessageSize="65536">
          <security mode="Transport">
            <transport protectionLevel="EncryptAndSign" />
          </security>
        </binding>
      </netNamedPipeBinding>
    </bindings>

    Wednesday, October 04, 2006 5:04 AM
  • That's an interesting suggestion. I had thought receiveTimeout was the time the framework waited for a response in a request/reply scenario. If it in fact controls the amount of time the framework waits for receiving any kind of message, then my next question is, what setting do I use to control the former? I'll tweak receiveTimeout to see if it makes a difference, since as you can see from my current binding, I do have it set rather low.

          <netNamedPipeBinding>

            <binding name="PrivateBinding" closeTimeout="00:00:20"

             receiveTimeout="00:00:30" sendTimeout="00:00:30">

              <security mode="Transport" />

            </binding>

          </netNamedPipeBinding>

     

    Wednesday, October 04, 2006 12:24 PM
  • Well, I'm rather confused to report that increasing the receive and send timeouts appears to have made a difference. Given the description from the documentation, this makes no sense.

    ReceiveTimeout = "Maximum time to wait for a read operation to complete before the transport raises an exception."
    SendTimeout = "Maximum time to wait for a write operation to complete before the transport raises an exception."

    There should be no read or write operation in progress, therefore no reason to raise an exception, yet the channel appears to be faulting. If the issue I'm seeing was due to an operation in progress, then sending extra messages across the line as I was doing every 10 seconds should have still faulted the channel since that same initial message would have already been in progress and ready to fault after 30 seconds regardless of whatever I sent afterwards.

    The behavior I'm seeing is that receiveTimeout appears to be acting as an inactivityTimeout for the channel. Even more unusal, when the fault occurs, I don't get a TimeoutException, the pipe just terminates with System.IO.PipeException. Either I've missed a key piece of information here, which is entirely possible, or the framework isn't acting as described. Here is the exception trace, perhaps it will help someone to explain what's going on here.

    <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Error">

      <TraceIdentifier>

        http://msdn.microsoft.com/en-US/library/System.ServiceModel.Diagnostics.ThrowingException.aspx

      </TraceIdentifier>

      <Description>Throwing an exception.</Description>

      <AppDomain>Client.vshost.exe</AppDomain>

      <Exception>

        <ExceptionType>

          System.IO.PipeException, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

        </ExceptionType>

        <Message>

          There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).

        </Message>

        <StackTrace>

          at System.ServiceModel.Channels.PipeConnection.OnAsyncReadComplete(Boolean haveResult, Int32 error, Int32 numBytes)

          at System.ServiceModel.Channels.OverlappedContext.CompleteCallback(UInt32 error, UInt32 numBytes, NativeOverlapped* nativeOverlapped)

          at System.ServiceModel.Diagnostics.Utility.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error, UInt32 bytesRead, NativeOverlapped* nativeOverlapped)

          at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

        </StackTrace>

        <ExceptionString>

          System.IO.PipeException: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).

        </ExceptionString>

      </Exception>

    </TraceRecord>

     

    Wednesday, October 04, 2006 1:40 PM
  • SendTimeout governs Send and Request.  When calling a typed client, this means that regardless of the value of IsOneWay on OperationContractAttribute, the operation will be governed by SendTimeout.

    ReceiveTimeout governs Receive and ReceiveRequest, but applications rarely call these methods explicitly--the dispatcher calls them for you.

    The dispatcher borrows ReceiveTimeout to decide how long to wait to receive a message before considering a session to be idle/dead.  The idea is that if you had called Receive with that timeout and did not get any messages, the Receive call would fail and the session would no longer be usable.  That said, I think it might have been less confusing to have another value outside the binding config that controls this called "SessionIdleTimeout".

    mjm

     

    Wednesday, October 04, 2006 6:15 PM
  • If I understand correctly, this means that the dispatcher is going to end the session after the ReceiveTimeout even if it is not actually waiting for a response to a request. If so, I think it's more than a question of terminology that's at fault here. We're talking about two distinct timeout periods, so having one borrow from the other seems a little shortsighted. If there's a good reason for it and a good way to deal with this scenario given those constraints then please let me know.

    This is my scenario:

    1. I have a service that accepts subscribers and generates events.
    2. A client will create a channel to the service, subscribe to events, and then update its interface based on these events. Occasional polling to the service may occur to verify the connection, but over a time span much longer than a single operation timeout would be for.
    3. When the client UI is closed, the channel is closed, and the service removes the client during its next update.
    4. Client/service are on the same machine, emphasis is on near real-time updates and continually responsive UI.
    5. Given the subscriber model, the Session should not terminate until an IsTerminating method is called, a send/receive timeout occurs from an operation, or a user configurable timeout has elapsed due to no communication. With other transports, the latter seems to be achieved with the ReliableSession.InactivityTimeout property, but I see no such property for named pipes.

    I can't bump up my receive timeout to achieve a longer session because I want my client to be notified quickly if the service goes down during an operation or takes longer than an expected time span. Likewise, if I try to keep the session alive by sending messages across the line within the short timeout window I need for operations, I'm blasting the channel with a ton of unnecessary traffic and introducing a lot of overhead to the implementation.

    I hope someone can suggest a good solution given the current timeout implementation. Otherwise, any chance the handling of these distinct timeout periods could change for the better between now and final release?

    Wednesday, October 04, 2006 7:01 PM
  • SendTimeout governs the entire Request/Reply operation--both sending a message and waiting for the reply.  A Request/Reply operation is not subject to two different timeouts.

    ReceiveTimeout does not affect operation timeouts at all.  It only affects how long a session will stay alive if no messages are transmitted.

    You can safely raise ReceiveTimeout in your scenario, and your clients will still return within the smaller SendTimeout.

    mjm

     

    Wednesday, October 04, 2006 10:02 PM
  • Ah! That explains it. In that case, I agree with you, a label change would be helpful.  

    I'd also suggest some additional text in the SDK documentation to make the relationship to a session more clear. I expected to find this kind of information on the SendTimeout/ReceiveTimeout entries. What I found was:

    SendTimeout = "Gets or sets the interval of time provided for a send operation to complete."
    ReceiveTimeout = "Gets or sets the interval of time provided for a receive operation to complete."

    While those statements may be true, they're generic, and you really have to understand how the framework internally uses IReplyChannel, IInputChannel, and IOutputChannel to comprehend the implications of those timeout values. Working primarily at the contract level, as I suspect most probably are, I haven't had the need yet to use those interfaces directly. Ignorance is bliss I suppose.

    Anyhow, thank you very much for clarifying this. I know as release nears the documentation will improve and many of the issues I've struggled with will be more easily explained. In the mean time, I appreciate being able to rely on the experts here in this forum. Thanks again.

    Wednesday, October 04, 2006 10:36 PM
  • Hi,

    I have tried setting the receiveTimeout to 00:05:00, and yet the namedpipe times out and closes the connection after 10 mins. What could be the problem? Why does it still take the default timeout of 10 mins? Please find below the settings I use for the netNamedPipeBinding.

        <bindings>
          <netNamedPipeBinding>

            <binding name="NamedPipe"         

    receiveTimeout="00:05:00"


    sendTimeout="00:05:00"

             maxBufferPoolSize="5242880"
              maxBufferSize="655360"
              maxReceivedMessageSize="655360">
                <readerQuotas maxArrayLength="16384" maxBytesPerRead="4096" maxDepth="32" maxNameTableCharCount="16384" maxStringContentLength="8192" />
            </binding>
          </netNamedPipeBinding>
        </bindings>

    Any help would mean a lot.

    Thanks in advance.

    Thursday, December 23, 2010 1:32 PM
  • any one knows solution for nihar dalai's query... any help is appreciated
    Thursday, August 11, 2011 7:13 AM