Re: [Pan-users] Re: Pan 0.120 only queuing tasks

[Per Hedeland]

Duncan <address@hidden> wrote:
>
>AFAIK from the last time this came up and from discussion by non-pan 
>users at my ISP (Cox, now outsourcing from highwinds-media, which /
>sucks!), it's not just a pan problem, but has to do with "lossy" 
>connections.  TCP (which underlies NNTP) simply doesn't work very well 
>with lost packets because it either interprets them as congestion and 
>slows down in the one case, or causes lost ACKs and thus "zombie 
>connection" syndrome.  The latter is generally the problem in the case at 
>hand.  If it's what I think it is, pan has sent ACKs for packets it has 
>received, saying it received them, send more (or maybe retransmit 
>requests if it didn't receive them), only the server never got the ACKs, 
>and having filled the allowed RcvWin without getting the ACKs saying 
>those are processed and allowing it to continue, it can't send more.

Uh, I dare say the Internet would have been somewhat less of a success
if TCP was indeed as fragile as you make it out to be. Remember, this
stuff was designed to survive direct hits with nuclear weapons...:-) TCP
does indeed not work well with persistent packet loss - that is to say,
performance goes down the drain, but if at all possible, the bits do
eventually arrive where they're supposed to. Of course ACKs are
retransmitted as needed just like everything else, i.e. the "zombie
connection syndrome" that you describe simply cannot happen if the
communication path still exists, and packets at least "occasionally" get
through. There has been some pathological cases where the communication
path goes away (modem drops connection, computer is powered-off without
proper shutdown) at exactly the wrong moment, but I believe a TCP/IP
stack that doesn't handle those would be considered buggy today.

>So both ends are waiting on the other to act, as the connection handshake 
>and control element got broken.  Hitting stop allows pan to process the 
>partial data it has.  Unfortunately, while pan will start the connection 
>terminate process, sometimes that gets hung as well.  Sometimes a pan 
>restart is necessary, and if the thing is /really/ screwed up, the kernel 
>may not be able to finish closing some of those connections until it 
>times them out.  (In the worst-case, I believe they can hang around for 
>24 hours. =8^(  )  One may then need to reboot to get them gone, if one 
>isn't patient enough to wait for it to happen on its own.

I'm afraid I have no idea what you're talking about here - there are
some "long-lived" states in the TCP logic, mostly having to do with the
need to make sure that packets from an old connection don't interfere
with a new one. But the time limit on those (notably TIME_WAIT) is on
the order of two minutes. Of course if an application doesn't close a
connection when the other end has signaled a close (the connection is
then in the CLOSE_WAIT state), the connection stays open, since TCP
allows "half-closed" connections - i.e. it's possible for that
application to still receive packets, but as soon as it does close the
connection (or exit, which is an implicit close), that connection is
gone.

--Per Hedeland
address@hidden