I am running Server 2003 and ASP.Net to serve up file
downloads.  The problem is that the files keep timing out
on Dial-Up accounts.  I have had this problem before and
I switched the downloads to dedicated boxes.  Recently I
upgraded the hardware and OS.  This problem has been
occuring ever since.

The customers are receiving one of two errors.  Either
they get "The connection with the server was reset" while
downloading; or they get "Could not initialize
installation. File size expected=4113724, size
returned=3239443" when installing.  I have thought about
chunking but I am just not sure what to do.

I reset the connection timeout inside of the web app to
14,400 seconds.  This is what I had it set too in server
2000 and it worked beautifully.  The file size ranges
from less than 1 MB to around 100 MB.  Any help would be
greatly appreciated.

Another side note, I was noticing that the DOTNETBB
downloads seemed to have the same issue as our server,
could they be related?

[ Post a follow-up to this message ]

"DanTheMan" <DanTheMan@discussions.microsoft.com> wrote in message
news:8FAE6F9F-0E30-4192-A7D1-AE766DCCF8D1@microsoft.com...
>I am running Server 2003 and ASP.Net to serve up file
> downloads.  The problem is that the files keep timing out
> on Dial-Up accounts.  I have had this problem before and
> I switched the downloads to dedicated boxes.  Recently I
> upgraded the hardware and OS.  This problem has been
> occuring ever since.
>
> The customers are receiving one of two errors.  Either
> they get "The connection with the server was reset" while
> downloading; or they get "Could not initialize
> installation. File size expected=4113724, size
> returned=3239443" when installing.  I have thought about
> chunking but I am just not sure what to do.

At first, you should set the Server.TimeOut setting sufficiently for a big
download.
Second, disable buffering, since this will eat your RAM totally.
Response.AppendHeader("Content-Size", file.Length.ToString()); will fix the
download size measurement (client-side)...

About chunking. You don't need to worry about that... But it's a good idea
to have a loop
while (Request.IsClientConnected())
{
// write blocks of 4096 bytes (eg)
}

--
compatible web farm Session replacement for Asp and Asp.Net
http://www.nieropwebconsult.nl/asp_session_manager.htm

> I reset the connection timeout inside of the web app to
> 14,400 seconds.  This is what I had it set too in server
> 2000 and it worked beautifully.  The file size ranges
> from less than 1 MB to around 100 MB.  Any help would be
> greatly appreciated.
>
> Another side note, I was noticing that the DOTNETBB
> downloads seemed to have the same issue as our server,
> could they be related?

[ Post a follow-up to this message ]

Posted below are the headers I am writing back.  When I add the Content-Size
header you recommended the downloads lose the ability to monitor the status.
Before it would show the download progress now it doesn't.  Also, the "file
size returned" error is only happening when they try to install the
downloaded *.exe files and most of them are dial-up accounts.  I have the
timeout range set to 4 hours but I am going to up it to 6 and the
response.buffer is now set to false in the code behind file.  I will continu
e
to monitor customer feedback, but so far it looks the same.

HttpContext.Current.Response.StatusCode = 206
HttpContext.Current.Response.StatusDescription = "Partial Content"
HttpContext.Current.Response.AppendHeader( "Content-Range", "bytes " &
StartPos & "-" & EndPos & "/" & FileSize )
HttpContext.Current.Response.AppendHeader( "Content-Length", ContentLength )
HttpContext.Current.Response.ContentType = "application/octet-stream"
HttpContext.Current.Response.AppendHeader( "Content-Disposition",
"attachment; filename=" & myFileInfo.Name )



"Egbert Nierop (MVP for IIS)" wrote:

