Where should I increase my ReceiveTimeout? - silverlight

I have a duplex TCP connection between a Silverlight client and a WCF C# server. The server is constantly pushing updates up to the client. However after about ten minutes of user inactivity, any user operation that gets sent to the server results in an exception, although the updates continue successfully.
Given the period of time involved and the inactivity on the client side I'm guessing it involves the ReceiveTimeout setting. However when I attempt to set it on the client (see below), it doesn't fix this.
CustomBinding binding = new CustomBinding(new BinaryMessageEncodingBindingElement(),
new TcpTransportBindingElement());
binding.ReceiveTimeout = TimeSpan.MaxValue;
EndpointAddress address = new EndpointAddress(testAddress);
testClient = new TestClient(binding, address);
Do I need to set this on the server side as well as or instead of the client side?
If I do need to set this on the server, how would I do this, as I'm using OperationContext.Current.GetCallbackChannel<ITestClient>() to get the callback interface?
The callback interface doesn't give me access to properties to set timeouts and I'm not sure what to cast it to to enable this. I tried setting it on the ServiceHost on the server side but this also didn't appear to fix it.

I would configure an extended OpenTimeout, ReceiveTimeout, and SendTimeout on both the client and server.

I think you should set on both sides.
you may try to get the binding used on service side (through ServiceHost.Description)and set its ReceiveTimeout.
I don't understand why you don't use netTcpBinding directly and use the web.config or app.config?

Turns out the answer is: it doesn't matter. Setting it on the client side was technically correct, but according to Configuring Web Service Usage in Silverlight Clients:
Caution: This value of receiveTimeout is not being respected in
Silverlight 4 and setting it will not affect the behavior of the
application.
I have since tested this and verified it was the case.
The answer ended up being implementing a keep alive call to the server once every four minutes (four minutes chosen because it's half of the ten minute receive timeout, minus a buffer).

Related

Chrome:POST/OPTIONS requests Fails with net::ERR_TIMED_OUT

The OPTION/POST Request is failing inconsistently with a console Error as err_timed_out. We get the issue inconsistently, it's only observed sometimes. Otherwise the request gets proper response from the back end. When it's timing out, the request doesn't even reach the server.
I have done some research on the stuff and found that due to maximum 6 connections to a resource restrictions it may wait for getting a connection released. But, I don't see any other requests pending ,all the other requests were completed.
In the timeline I can always see that it stalled for 20.00 seconds. Most of the time the time is same. But, it only shows that its been stalled for some time nothing else in the timeline.
The status of the request shows failed ERR_Connection_Timed_Out. Please help.
The Network Timing
Console Error
I've seen this issue when I use an authenticated proxy server and usually a refresh of the page fixes it.
Are you using an authenticated proxy server where you are seeing this behavior? Have you tried on a pc with direct access (i.e. without proxy) to the Internet?
I've got the same problem when I choose another ISP. I thought I would have only to put my new ID and password, but it wasn't the case.
I have an ADSL modem with a dry loop.
All others services were fine (DNS resolution, IP telephony, FTP, etc).
I did a lot of tests (disable firewall, try some others navigator, try under Linux, modem default factory, etc) none of those tests were successful.
To resolve the problem ERR_TIMED_OUT, I had to adjust the MTU and MRU values. I put 1458 rather than 1492, which is the default value.
It works for me. Maybe some ISPs use different values. Good luck.

WCF Timeout (HTTP Request was aborted/No endpoint listening)

I was modifying a WCF service to increase the timeout for a Silverlight client. Before modifying the timeouts I'm seeing CommunicationObjectAborted exception (The HTTP request to [URL] was aborted). At first I only modified the web.coffig of the WCF and it had no effect. I then followed this post (http://blog.ecofic.com/?p=379) and edited ServiceReferences.ClientConfig as well. Now I'm seeing a No endpoint exception. The exception was not thrown immediately after the client connects to WCF, but after about 1 minute after it connected to WCF. I suspect it has something to do with the timeouts?
I set open, close, send and receive timeouts to 5 minutes in both config files.
Any idea? Thanks!
As Richard pointed out, sendTimeout only be needed to set on the client (your Windows Phone app in this case). Double check the ServiceReferences.clientConfig as manually added value might get overwritten by Visual Studio.
Also you can check this post for using Fiddler on Windows Phone (emulator).
You should use Fiddler to analyse the requests performed by your application. This way, you will be able to know what happen when the request is sent, where exactly it is sent (if it is sent), and the response code from the server.
Obtaining these informations is the first step on the way to troubleshoot your issue.

Creating Web-service for modifying XPO objects by timer

I have several clients that create new objects. When new object is created I need to start a timer that will change some object properties when time is elapsed (each object can be visible only for defined client groups certain time).
I want to use for this purpuses web-service and wrote a method that starts timer.
For example I need to set timer to 5 minutes. Are there any restrictions for executing time? Will a timer keep my web-service alive?
Perhaps, I don't understand your task completely, but your idea about Web Service usage looks strange to me. Web Services are usually used to process requests from remote clients. I.e. a client calls method of a Web Service and Web Service returns a result to this client.
I think, I got your idea :). If you need to just change data in the DB, I think the better solution is to create a windows service which will ping web service when needed.

