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

[Duncan]

Per Hedeland <address@hidden> posted
address@hidden, excerpted below, on  Mon,
30 Apr 2007 19:12:02 +0200:

Duncan wrote...

>> If it's what I think it is, pan has sent ACKs for packets

That BTW was a mis-type.  More accurately, it's not the app (pan in our 
case) but the OS TCP/IP stack that will be sending the ACKs in the 
ordinary case, as the app (pan) pulls the packets out of the receive 
buffer thus making room for 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.

Well, you are describing the ideal and properly implemented state.

What I can say is that, regardless of the reason (which might be the 
below at times), in practice, users have to deal with such zombie 
connections from time to time.  It does seem to happen less on good 
connections, and proper implementation has "the world" to do with it as 
well, but it does unfortunately happen in real life to real users.  I 
expect you'll say this is due to bad implementations of the standard, and 
I'll agree, it is, but it still happens, and users that have nothing to 
do with the implementations, good or bad, still have to deal with it.

Actually, if you read my previous post, that was in fact what I was 
saying, that the highwinds software implementation has an end-user 
reputation for being what amounts to a rather poor implementation, with 
all sorts of issues unless it happens to be perfectly tweaked for every 
one of perhaps dozens of factors, or unless it is run way under its rated 
capacity.  (Even a poor implementation run on a few tens of thousands of 
dollars worth of hardware will likely handle a dozen users...)

> 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.

The half-closed state was in fact what I was referring to, with close 
packets being lost in transit, such that one end or the other doesn't 
realize the other is closing the connection (or has successfully closed 
in, in the case of the final ACK, thus keeping a now dead connection open.

There may in fact be other mechanisms at work here as well.  However, 
this one seems to fit the available data.  At least in the Cox/Highwinds-
media case, multiple RESETS jumbled together with continuing packets on 
the connection (sequenced AFTER the RESET, so it's not just late 
packets), have been documented via packet capture in the continuing 
saga.  That sort of stuff should NOT be happening.  If the server has 
sent a reset, it shouldn't continue sending regular packets on the same 
connection.  It should wait, and if necessary send another reset, but it 
shouldn't continue sending ordinary data packets with sequence numbers 
indicating they were sent AFTER the RESET.  That's indicative of a 
seriously screwed up implementation.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman