Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Rodney Thayer wrote in a message to Mike Bilow: >POP is inherently message granular. Why bother with keepalive? RT> because when the intervening internet, or the ISP, or the RT> machine at the client end decided to go into an RT> inappropriately quiescient state you get some kicks that RT> have a chance of getting it out of that state. RT> obviously this depends on what the code does in keepalive RT> processing (for example, is it smart enough to react to a RT> returning "port unreachable" icmp message) RT> Trust me, it would be more preferrable than what I do to the RT> poor support people at my ISP when POP3 decides to hose up RT> in my face (right, Rich?) Handling ICMP Port Unreachable is a difficult issue under any circumstances, since this can often result from catastrophic failure to which adding lots of traffic is not helpful. In any case, it seems to me that the best situation for POP3 would be to have the TCP circuit expire normally via timeout if one end just dies. "Kick" implies that the sender has gone into excessive backoff rather than died, and TCP/IP assumes that such situations are indicative of congestion rather than unreliability. In fact, TCP/IP presumes that it is operating above some kind of link and physical layers which are sufficiently relaible to support the datagram nature of IP. There is no point to kicking the receiver rather than the sender, since the receiver will send TCP ACK frames quite promptly after a very short delay. It is considered evil to compensate for unreliability below the IP layer by making backoff more aggressive, the Internet equivalent of running a red light. -- Mike
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |