Duncan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
