Eric
Tue Nov 18 16:36:57 CST 2003
Hector,
I appreciate the detailed response! It gives us some areas to investigate. I
can say our application is not posting but "getting" from IIS. It is a
remote software installation tool and our client can interpret from, and
install "packages (application installs)" over URL's. Problem has been with
56K dial-up users where the download and install begins, then craps out with
the connection reset error. One thing our client is doing is a direct
installation to the target machine's hard drive, without first copying the
package locally. This means it's installing each EXE, DLL, etc. on the fly.
So we're constantly going back and getting more data from IIS. Whereas IE
will usually download the entire setup executable to a temp location then
install from there, in normal download situations. In my testing, it's like
IIS encounters a larger file, the file temporary gets written to the target
machine then - poof! - connection reset. UNIX works flawlessly.
One othert idbit, I haven't tested over HTTPS, just HTTP...
Thanks again...
"Hector Santos" <nospam@nospam.com> wrote in message
news:%23kpFa3XrDHA.2488@TK2MSFTNGP09.phx.gbl...
> This is happening to everyone. Microsoft has seriously changed something
in
> either IE and/or the socket layer.
>
> Question, when your users install applications via URL, this this mean
data
> is being POSTed to your IIS web server?
>
> If so, that is probably the problem.
>
> If it is the post issue, like it was for us, IE is posting data with 2
> extra bytes (CRLF) in the POST data. This is per the CERN specification
for
> the POST request.
>
> However, if the server is not ready to read/flush these two extra bytes,
> then you will see the connection reset problem arise and it 100%
> intermittent depending on:
>
> a) TCP Window sizing on both ends,
> b) Socket SO_LINGER
> c) lack of TCP half close usage
> d) Transmission speed on both ends, send and receive.
>
> You don't see the problem on the UNIX server box probably because it is
> properly using TCP half close logic and/or it is prepared to flush the 2
> extra POST bytes.
>
> I didn't see the problem when testing on a local machine setup, over a T1
> setup, but I didn't saw it from my home ADSL connection which has a faster
> receive than send.
>
> We had the same problem with our Wildcat! Web Server. I read about TCP
Half
> Close logic and it fixed the problem. But it didn't explain why I was
> seeing the mysterious 2 extra bytes in the receive queue flushing which is
> part of the Half Close logic. Once I found out about the POST command 2
> extra bytes requirement, it explained why the Half CLose was working by
> flushing the remaining data in the socket. By also adding the server
logic
> to read in the 2 extra bytes as part of the POST data, it also fixed the
> problem.
>
> See the following links describing how the Apache server fixed the
problem:
>
>
http://httpd.apache.org/docs/misc/known_client_problems.html
>
> Read the first item in the above link
>
> and I just found this from Microsoft in their description of the TCP/IP
> problem, but in regards to SSL 3.0. I don't think it is SSL specific. It
> is across the board.
>
>
http://support.microsoft.com/?kbid=305217
>
> Good Luck
>
> --
> Hector Santos
> WINSERVER "Wildcat! Interactive Net Server"
> support:
http://www.winserver.com
> sales:
http://www.santronics.com
>
>
>
>
>
>
> "Eric" <ericpfishfever@hotmail.com> wrote in message
> news:dwbub.1080$Re.1068065@newshog.newsread.com...
> > I'm looking for a suggestion on how to best monitor and log a given IIS
> > session, ideally in verbose mode. We have an app that allows users to
> > install application via URL's. Problem is when the application is hosted
> on
> > IIS, our debug log on the client shows "connection to the server was
> reset"
> > when accessing this large file via dial-up. I'm pinning this on IIS
> because
> > the same installation over dial-up works when the download is hosted on
> > UNIX.
> >
> > Perhaps our problem is related to a setting within IIS or with our ISP?
I
> > don't understand why UNIX works, however.
> >
> >
>