Price & Order About Download Technical Support Version 10
Solutions Blog: Connection Errors

September 11, 2014

If you check your error log, you will most likely see entries that look something like this:

    [11/Sep/2014]  HTTP Session  TCP Send Error: Pipe closed. (Client terminated connection.)
    [11/Sep/2014]  HTTP Session  An error occurred while sending a file. -32 (Broken connection)

The question is... What do we make of these errors?

Don't Be Too Worried

By themselves, these errors in your log files are no cause for concern, at all. Connection errors occur all the time, for a variety of reasons. The error may have been caused by a network connection failure, but it's far more likely that the user simply closed the browser window, the client computer went to sleep, or the user decided to cancel the transfer for some reason.

The error may even have been part of normal activity. Browsers begin downloads and then cancel them all the time during entirely normal processing. For example, when a Safari user clicks a link to a movie, Rumpus starts sending the file. But Safari doesn't actually play videos, QuickTime does, so when Safari sees that the file being downloaded is a movie, it halts the transfer and then passes the URL off to QuickTime. QuickTime then begins the transfer again and plays the video. Rumpus logs the fact the the transfer was interrupted, but this is completely normal activity and from the user's perspective, everything worked perfectly.

The moral of the story is this... Connection errors in your log files are to be expected. By themselves, errors do not necessarily indicate any problem at all, and if users aren't reporting any issues, these error messages can be safely ignored.

So, if that's the case, why does Rumpus log these errors?

And Don't Expect Too Much

Error messages are useful in helping to diagnose problems when they occur, so when users are reporting problems, connection errors should be looked at more carefully. As I said, by themselves connection errors can be ignored, but when paired with reproducible client problems, they become a useful diagnostic tool.

Unfortunately, the connection error itself (lines similar to those shown above) don't provide much detail about the nature of the problem, if indeed there was a problem. The messages indicate that a connection unexpectedly went dead, but the server has no idea why the connection went dead. It could have been for one of the normal reasons described above, or it could be a router/firewall deciding to terminate the transfer for a security reason, a flaky Internet connection, a faulty network device, or any of a dozen or more other reasons. When transfers are disconnected, the key question is where the disconnect occurred, but unfortunately, the server just doesn't have access to that information.

For tips on troubleshooting recurring, seemingly random disconnection problems, see the Broken Transfers article I wrote a couple of years ago.

That's not to say that error logs are useless. The fact that a connection was dropped can be useful in diagnosing a reproducible problem. Also, other error messages in the log that precede or follow the connection error can be helpful in discovering details about what was happening at the time of the disconnect.