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 que
On 06/05/10 09:22 +0200, 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 ap
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
On Thu, 2010-05-06 at 03:19 -0500, Dan White wrote:
> And what do you do if the server takes longer that you think it should to
> respond to a query? Do you assume that it's a networking issue or a slow
> server?
Instead of fighting clients with this, I solved it by having server send
* OK Hang
On Thu, 6 May 2010, Timo Sirainen wrote:
Instead of fighting clients with this, I solved it by having server send
* OK Hang in there..
about every 15 seconds during long running commands. Clients seem to be
happy with it and not disconnect.
Unfortunately, the mobile device guys and gals then ge
On Thu, 2010-05-06 at 11:19 -0700, Mark Crispin wrote:
> On Thu, 6 May 2010, Timo Sirainen wrote:
> > Instead of fighting clients with this, I solved it by having server send
> > * OK Hang in there..
> > about every 15 seconds during long running commands. Clients seem to be
> > happy with it and n
On Thu, 6 May 2010, Timo Sirainen wrote:
I think that's a different issue. They're unhappy when an idling device
gets woken up (constantly). The "Hang in there" messages are sent only
when client has requested some command that takes >15 seconds. Most of
the users/clients never see those messages
On Thu, May 06, 2010 at 11:46:20AM -0700, Mark Crispin wrote:
> On Thu, 6 May 2010, Timo Sirainen wrote:
> >I think that's a different issue. They're unhappy when an idling device
> >gets woken up (constantly). The "Hang in there" messages are sent only
> >when client has requested some command tha
On Thu, 6 May 2010, Dan White wrote:
And what do you do if the server takes longer that you think it should to
respond to a query? Do you assume that it's a networking issue or a slow
server?
Crapware assumes that it is a network issue that somehow is utterly
irrecoverable in TCP, yet magically
On Thu, 6 May 2010, Oswald Buddenhagen wrote:
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.
"Mr. Newton, your notions a
On Thu, May 06, 2010 at 01:24:00PM -0700, Mark Crispin wrote:
> Crapware assumes that it is a network issue that somehow is utterly
> irrecoverable in TCP, yet magically goes away if you tear down the TCP
> connection and establish a new one.
>
hmmm ... why might they do such an obviously nonsensi
On Thu, May 06, 2010 at 02:42:24PM -0700, Mark Crispin wrote:
> On Thu, 6 May 2010, Oswald Buddenhagen wrote:
> >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
On 06/05/10 23:46 +0200, Oswald Buddenhagen wrote:
funny, how establishing some reasonable common guidelines for handling
loss of state in the standard could alleviate these problems to a
significant degree. unfortunately, the creator doesn't even acknowledge
the problem. oh, well. tough luck, i
On Fri, 7 May 2010, Oswald Buddenhagen wrote:
i'll be way more impressed when you actually propose something that
works on a large scale instead of insisting on your idealized worldview
and insulting the intelligence of everyone who tries to solve very real
problems.
Problems are not solved by
On Thu, May 06, 2010 at 05:34:35PM -0500, Dan White wrote:
> loss of tcp connection != loss of state.
>
loss of the state we are talking about here. it's all based on mark's
postulation that a tcp connection is reliable.
> In my own review of several IMAP RFCs, it's clear that connection problems
On Thu, 6 May 2010, Dan White wrote:
loss of tcp connection != loss of state.
Correct. There's a further equation:
loss of network connectivity != loss of TCP session != loss of state
There is no reason to lose a TCP session because of a short-term loss of
network connectivity.
Although it
On Thu, May 06, 2010 at 03:20:06PM -0700, Mark Crispin wrote:
> On Thu, 6 May 2010, Oswald Buddenhagen wrote:
> >ever heard about connection-tracking packet filters and routers?
> >ill-tempered transparent proxies?
>
> Tell us all about the connection-tracking packet filters and routers
> that exi
On Fri, 7 May 2010, Oswald Buddenhagen wrote:
loss of the state we are talking about here. it's all based on mark's
postulation that a tcp connection is reliable.
TCP connections are reliable. Run, don't walk, to your nearest technical
bookstore and read about network layering.
Crappy softwar
On May 6 2010, Mark Crispin wrote:
On Fri, 7 May 2010, Oswald Buddenhagen wrote:
loss of the state we are talking about here. it's all based on mark's
postulation that a tcp connection is reliable.
TCP connections are reliable. Run, don't walk, to your nearest technical
bookstore and read ab
On Fri, 7 May 2010, Oswald Buddenhagen wrote:
who cares what existed back then? we are talking about *today*. but you
are still arguing as if the internet looked the same as 25 years ago.
"Who cares about anything from the past? There is nothing to be learned
from past experience, and nothing
On Thu, 6 May 2010, Brian Hayden wrote:
TCP connections are more reliable than UDP; that does not mean they are
"reliable", full stop.
You are using the wrong definition of reliable.
Reliable does not mean "does not fail".
UDP has no provision for reliability, ordering or data integrity. TCP
On May 6 2010, Mark Crispin wrote:
Reliable does not mean "does not fail".
Coincidentally, nobody said it did. Interesting!
This is another fun historical dissertation, at whose core is: "change the
RFCs, and until then maintain some righteous anger."
What you think of as being "failure"
On Thu, 6 May 2010, Brian Hayden wrote:
Reliable does not mean "does not fail".
Coincidentally, nobody said it did. Interesting!
If that was not your meaning in claiming that "TCP is not reliable", then
you don't know what you are talking about.
TCP is most certainly reliable.
This is anoth
On May 6 2010, Mark Crispin wrote:
I go to the trouble to teach you how things actually work, and you respond
with a typical nihilistic Gen-X retort.
Was that what you said, or was it not? It quite clearly was, so the retort
was typically nothing (particularly indicative of a generation to wh
I run IMAP4rev1 2007a.403 on RHEL 5, from xinetd. I find imapd
processes running under uid root that hang around indefinitely and
gradually accumulate on the mail server. netstat shows that these are
connected to known client addresses, and this is verified by log records
showing the initial con
25 matches
Mail list logo
