Hi Alan,
> On Sul, 2004-09-12 at 18:29, Wolfpaw - Dale Corse wrote:
> > A fair comment :) But look at it this way:
> >
> > - The TCP RFC was last updated when?
>
> About 2 months ago. The 793 RFC isn't updated instead new
> ones are added for the additional features/discoveries.
My fault there :( Sorry.
> > - What is the average time for a tcp packet to fly even across
> > the world these days? Maybe 300 ms? 1 second? 5?
> > - It is not a secret that the TCP protocol has flaws, take for
> > example the RST bug, which required among other things, BGP4
> > to use MD5 encryption to avoid being potentially attacked.
>
> This is not a TCP flaw, its a combination of poor design by
> certain vendors, poor BGP implementation and a lack of
> understanding of what TCP does and does not do. See IPSec.
> TCP gets stuff from A to B in order and knowing to a
> resonable degree what arrived. TCP does not proide a security service.
>
> (The core of this problem arises because certain people treat
> TCP connection down on the peering session as link down)
Good point :)
> > So this brings me to:
> >
> > A) Why are the timeouts so long?
>
> So you don't get random corruption
Hmm. I'll take your word for it, I'm not quite grasping it,
but you know quite a bit more about it then I do :) I would
have thought once a close is sent, the data has all been received
and/or sent anyway, so what would corrupt?
> > C) Socket still re-uses an FD before it is actually completely
>
> Pardon ?
It _appears_ that when we close a socket (ie with mysql_close) on
the client side, the client side closes the FD properly (though Mysql
doesn't), and then if we call connect (which it does a lot, being a proxy
server) it will reuse that FD. At this point, the Mysql side still hasn't
closed it, and it is sitting in CLOSE_WAIT, where it remains forever, since
it is in use by the client side elsewhere already. Should connect be
checking the "list of not connected, but state other then CLOSED" list
before it decides to use a particular FD? Or is this behavior intentional?
> > sending something to the other side is required, but I can't see why
> > having the other side send something back is part of the protocol.
> > This could be
>
> Because packet sizes are finite and not doing so requires an
> infinite sequence space and thus infinite packet sizes.
> Reread the TCP specifications more carefully, also look at
> RFC1337 which discusses some of the real world cases of
> getting this wrong.
Fair enough, thank you for clarifying it for me :)
Keep up the good work :) (which you do a lot of I might add :)
D.
On Sul, 2004-09-12 at 19:52, Wolfpaw - Dale Corse wrote:
> > > A) Why are the timeouts so long?
> >
> > So you don't get random corruption
>
> Hmm. I'll take your word for it, I'm not quite grasping it,
> but you know quite a bit more about it then I do :) I would
> have thought once a close is sent, the data has all been received
> and/or sent anyway, so what would corrupt?
It has all arrived at least once. However you don't know if a
retransmitted packet took a long trip round the world and popped out
later. When that happens you need to be sure you can tell old and new
apart. The TIME_WAIT state is basically "don't use this identical set of
port/address data for long enough to be sure any prior use has exited
the internet in its entirety.
> It _appears_ that when we close a socket (ie with mysql_close) on
> the client side, the client side closes the FD properly (though Mysql
socket != fd. If you close an fd and open you may get the same fd but
its a different socket. If its getting stuck closing could you have
another copy of the fd left open somewhere or have passed it to a
process you forked (thats a classic nasty to track down error) ?
> doesn't), and then if we call connect (which it does a lot, being a proxy
> server) it will reuse that FD. At this point, the Mysql side still hasn't
> closed it, and it is sitting in CLOSE_WAIT, where it remains forever, since
> it is in use by the client side elsewhere already. Should connect be
> checking the "list of not connected, but state other then CLOSED" list
> before it decides to use a particular FD? Or is this behavior intentional?
Sockets are two way at the TCP layer. "close" really means "have
finished sending". When both ends have finished sending the connection
is complete but not before. Thus if Mysql daemon says "I am done" but
you have open references to the handle then it will stay open one way
still.