Develop Reference

HttpListener setting a total connection timeout

I am trying to control the maximum total duration of a single connection in HttpListener. I am aware of the TimeoutManager property and the 5 or so different timeout values that it contains but it is unclear whether or not setting each of those values will add up to the total places where delay may occur in a connection.
I am looking for something more along the lines of: "If we have a connection that lasts more than x s from the moment of opening the connection until now, abort it without sending anything else or waiting for anything else."
EDIT
To clarify, the scenario that I was experimenting with involves the server trying to send the response and the client not receiving. This causes HttpListenerResponse.OutputStream.Write() to hang indefinitely. I was trying to find a method that I can call from another thread to hard-abort the connection. I tried using OutputStream.Close() and got Cannot Close Stream until all bytes are written. I also tried HttpListenerResponse.Abort() which produced no visible effect.

None of those properties will do what you want. HttpListener is intended to control the request flow, incomming and outgoing data, so it doesn't handle the time between when the response has been fully received and when you send a response, it's your responsability to take care of it.
You should create your own mechanism to abort the request if the total time is higer than the desired one, just a timer can be enough, when a new connection is created enqueue a timer with the total timeout as expiring time, if the request ends before the timer expires cancel the timer, else the timer aborts the request.

Faulted WCF duplex callback after inactivity - keep alive long-running push notifications

In short
How to prevent a duplex callback channel to be closed after an idle period?
In detail
I have a mostly working duplex WCF setup over NetTcpBinding i.e. the client can talk to the server and the server can call back to the client.
Furthermore, I have a reliable session such that the client does not lose the connection to the server after the default period of inactivity, achieved with the following configuration on both client and server:
var binding = new NetTcpBinding(SecurityMode.None);
// Need to prevent channel being closed after inactivity
// i.e. need to prevent the exception: This channel can no longer be used to send messages as the output session was auto-closed due to a server-initiated shutdown. Either disable auto-close by setting the DispatchRuntime.AutomaticInputSessionShutdown to false, or consider modifying the shutdown protocol with the remote server.
binding.ReceiveTimeout = TimeSpan.MaxValue;
binding.ReliableSession.Enabled = true;
binding.ReliableSession.InactivityTimeout = TimeSpan.MaxValue;
However, after a period of inactivity of less than half an hour (haven't measured the minimum time exactly), the server is unable to use the callback again - the server just blocks for a minute or so and I do not see any exceptions, while nothing happens on the client side (no evidence of callback).
Leads and root causes?
Note that I can use the callback fine twice in a row consecutively, as long as I do not wait long in between the callback calls.
Are the callbacks configured somewhere else? Do callbacks have their own timeouts etc?
Might it be a blocking/threading issue - need to either set UseSynchronizationContext=false on your client, or avoid blocking while waiting for the message to be received
Should DispatchRuntime.AutomaticInputSessionShutdown be set to false, and if so, how? I'm not really sure how it relates to reliable sessions and I do not know where to access this property
Anything else?

I achieved this by extending the BaseClient class with an automatic keep alive message to be invoked on the target interface when no other calls are made.

Why is a TimeoutException not faulting my channel?

I have a duplex WCF service and client running on the same machine. The client is configured to have 15 second timeouts:
<binding name="NetTcpBinding_IServiceIPC" closeTimeout="00:00:15"
openTimeout="00:00:15" receiveTimeout="00:00:15" sendTimeout="00:00:15" />
The client is handling faults like this:
client.InnerChannel.Faulted += FaultHandler;
client.InnerDuplexChannel.Faulted += FaultHandler;
client.ChannelFactory.Faulted += FaultHandler;
If I kill my Service process, the client correctly gets a TimeoutException after 15 seconds:
This request operation sent to net.tcp://localhost:8732/Service/ did not receive a reply within the configured timeout (00:00:15). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client. (System.TimeoutException)
However, the channel is not faulted at this point. My fault handler doesn't end up getting called until about 5 minutes after I kill the Service process. I thought that a TimeoutException would fault the channel (see this answer), but somehow that doesn't appear to be the case. Is there any way I can force the channel to be faulted more quickly after the Service process is killed?

This question Duplex channel Faulted event does not rise on second connection attempt suggestions the Faulted event isn't always fired. And the WCF state flow diagram on MSDN confirms that possibility - http://msdn.microsoft.com/en-us/library/ms789041.aspx
There are many paths to the closed state that don't go through the faulted state. Most likely, when you time out, the Abort() method is being called and you transition from the open state to the closing state without going through the faulted state. Add some logging to check the state throughout execution. If you're trying to reopen the channel after timing out, that would explain why you end up in the faulted state 5 minutes later. To solve your bigger problems, move logic in the FaultedHandler elsewhere so it's executed when you reach the closed state through other paths.

I know the question is old. But I searched quite a lot and always ended up here. So I thought I'd post my findings here:
It depends which Timeout.
If you hit the SendTimeout or ReceiveTimeout of your binding (in my case NetTcpBinding), then yes, the channel will fault.
BUT, if you hit the OperationTimeout of your Service (in my case DuplexChannel) then you will just get a TimeoutException and the channel will NOT fault.

Is there an execution timeout for WCF operations marked as OneWay?

Does the OneWay operations in WCF service execute as long as the operation is complete?
By my experiment, I think there is no timeout. I was able to run an operation for half an hour. (I closed after that)
Can someone experienced in WCF answer this? If there is a timeout, where can I specify it

OneWay operations don't wait for a Reply Message. It just writes data to the network connection and returns. So, the only "wait time" would be the time required to write the message to the network.
Be aware though that WCF can still block the client (Clients Blocking with One-Way Operations):
this means that any problem writing the data to the transport prevents the client from returning. Depending upon the problem, the result could be an exception or a delay in sending messages to the service.
Edit: Regarding timeout, they are set on the binding. If your operation can't perform his "Send Message", it can still timeout.

There is no timeout. You have to handle it by yourselves in running operation. Timeouts are related to working with channels but in case of one way operation the message is received and passed to operation and no more interaction with channel will ever occure.

CommunicationException with 'not recognized sequence' message in WCF

I get a CommunicationException while using WCF service. The message is:
The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted.
The exception is thrown in a moment after a contract method was called. Before calling contract method the channel state is Opened. I restore my service client after catching this exception and for some time it works fine. But then this error occures again. It seems like some timeout is exceeded, but I can't understand which one exactly.
I use wsHttpBinding with reliableSession enabled. The InactivityTimeout is set to half an hour and I'm sure it's not exceeded, because exception is thrown earlier.

I solved the problem. The reason was RecieveTimeout on a server side. It was set to 1 minute, so after having no requests during 1 minute server used to close a channel, and when client tried to call a contract, channel was already crashed due to the timeout.
I found the solution after reading this article:
http://msdn.microsoft.com/en-us/library/system.servicemodel.reliablesession.inactivitytimeout.aspx

I received this error while setting up a new WCF service which returned a list of objects.
My understanding is that WCF services can only pass very simple objects back n forth.
So objects with anything other than public properties will not be transferable.
The object had a read only property doing a bit of logic.
Once I got rid of this, rebuilt, and updated the web references, the error went away.

Tip:
If you're returning a object and it has properties check the gets and sets of each one.
We had a problem around it.

I have seen this happen when an application pool gets recycled.
Look at the very last section of this blog about service recycling .