Fiddler fixes my problem, but why?

[Wes Jackson]

I've got an HTTP based program that runs on our LAN. Periodically I'm either losing packets or losing connection to this program and it errors out. So I installed Fiddler to watch the traffic and determine what is going on. The problem is when Fiddler is running, we never have the errors. So my question is, what is Fiddler doing to correct the problem?

 

Thanks,

Wes

[EricLaw]

Contrary to apparently popular belief, Fiddler has no magical components. :-)

You haven't provided nearly enough information to answer your question. Where is Fiddler running (client or server?). How have you determined that you're "losing packets"? What does "losing connection" mean? What is the program in question? What technology was it written using?

[Wes Jackson]

Eric,

The program in question is an accounting software called Deltek Vision. Its built on .Net and communicates to an sql database on a server. The errors we are getting happen at random and consist of " error 400 bad request" or " the underlying connection was closed". After weeks of troubleshooting with their support. They claim we are losing connection or dropping packets. I see no evidence of either one. So I decided to put Fiddler on the client, when I did I no longer had the issue. Ive narrowed it down to Windows 7 machines only. The server is a VM running 2008r2.

[Erik]

I have had this same experience. I had problems at a client where it appeared HTTPS connections were being abnormally terminated when using Chrome Frame inside Internet Explorer. We installed fiddler to test, and immediately the problem went away. I think there is some magic in there :)

 

We managed to work out that some element on their LAN was causing dropped connections to the server in question, only when using the SSL connection. The server was using a Subject Alternative Name certificate. When installing the certificate into the client machines local key store, the problem went away. As to why this problem went away when using Fiddler, only the Author can guess :)

[EricLaw]

.NET code can be fragile in that it can throw an exception if it's configured for KeepAlive but the server closes the connection after sending a response that doesn't have a Connection: close header on it. In the early days, Fiddler used to cause this problem (because it didn't keep client connections alive, and it didn't add a Connection: close response header). Today, Fiddler can mask the problem in buggy .NET code because it doesn't close KeepAlive connections to the client for two minutes, even if the server closed its connection to Fiddler before that time.

It's possible that this explains the problem here-- if there were something on the network that was causing idle connections to close quickly, it's possible that this would expose the bug in the .NET code.

You could use Fiddler's Timeline tab (with the Client PipeMap and Server PipeMap views) to examine connection reuse and see if this might explain what you're seeing. Or you could watch in a tool like Microsoft Netmon or Wireshark without Fiddler running.

[Wes Jackson]

Any particular reason the server would throw a Connection close Eric?

I'll run wireshark and see if I can view anything.

 

Thanks for all your help, it has given me more options to try. We were at a dead end.

[Wes Jackson]

Also...

 

The clients are connecting to server across NLAN. Gigabit pipe using only Dell Switches.

Route is 3 hops, avg response time 3-4ms

 

I've had SolarWinds Network monitor running for almost a week and there has never been a dropped packet or loss of connection.

[EricLaw]

Unfortunately, if you're not seeing premature connection closures with WireShark or a similar tool, I'm not sure what the problem could be.

To clarify on my original suspicions-- the server can close a connection in two ways:

1> It can say: "Connection: close" in the HTTP response header. This lets the client know the connection is closing and avoids the .NET bug.

2> It can simply close an idle connection at any time. This is perfectly legal, but can blow up .NET client code that expects the connection to be kept around since there was no "Connection: close" header.

As to why #2 might happen: Sometimes performance tuning products will do stuff like this to try to limit the # of open connections on a server. I don't know of any specific products that do this, but the thing to keep in mind is that such behavior is legal and HTTP clients should be able to handle it.