Oswald Buddenhagen wrote: > On Wed, May 05, 2010 at 03:09:20PM -0700, Mark Crispin wrote: > >> On Wed, 5 May 2010, UCTC Sysadmin wrote: >> >>> If they can understand the difference between TCP and UDP, they can >>> understand state. >>> >> I wouldn't be so certain. If you look at a lot of applications these >> days, they blat out a query, and read an answer. If they don't get an >> answer in what they consider to be a suitable time, they drop the >> connection and try again. >> Well, that's not paying attention to what protocol (TCP) they're using, or the protocol (IMAP) needs an adjustment perhaps (I don't know what the protocol is, so forgive me) for an out-of-band inquiry, as in "are you still alive?" Or if they were (able) to send another message down the pipe, saying "forget it and goodbye" so that at least the IMAP client knows to go away immediately. My IMAP jams and I have to kill processes to free it up, if I do work from home and then return to office processes which have been idle for many hours or over a weekend, the mail reader (Thunderbird in my case) seems to return a "nothing new" from the processes despite having changed the folder contents at home. If it's Thunderbird's problem, I can't fix it from Thunderbird, although I haven't killed TB to try that hypothesis (duh.)
Naively, "how hard could it be to rewrite IMAP handling in Thunderbird?" Doesn't seem like a massive project, overall. From what I "hear" here I estimate the protocol should be smart enough for me as a client to asynchronously clear, reset or signal a connection to the IMAP client. If that's not true, it requires bookkeeping on the client side to know whether a wait was anomalous, and if the same client can't be talked to during a "long local file operation", I wouldn't so quickly blame TB. The user never considers how long things might take on the server, though I've learned to be patient to let big moves finish. Sometimes I never get an "ACK" for operation done (large move seems stuck) and have to kill or retry something to resync TB to the server's actual state. Doing stupid things to obtain certainty (in real time for the user) is expedient; were the people who wrote TB that clueless? If IMAP provides the right feedback hooks, the TB authors should have availed themselves of them to manage remote processes more smartly. I had looked for a timeout flag for the IMAP client in inetd to set a timeout for an idle connection, is there one? I'd've been using it by now if there were, so I think the answer is no. >> Put another way, they treat TCP just like UDP, only with this strange and >> annoying "connection" stuff that they don't understand why it's there. >> >> That's "not understanding the difference between TCP and UDP." Tell them they're "misusing the IP API" and they might get it. Didn't they ever wonder why the network calls and handling were different if the protocols "were the same"? > you may rail about the stupidity of those developers as much as you > want. apparently unlike you, they live in the real world where the only > guarantee which tcp provides is that the data stream is intact - *if* it > arrives. timeouts as a workaround for shortcomings of the tcp/ip stack > under real-world conditions are a perfectly reasonable approach, just > like keep-alive signals in higher-level stateful protocols to prevent > timeouts. if you want to do better, you can use imap directly over ATM > or ISDN or other really stateful protocols. but even these sometimes > just go deaf, because they run with crappy real-world system software, > too. > _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
