Hi guys,
I've moved this discussion to the ha-dev mailing list. Somewhere a
while back, we needed to do this, but I forgot (and was kind of behind
on email).
Horms wrote:
>
> On Tue, Apr 11, 2000 at 05:07:56PM -0600, Alan Robertson wrote:
> > Horms wrote:
> > >
> > > On Tue, Apr 11, 2000 at 09:59:00AM -0300, Luis Claudio R. Goncalves wrote:
> > > > Hello!
> > > >
> > > > > > It sounds good. There's any special reason for the sequence number?
> > > > >
> > > > > I only put that in to help keep track of the potential for lost packets.
> >
> > Lost packets are already taken care of. They get retransmitted.
>
> Excellent, that makes our job so much easier.
That's what I asked Luis and Marcelo to make sure they tested well after
their last round of changes. Some impinged on this area.
Please note though that it does NOT guarantee that packets arrive in
order. If you need to break up a request into several packets, for size
or some other reason, you may need to put "local" sequence numbers on
the request, and/or request IDs to deal with this, BUT, you won't have
to do retransmission.
One thing that *can* happen to you, is that a machine can go down in the
middle of a transaction, and that you need to note that, and deal with
it accordingly.
If your code survives a high packet-loss rate of 30-50% with it's sanity
(but not necessarily it's full functionality) for a long period of time,
then it's probably pretty good.
I think I'd put out what you have on Friday as 0.4.7a. Go ahead and add
your names to the AUTHORS file, and add your entries to the changelog in
the Specfile. Add some examples to the sample config file. Tell Rudy
what you did, and what changes it makes for the users. Let's plan on
releasing your version as 0.4.7a on Friday, and after Rudy gets a look
at it, and puts in his changes, and people have had a chance to try it
out, we'll call that version 0.5. OK?
So, you can put your ChangeLog entries in the code, and call it 0.5 BETA
series.
After this, I'd like to see the a version that dealt with the cluster
partition/rejoin problem to come out in the near future.
The protocol can detect this (but doesn't) pretty easily by looking at
the sequence number of the packets that arrive as it decides that a
machine that was dead but is now alive. If they are low, then it's a
protocol restart, and there's not been a cluster partition. If they're
high, then there's been a partition, and it's now rejoined.
I don't have the code in front of me, but that's the general idea. I
actually think there's a branch of code in the protocol area where it
realizes this has happened, but doesn't call it a "cluster partition".
But, if you look at the code, I think you'll see where I'm talking
about. Maybe I should go in and put in comments to that effect :-)
Thanks Guys!
-- Alan Robertson
alanr@suse.com
I've moved this discussion to the ha-dev mailing list. Somewhere a
while back, we needed to do this, but I forgot (and was kind of behind
on email).
Horms wrote:
>
> On Tue, Apr 11, 2000 at 05:07:56PM -0600, Alan Robertson wrote:
> > Horms wrote:
> > >
> > > On Tue, Apr 11, 2000 at 09:59:00AM -0300, Luis Claudio R. Goncalves wrote:
> > > > Hello!
> > > >
> > > > > > It sounds good. There's any special reason for the sequence number?
> > > > >
> > > > > I only put that in to help keep track of the potential for lost packets.
> >
> > Lost packets are already taken care of. They get retransmitted.
>
> Excellent, that makes our job so much easier.
That's what I asked Luis and Marcelo to make sure they tested well after
their last round of changes. Some impinged on this area.
Please note though that it does NOT guarantee that packets arrive in
order. If you need to break up a request into several packets, for size
or some other reason, you may need to put "local" sequence numbers on
the request, and/or request IDs to deal with this, BUT, you won't have
to do retransmission.
One thing that *can* happen to you, is that a machine can go down in the
middle of a transaction, and that you need to note that, and deal with
it accordingly.
If your code survives a high packet-loss rate of 30-50% with it's sanity
(but not necessarily it's full functionality) for a long period of time,
then it's probably pretty good.
I think I'd put out what you have on Friday as 0.4.7a. Go ahead and add
your names to the AUTHORS file, and add your entries to the changelog in
the Specfile. Add some examples to the sample config file. Tell Rudy
what you did, and what changes it makes for the users. Let's plan on
releasing your version as 0.4.7a on Friday, and after Rudy gets a look
at it, and puts in his changes, and people have had a chance to try it
out, we'll call that version 0.5. OK?
So, you can put your ChangeLog entries in the code, and call it 0.5 BETA
series.
After this, I'd like to see the a version that dealt with the cluster
partition/rejoin problem to come out in the near future.
The protocol can detect this (but doesn't) pretty easily by looking at
the sequence number of the packets that arrive as it decides that a
machine that was dead but is now alive. If they are low, then it's a
protocol restart, and there's not been a cluster partition. If they're
high, then there's been a partition, and it's now rejoined.
I don't have the code in front of me, but that's the general idea. I
actually think there's a branch of code in the protocol area where it
realizes this has happened, but doesn't call it a "cluster partition".
But, if you look at the code, I think you'll see where I'm talking
about. Maybe I should go in and put in comments to that effect :-)
Thanks Guys!
-- Alan Robertson
alanr@suse.com