﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on Writing unreliable software</title><description>MSPaint &amp; PowerPoint
</description><link>http://ayende.com/3307/writing-unreliable-software#comment9</link><guid>http://ayende.com/3307/writing-unreliable-software#comment9</guid><pubDate>Thu, 15 May 2008 13:11:57 GMT</pubDate></item><item><title>Eric commented on Writing unreliable software</title><description>Oren,
  
  
This is a bit of a tangent, but what tools do you use for the nice graphics you use in your posts? Especially code mark-up with boxes and arrows?
  
  
Thanks!
</description><link>http://ayende.com/3307/writing-unreliable-software#comment8</link><guid>http://ayende.com/3307/writing-unreliable-software#comment8</guid><pubDate>Thu, 15 May 2008 13:04:58 GMT</pubDate></item><item><title>Ayende Rahien commented on Writing unreliable software</title><description>The scenario that I have is file downloads, which is why I am hitting this.
  
Thanks for confirming that the queue is not FIFO
</description><link>http://ayende.com/3307/writing-unreliable-software#comment7</link><guid>http://ayende.com/3307/writing-unreliable-software#comment7</guid><pubDate>Fri, 09 May 2008 19:46:49 GMT</pubDate></item><item><title>Ayende Rahien commented on Writing unreliable software</title><description>Next on the list of things to check, but I don't think so
</description><link>http://ayende.com/3307/writing-unreliable-software#comment6</link><guid>http://ayende.com/3307/writing-unreliable-software#comment6</guid><pubDate>Fri, 09 May 2008 19:35:04 GMT</pubDate></item><item><title>Evan commented on Writing unreliable software</title><description>For the above, you can google "Http Pipelining" for more information as that's how .NET/IIS do it on the wire.
  
  
</description><link>http://ayende.com/3307/writing-unreliable-software#comment5</link><guid>http://ayende.com/3307/writing-unreliable-software#comment5</guid><pubDate>Fri, 09 May 2008 17:54:09 GMT</pubDate></item><item><title>Evan commented on Writing unreliable software</title><description>"The .NET framework is allowing (by default) only 2 connections to a server. GetLog will only be executed when there is a free slot, and the async requests are ahead of it in the queue. (Actually, I haven't verified the exact sequence in which this would be executed)."
  
  
Two things:
  
  
The queue doesn't wait for a response from the first request before sending another.  As an example, if you invoke 14 very slow methods asynchronously and a 15th fast method asynchronously, you will get the 15th response back first.  The fact that you can only have two sockets open to the server does not mean that you can only have two requests executing at a time.  The queue means that you can only *send* 2 requests at a time (one over each socket).  A queue on the other side means you will only *receive* 2 requests at a time.
  
  
2 connections != 2 concurrent executing requests
  
  
This generally doesn't factor into anything unless the requests or responses become large.  In that scenario, if you have 3 responses that need to be received and 2 that are large files (several megabytes), the the two multimegabyte files will clog the connections (because of the time needed to receive the data).  Opening the 3rd connection would allow the little response (#3) to come though.
  
  
Generally speaking, this only factors in if you are sending or receiving large requests/responses.
  
  
Although this can bite you if you are doing heavy webservice traffic between two machines (as SOAP is very bloated).  It can cause an artificial throughput/performance bottleneck--especially if there is a high speed network connection between the machines.
  
  
Now for the second thing:
  
  
The queue isn't strictly FIFO.  Request #N may be sent before Request #1.  In simple test scenarios, I've seen the 15th async request received on the server (and processed) before the 1st (when sending the requests asynchronously very close together).
  
  
</description><link>http://ayende.com/3307/writing-unreliable-software#comment4</link><guid>http://ayende.com/3307/writing-unreliable-software#comment4</guid><pubDate>Fri, 09 May 2008 17:45:23 GMT</pubDate></item><item><title>Ravi Terala commented on Writing unreliable software</title><description>TFS proxies use UnsafeAuthenticatedConnectionSharing and ConnectionGroupName. All the proxies to a server use the same connection group name.
  
  
My guess is that what you observed is due to this connection group settings. Is there a way for you to find the ServicePoint.ConnectinLimit value for your app? There is a good chance that these are related.
</description><link>http://ayende.com/3307/writing-unreliable-software#comment3</link><guid>http://ayende.com/3307/writing-unreliable-software#comment3</guid><pubDate>Fri, 09 May 2008 16:51:14 GMT</pubDate></item><item><title>Gian Maria Ricci commented on Writing unreliable software</title><description>I hitted the problem of timeout not working in async request a while ago. I too think that this is a bug, it is documented, but it remain a bug.
  
  
Alk.
</description><link>http://ayende.com/3307/writing-unreliable-software#comment2</link><guid>http://ayende.com/3307/writing-unreliable-software#comment2</guid><pubDate>Fri, 09 May 2008 15:10:35 GMT</pubDate></item><item><title>Scott Allen commented on Writing unreliable software</title><description>Does the software behave differently if you configure the framework to allow more concurrent requests?
</description><link>http://ayende.com/3307/writing-unreliable-software#comment1</link><guid>http://ayende.com/3307/writing-unreliable-software#comment1</guid><pubDate>Fri, 09 May 2008 14:20:07 GMT</pubDate></item></channel></rss>