by : I got up my nerve to compile my first Linux kernel and came across the the special patch for compatibility with PC/TCP by
: FTP corp. The Net Howto did not elaborate much on this. What was the problem and does it only occur with certain versions
: of the PC/TCP software? We have this software package running on lots of PC's at our site. We also have a competing
: package running from Ipswitch which is composed of many ex-FTP people and may have similiar techniques in their code. What
: was the problem? How is it invoked. What symptoms do I need look for? I didn't understand the config question until
: researching it afterwards. I eventually will make a new kernel but for the time being I'm using one that makes me nervous.
: Thanks in advance,
: Dave
There's a bug in Linux that's invoked by certain TCP/IP implementations.
The Linux PC/TCP compatiability configuration option activates a workaround.
From personal experience, the TCP/IP implementations that invoke this bug
include the DOS TCP/IP software from FTP Software and Cisco routers. I
don't recall seeing any problem with the newer OnNet software from FTP,
but that doesn't mean it isn't there.
Consider two hosts: host A is a host running TCP/IP software that invokes
the Linux bug and host B is a Linux machine.
From the user's point of view, the problem is that sometimes a TCP connection
(telnet, ftp, or whatever) will "hang" in the sense that Linux will no longer
send any data on that connection. Closer investigation shows that data is
still flowing from host A to host B, but data going from host B to host A is
just piling up on host B.
To understand what's really going on you have to know a bit about the TCP
protocol, specifically the TCP window size. The TCP window size is an
integer stored in all TCP packets that is used for flow control. When one
end of the TCP connection sends a packet, it always includes the current
window size which tells the receiver of the packet how much data it can send
right now. There are a bunch of rules controlling how the window size is
used to ensure efficient, orderly data flow in a variety of circumstances.
When a TCP connection is established, Linux determines the maximum window
size (also called maximum segment size, I believe) of the other end and uses
that to determine buffer sizes. When an application has data to send, Linux
breaks that data up into buffers no larger than the maximum window size. If
the next buffer is larger than the current window size, Linux waits for the
window size to increase to a size at least as large as the buffer. However,
host A isn't required to increase the window size back to the maximum and,
in certain circumstances, it's not desirable for it to do that, so there's
no guarantee that the window size will ever be as big as LInux wants it to
be. Linux should eventually recognize that the window size hasn't increased
and break it's buffer into smaller buffers and send what the window size
currently allows; however, it never does that leading to the symptoms
described above.
The PC/TCP kernel configuration option activates a workaround where Linux
uses buffers that are half the size of the ones it would normally use. I'm
not sure that that guarantees that the above situation won't happen, but it
makes it very much less likely.
Note: I don't claim to be a TCP/IP protocol expert, so a few of my details
might not be quite right, but I think I've mostly got it right.
Rodney