>
> "DanTheMan" <DanTheMan@discussions.microsoft.com> wrote in message
> news:8FAE6F9F-0E30-4192-A7D1-AE766DCCF8D1@microsoft.com... 
>
> At first, you should set the Server.TimeOut setting sufficiently for a big
> download.
> Second, disable buffering, since this will eat your RAM totally.
> Response.AppendHeader("Content-Size", file.Length.ToString()); will fix th
e
> download size measurement (client-side)...
>
> About chunking. You don't need to worry about that... But it's a good idea
> to have a loop
> while (Request.IsClientConnected())
> {
> // write blocks of 4096 bytes (eg)
> }
>
> --
> compatible web farm Session replacement for Asp and Asp.Net
> http://www.nieropwebconsult.nl/asp_session_manager.htm
> 
>
>

[ Post a follow-up to this message ]

"dan@pccrafter.com" <dan@pccrafter.com@discussions.microsoft.com> wrote in
message news:4988E0A4-2DAB-457B-8B34-E1B30A9D6E08@microsoft.com...
> Posted below are the headers I am writing back.  When I add the
> Content-Size
> header you recommended the downloads lose the ability to monitor the
> status.
> Before it would show the download progress now it doesn't.  Also, the
> "file
> size returned" error is only happening when they try to install the
> downloaded *.exe files and most of them are dial-up accounts.  I have the
> timeout range set to 4 hours but I am going to up it to 6 and the
> response.buffer is now set to false in the code behind file.  I will
> continue
> to monitor customer feedback, but so far it looks the same.

Sorry, it should have been content-length indeed.
But I believe that the timeout is the cause of it. In addition
Response.IsClientConnected makes your script clean up nicely after a
disconnect.
[vbcol=seagreen]
> HttpContext.Current.Response.StatusCode = 206
> HttpContext.Current.Response.StatusDescription = "Partial Content"
> HttpContext.Current.Response.AppendHeader( "Content-Range", "bytes " &
> StartPos & "-" & EndPos & "/" & FileSize )
> HttpContext.Current.Response.AppendHeader( "Content-Length",
> ContentLength )
> HttpContext.Current.Response.ContentType = "application/octet-stream"
> HttpContext.Current.Response.AppendHeader( "Content-Disposition",
> "attachment; filename=" & myFileInfo.Name )
>
>
>
> "Egbert Nierop (MVP for IIS)" wrote:
> 

[ Post a follow-up to this message ]

Hi,

In my Try-Catch Blocks I am able to get the following error.

12/28/2004 5:14:33 PM
Thread was being aborted.
System.Web
at System.Web.UnsafeNativeMethods.EcbFlushCore(IntPtr pECB, Byte[]
status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32
numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLength
s, Int32
doneWithSession, Int32 finalStatus, Int32 kernelCache, Int32 async,
ISAPIAsyncCompletionCallback asyncCompletionCallback)
at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[]
status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32
numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLength
s, Int32
doneWithSession, Int32 finalStatus, Boolean& async)
at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean
isFinal)
at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush)
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpWriter.WriteFile(String filename, Int64 offset, Int64
size)
at System.Web.HttpResponse.WriteFile(String filename, Int64 offset, Int64
size)
at ClubDownload.DownloadFile.getFile(String FilePath, String ContentType)
in C:\Webs\Mirror2 Server\mirror2.pccrafter.com\bin\ClubDownload.vb:line 140
EcbFlushCore

Does this shed any light on the situation?  I upgraded the code that I use
for downloading over the weekend, however, not all the download problems are
gone.  Our customers are becoming very angry because of the switch from
server 2000 to server 2003.

"Egbert Nierop (MVP for IIS)" wrote:

> "dan@pccrafter.com" <dan@pccrafter.com@discussions.microsoft.com> wrote in
> message news:4988E0A4-2DAB-457B-8B34-E1B30A9D6E08@microsoft.com... 
>
> Sorry, it should have been content-length indeed.
> But I believe that the timeout is the cause of it. In addition
> Response.IsClientConnected makes your script clean up nicely after a
> disconnect.
> 
>
>

[ Post a follow-up to this message ]