Silverlight4 client timouts on long running WCF calls

Hi I have silverlight client timeout problem tried the
TimeSpan getSessionMapTimout = new TimeSpan(0, 20, 0);
Client.Endpoint.Binding.CloseTimeout = getSessionMapTimout;
Client.Endpoint.Binding.ReceiveTimeout = getSessionMapTimout;
Client.Endpoint.Binding.SendTimeout = getSessionMapTimout;
Client.Endpoint.Binding.OpenTimeout = getSessionMapTimout;
Client.InnerChannel.OperationTimeout = getSessionMapTimout;
options including the InnerChannel.OperationTimeout , None of them work the silverlight client still timesout in 30 secs .
The interesting thing is the IE regestry settings "ReceiveTimeout"=dword:00007530 seem to override the Silverlight client settings, cause if i remove this from the registry, everything works fine.
How to make these timeout working from with in silverlight and override IE registry settings.
What kind of binding are you using? I'm using the Duplex binding for hours / days at a time and there's no issue.
Did you check the timeout on the server side? There's also the ASP.NET connection timeout to take into consideration (I think it's set to 30s or something by default).
I have found that, using the client stack outside of IE (in out-of-browser mode), requests that take longer than 10 seconds fail with an ArgumentNullException coming from HttpWebRequest.EndGetResponse(). From what I've seen on the web, other people have also experienced this in Firefox and Chrome, but in IE it seems to work fine (presumably it waits indefinitely and you can roll your own timeout).
I don't believe there's an API in the client stack for setting the timeout.
You need to use the Client Http stack in Silverlight if you need to extend the timeout. The standard browser stack that Silverlight uses has a timeout set by the browser and you can't manipulate it.
HttpWebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
That will register all Http to be on the client stack. However, using this method has some limitation. This page has a great chart showing the difference between the two stacks.

Aynchronous web server calls in Silverlight and maximum HTTP connections

I've read that Silverlight 2.0 imposes by design an asynchronous model when communicating with the web server. I haven't had a chance to experiment with Silverlight, but I assume that it uses a thread-pool to manage threads like in the .NET Framework.
Now, since some browsers, most notably Internet Explorer, have an hard-coded limit of maximum two concurrent HTTP connections that can be made on the web server, what happens if I make a bunch of asynchronous requests from Silverlight?
Does Silverlight bypass this limitation in the web browser and open as many HTTP connections as there are threads available, or do the asynchronous requests queue up and wait for one of the two connections to become available?
In IE (haven't tested others) Silverlight is restricted to 2 connections at a time.
The behavior in Silverlight is to simply not make the request. So if you make 5 Async web service requests right in a row, the first 2 will happen, the other three won't. No exception is thrown that i've seen...
Fiddler is a big help here :)
Create a messaging manager interface for your client. Any outgoing request are posted to a queue that this manager processes against. It would serially process queued messages (i.e., when the call back of the last message sent to the server is invoked, can then safely proceed to process the next queued message).
You can consume the other connection resource by keeping a Comet connection open to the server. The server would push any return messages to the client via this Comet connection. You'll need to stamp out-going messages with a unique number that can be embedded as a property on in-coming messages - so that results can be correlated to request. The messaging manager would dispatch a result message to the appropriate handler for that result.
Essentially you end up using two connection resources to establish bi-directional messaging. But there is no artificial limit on the number of requesters on the client (though request will get serially transmitted to the server). The act of sending is always fast, though, because you don't wait for any result to be computed - you just need to deliver the message reliably to the server and return. Results come back asynchronously on the other Comet connection.
We do something along these lines with our Flex client apps in conjunction to Adobe BlazeDS running in our Tomcat web server:
A Flex-based asynchronous stack
Firefox is also limited to two connections, in addition to IE as stated already.
Note that the limit is per hostname.
If you add entries to your hosts file, or use dns aliases you can get more connections. For example in testing, add lines like '127.0.0.1 test1' to your hosts file, and then you can open two connections to http://localhost and two more to http://test1
I guess, being a .NET application Silverlight 2 has an independent from browser limit.
I would assume It is maxconnection attribute in Machine.config as mentioned in http://support.microsoft.com/kb/828219
Firstly the Machine.config file would not be used as the Silverlight control is sandboxed with its own version of the CoreCLR.
I believe that the Silverlight control actually makes use of the underlying browser to make the asynchronous HTTP requests. This is most likely the case considering how the Silverlight control can't gain access to SOAP fault information as the SOAP specification requires that the server returns an HTTP 500 response code and the Silverlight control doesn't get that from the browser hosting the control.
This post here serves to confirm this.
As to the limit of concurrent HTTP connections, I believe IE5 and later limit the number of connections to the same site based on HTTP protocol version - HTTP/1.0 it limits to 4 connections and HTTP/1.1 to 3 connections. Most of the time the web server will limit the number of connections to 2 per client, queueing or discarding the remainder.

Resources