Thanks in advance for your time and assistance.
I am using Azure Client Library (ie. CloudStorageAccount - CloudBlobClient - CloudBlob) to download/upload blobs in a WPF application.
I would like to set a timeout session in my WPF client application to abort attempt to get a cloud blob. This is different that the server-side timeout that I can set on a blob transfer session. I want to do this as internet connectivity where the application will be used has very unstable intermittent connection.
In other words, I try to do BlobContainer.FetchAttributes before actual data transfer to check internet connectivity. If there is no connection, I do not want to wait 90 odd seconds before it times out and throws an exception.
I have already tried setting timeout in BlobRequestOptions but this does not work as it is applicable only once I have a connection.
Have I understood the settings wrong or is there something else I need to setup/configure/code to achieve a quicker timeout?
I can see in Fiddler that StorageClient library is using HTTP behind the scenes and as per some post I read, I have tried setting timeout in app.config as depicted below. This did not work either.
<configuration>
<system.web>
<httpRuntime executionTimeout="5" />
</system.web>
</configuration>
Sample Timeout using BlobRequest Options:
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
blobContainer = blobClient.GetContainerReference("abcd");
CloudBlob blob = blobContainer.GetBlobReference(aCloudPath);
BlobRequestOptions bro = new BlobRequestOptions()
{ Timeout = TimeSpan.FromSeconds(5) };
blob.DownloadToFile(aLocalPath, bro);
Either options do not work!!
First, changing the httpRuntime executionTimeout in your app.config will not work. This is a setting used server-side by ASP.NET.
Second, the code with the BlobRequestOptions should work, but there's a caveat. By default, the BlobClient comes with an exponential backoff retry policy to handle transient conditions (ie: no network access). Between each retry it will wait a bit and then try again.
If you want to disable this when trying to check for network access, you can simply disable the retry policy:
blobClient.RetryPolicy = () =>
{
return (int currentRetryCount, Exception lastException, out TimeSpan retryInterval) =>
{
retryInterval = TimeSpan.Zero;
return false;
};
};
Be sure to only disable this for when you're testing the network access, don't disable this for your actual requests.
Oh and by the way, why don't you simply use something that already exists to check the internet connection? There are a few APIs available in Windows, like InternetCheckConnection.
And if your connection is unstable, it might be a better idea to improve the retry policy instead of disabling it (look at TOPAZ for example).
Related
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.
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).
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.
I need to stress-test a silverlight application which uses Windows authentication mode. To achieve this task I am using the StressStimulus Fiddler addin.
What I am doing is to log in and doing some stuff like search etc. I captured the HTTP messages transferred in Fiddler and replayed them using the above mentioned tool.
However, when I replay the packages I always get a 401.1 Server responses.
I tried to use different Authorization approaches (NTLM and Negotiate) but I always get the same response message.
Fiddler seems to be properly configured. In the Fiddler options menun "Reuse client connection" is checked as well as "Reuse connection to server". I even raised the KeepAliveTimeout in the registry without any success.
Does anybody have an idea whats going wrong?
You can't replay authentications such as NTLM and Negotiate. One the most important features of any challange/response authentication is that it must not be replayable. Without this feature an attacker can monitor a successful authentication and then replay the same sequence to gain access to things they aren't entitled.
I'm having an issue where IIS 7.5 (on Windows 7 64-bit) is failing when I call it from an out-of-browser Silverlight 4 app using SSL and a client certificate, with the message "The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)". The request does make it to IIS. here is a sample from the failed request trace:
The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3) http://www.slipjig.org/IISError.gif
I am using the browser HTTP stack, because the client HTTP stack does not support client certificates. The client code attempting to hit the server is the Prism module loader. If I run the app out-of-browser but ignore client certs, or if I run the application in-browser but require client certs, it works fine. It seems to be the combination of the two that is causing the problem.
I tried the following to gather more info:
Used Fiddler to view the failing request. It works if Fiddler is running (presumably because Fiddler is handling the client certificate differently?);
Created an .aspx web form to serve up the module .xaps;
Created an HTTPModule to see if I could intercept the request before it failed;
Used a packet sniffer to see if I could tell if the client certificate was being sent correctly.
None of the above gave me much useful information beyond what I could see in the trace file, although the Fiddler thing is interesting.
Any ideas? Thanks in advance!
Mike
I beat my head against the wall for weeks on this problem. Here's what I learned and how I finally worked around it.
Prism's FileDownloader class uses System.Net.WebClient to load modules. In OOB mode, WebClient seems to use the same stack as IE, but it apparently either doesn't send the client certificate, or (more likely) doesn't correctly negotiate the SSL/client cert handshake with the server. I say this because:
I was able to successfully request .xap files using Firefox and Chrome;
I was not able to successfully request .xap files using IE;
IIS would fail with a 500, not a 403.
I couldn't get good visibility into what was actually happening over the wire; if I used Fiddler, it would work, because Fiddler intercepts communications with the server and handles the client certificate handshake itself. And trying to use a packet sniffer obviously wouldn't tell me anything because of SSL.
So - I first spent a lot of time on the server side trying to eliminate things (unneeded handlers, modules, features, etc.) that might be causing the problem.
When that didn't work, I tried modifying the Prism source code to use the browser's HTTP stack instead of WebClient. To do this, I created a new class similar in design to FileDownloader, implementing IFileDownloader, that used the browser stack. I then made some changes to XapModuleTypeLoader (which instantiates the downloader) to make it use the new class. This approach failed with the same error I was originally experiencing.
Then I started researching whether a commercial third-party HTTP stack might be available. I found one that supported the features I needed and that supported the Silverlight 4 runtime. I created another implementation of IFileDownloader that used that stack, and BOOM - it worked.
The good news with this approach is that not only can I use this to load modules, I can also use it to protect communications between the client and our REST API (a benefit we were going to give up, before).
I plan to submit a patch to Prism to allow the downloader to be registered or bound externally, as it's currently hard-coded to use its own FileDownloader. If anyone is interested in that or in the commercial HTTP stack I'm using, contact me (msimpson -at- abelsolutions -dot- com) for links and code samples.
And I must say this - I still don't know for sure whether the root problem is in the HTTP stack on the client side or the server side, but it's a FAIL on Microsoft's part nonetheless.
What we (Slipjig and I) found out this week is that there does appear to be a way around these issues, or at least, we're on the trail to determining whether there is a reliable, repeatable way. We're still not positive on that, but here's what we know so far:
At first pass, if you have code like this you can start making requests with either the Browser or Client stack:
First, place a "WebBrowser" control in your Silverlight XAML, and make it send a request to your HTTPS site.
This may pop up the certificate dialog box for the user. Big deal. Accept it. If you have only one cert, then you can turn an option in IE off to suppress that message.
private void Command_Click(object sender, RoutedEventArgs e) {
// This does not pop up the cert dialog if the option to take the first is turned on in IE settings:
BrowserInstance.Navigate(new Uri("https://www.SiteThatRequiresClientCertificates.com/"));
}
Then, in a separate handler invoke by the user, create an instance of your stack, either Client or Browser:
private void CallServer_Click(object sender, RoutedEventArgs e) {
// Works with BrowserHttp factory also:
var req = WebRequestCreator.ClientHttp.Create(new Uri("https://www.SiteThatRequiresClientCertificates.com/"));
req.Method = "GET";
req.BeginGetResponse(new AsyncCallback(Callback), req);
}
Finally, the Callback:
private void Callback(IAsyncResult result)
{
var req = result.AsyncState as System.Net.WebRequest;
var resp = req.EndGetResponse(result);
var content = string.Empty;
using (var reader = new StreamReader(resp.GetResponseStream())) {
content = reader.ReadToEnd();
}
System.Windows.Deployment.Current.Dispatcher.BeginInvoke(() =>
{
Results.Text = content;
});
}
I had the same issue and I fixed it by creating the certificate using makecert. Follow the steps from this article http://www.codeproject.com/Articles/24027/SSL-with-Self-hosted-WCF-Service and replace CN with your ip/domain. In my case I have tested the service on the local machine and run the commands as follows:
1) makecert -sv SignRoot.pvk -cy authority -r signroot.cer -a sha1 -n "CN=Dev Certification Authority" -ss my -sr localmachine
after running the first command drag the certificate from "Personal" directory to "Trusted Root Certification Authority"
2) makecert -iv SignRoot.pvk -ic signroot.cer -cy end -pe -n
CN="localhost" -eku 1.3.6.1.5.5.7.3.1 -ss my -sr
localmachine -sky exchange -sp
"Microsoft RSA SChannel Cryptographic Provider" -sy 12
In case you want to run the silverlight application on another machine, export the certificate created at step1 and then import it on any machine where you want your application to run.