Anyone else experiencing trouble connecting various microsoft
www and ftp sites? I put a Sniffer on the line and found that
I have a part of a web page come up and then the connection is
reset.
This is using Netscape Communicator4 on both NT and SPARC
Solaris. If one uses IE3 it works better.
I find this highly suspicious. Also straight ftp from a unix
system
is very slow if you get in at all. I think we can all agree that
the tcp/ip stack on sparc solaris 2.5.1 is not likely broken
(patched
to current level, January '98, just in case) where NT might be
suspect even 4.0 w/service pack 3.
One possible problem I consider is that I have Path MTU discovery
turned on in all my routers interfaces (Bay RS12.10). My path to
microsoft is via Alter.Net . The local Ethernet MTU is 1518 but
the UUNET circuit is 1600. The packets I see come by with "don't
fragment" set for several and then one that does not have DF and
then the TCP reset comes in.
Anyone else experiencing trouble connecting various microsoft www
and ftp sites? I put a Sniffer on the line and found that I have a
part of a web page come up and then the connection is reset. This
is using Netscape Communicator4 on both NT and SPARC Solaris. If one
uses IE3 it works better. I find this highly suspicious. Also
straight ftp from a unix system is very slow if you get in at all. I
think we can all agree that the tcp/ip stack on sparc solaris 2.5.1
is not likely broken (patched to current level, January '98, just in
case) where NT might be suspect even 4.0 w/service pack 3.
This curious behavior was discussed a few months ago on the mailing
list for the TCP implementors mailing list.
The Windows TCP/IP stack appears to use RST to mean "busy, try again".
Unfortunately, no one else does, nor is this behavior needed.
An NT machine (presumably what is running on Microsoft's www and ftp
sites) will issue an RST on an incoming connection when the socket
queue is full. An NT machine acting as a client retries a SYN
responded to by an RST 3 times, separated by a half-second, and only then
gives up.
The proper behavior would be for NT to ignore SYNs when its backlog is
full, and rely upon the client machine to retry the SYN. No other
TCP/IP stack but Microsoft's is going to retry a connection which was
terminated with an RST, so you will likely end up with broken images
on a web page. It's possible that IE3 handles this situation better
than Netscape because, knowing this quirky behavior, it might attempt
to compensate for it by retrying a connection refused a few times.
Anyone else experiencing trouble connecting various microsoft www
and ftp sites? I put a Sniffer on the line and found that I have a
part of a web page come up and then the connection is reset. This
is using Netscape Communicator4 on both NT and SPARC Solaris. If one
uses IE3 it works better. I find this highly suspicious. Also
straight ftp from a unix system is very slow if you get in at all. I
think we can all agree that the tcp/ip stack on sparc solaris 2.5.1
is not likely broken (patched to current level, January '98, just in
case) where NT might be suspect even 4.0 w/service pack 3.
This curious behavior was discussed a few months ago on the mailing
list for the TCP implementors IETF working group.
The Windows TCP/IP stack appears to use RST to mean "busy, try again".
Unfortunately, no one else does, nor is this behavior needed.
An NT machine (presumably what is running on Microsoft's www and ftp
sites) will issue an RST on an incoming connection when the socket
queue is full. An NT machine acting as a client retries a SYN
responded to by an RST 3 times, separated by a half-second, and only then
gives up.
The proper behavior would be for NT to ignore SYNs when its backlog is
full, and rely upon the client machine to retry the SYN. No other
TCP/IP stack but Microsoft's is going to retry a connection which was
terminated with an RST, so you will likely end up with broken images
on a web page. It's possible that IE3 handles this situation better
than Netscape because, knowing this quirky behavior, it might attempt
to compensate for it by retrying a connection refused a few times.