-> Multiple implementations
by "Dave Collier-Brown"
-> Re: Multiple implementations
by chris@kosh.punk.net (Christopher Ambler)
-> Re: Multiple implementations
by Michael Dillon
-> Re: Multiple implementations
by chris@kosh.punk.net (Christopher Ambler)
-> Re: Multiple implementations
by "Richard J. Sexton"
-> Re: Multiple implementations
by Michael Dillon
-> Re: Multiple implementations
by chris@kosh.punk.net (Christopher Ambler)
----------------------------------------------------------------------
Date: 28 Aug 1996 11:31:56 -0700
From: Kent Crispin
Subject: Re: Modelling the Process
Dave Collier-Brown allegedly said:
> Well, it's time t ocomment on requirements next (as I promised
> all too many moons ago). This is the partially-proofread example
>
> As with the appreciation, I'll upload it to a web site presently.
> --dave
> --
> David Collier-Brown, | Always do right. This will gratify some people
> 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
> Willowdale, Ontario | davecb@hobbes.ss.org, unicaat.yorku.ca
> N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
[900 lines of html deleted]
Dave, it was a little hard to read, until I went to your web site.
The technique and notation you used for modelling state transitions
was quite interesting.
I thought the level of generality you used was too high (in general
:-). In particular, I think that that the CDB (regardless of whether
it is implemented in a special purpose database or DNS) would only
contain (C,d,R) triples (probably some more data too, but at an
abstract level...). All the changes would be, then, something like this:
So, in my view, the only legal transitions would be:
C,d,R -> (C,d,R)
(C,d,R) -> (C,d,R')
(C,d,R) -> C,d,R, and
possibly (C,d,R) -> (C',d,R)
Now, possibly I see it this way, because I am thinking that the
database will actually be imbedded in DNS.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 28 Aug 1996 18:46:24 -0700
From: "Dave Collier-Brown"
Subject: Re: Modelling the Process
Kent Crispin saith:
|Dave, it was a little hard to read, until I went to your web site.
|The technique and notation you used for modelling state transitions
|was quite interesting.
|
|I thought the level of generality you used was too high (in general
|:-). In particular, I think that that the CDB (regardless of whether
|it is implemented in a special purpose database or DNS) would only
|contain (C,d,R) triples (probably some more data too, but at an
|abstract level...). All the changes would be, then, something like this:
|
|So, in my view, the only legal transitions would be:
|
|C,d,R -> (C,d,R)
|(C,d,R) -> (C,d,R')
|(C,d,R) -> C,d,R, and
|possibly (C,d,R) -> (C',d,R)
|
|Now, possibly I see it this way, because I am thinking that the
|database will actually be imbedded in DNS.
Yes, that's substantially what you'd hope to have at the end.
The diagram I drew was a prototype TTM (Timed Transition Model),
which explicitly represents transitions to ``illegal' 'states.
These are used to put bounds on the action that puts the model
back into a legal state, and in this case to illustrate all the
possible states so we could decide which were errors and would need
to be fixed.
The odd states usually have names like ``decending'' or ``travelling''
or ``approaching'' (from a train and crossing-gate example), and
represent things which necessarily happen, but which you'd prefer
to take zero time... except they refuse to do so. So you design
so that
a) the time is bounded, and that some thing is done
beforehand so that nothing bad can occur in that
time period, or
b) the peculiar state is self-curing, or
c) the state can't effect anyone.
A time-bounded example might be ``before returning YES and
allocating a domain name, start a timer that will return the
name to the pool if you don't have 2 NS records and a whois file
by the time it goes off''.
A self-curing state might be ``the NS records of the domain
are removed from the DNS on entering the (C,d) R state''. Some
element outside the model will tend to drive **that** one back to the
desired state!
A state that can't affect anyone is harder to think up. I might
claim (C,R) d is such, on the ground that it just leads to (C',R',d)
but that's stretching the arguement.
Anyway, your analysis is correct: there should only be very
few legal transitions, and all the others should either be rendered
impossible or coerced into legal ones.
If it weren't simple, full-scale examples which have a complete TTM
for each physical component would be unmanageable. Ours might have
a second TTM which showed what records became visible/invisible
to the world, but I didn't feel like trying to draw it until I
understood the first picture fully!
- --dave
- --
The text for this is Jonathan Ostroff, ``Temporal Logic for Real-Time
Systems'', Taunton, Somerset (Research Studies Press / John Wiley),
1989, ISBN 0-471-92402-4. I understand he has a newer one in draft.
This was for a grad course, which I found exceedingly difficult. He's
now teaching it to undergrads, which says impressive things about my
younger colleagues!
- --
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | astonish the rest. -- Mark Twain
Willowdale, Ontario | davecb@hobbes.ss.org, unicaat.yorku.ca
N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
----------------------------------------------------------------------
Date: 28 Aug 1996 19:31:43 -0700
From: "Dave Collier-Brown"
Subject: Multiple implementations
To go along with the web-page and all-dns prototypes proposed, I
did mock up the server and client programs in C with my daemon kit.
They do absolutely nothing real, but will be easy to experiment
with when we get down to brass tacks.
But I lied: it took me two evenings because I broke my apraNaut kit
while trying to do timeouts properly.
Here's an actual run of the fake-a-type:
hobbes:/home/davecb/projects/active/sdmp/src> sdmpd
220 sdmpd server on hobbes.ss.org ready at 28 Aug 96 22:20:09 EDT
hello davecb@hobbes.ss.org
320 challenge xyzzy
authorize gb25nhsl;
250 OK
help
250-Shared/Simple Domain Management Protocol server.
250-Supported commands are:
250- HELLO registry
250- AUTHORIZE reply
250- REGISTER domain
250- UPDATE domain
250- RELEASE domain
250- UNREGISTER domain
250- REREGISTER domain
250- NAMESERVER name [address]
250- CONTACTS
250- NOOP
250- HELP
250 QUIT
register grurr.shared
250 OK
nameserver ns1.gnurr.shared 142.77.1.22
250 OK
nameservr ns2.gnurr.shared 142.77.1.23
550-Unexpected command "nameservr ns2.gnurr.shared 142.77.1.23"
550 expected one of quit noop help nameserver contacts
nameserver ns2.gnurr.shared 142.77.1.23
250 OK
contacts
350 Send contact information, terminated with .
hi
ho
hum
.
250 OK
noop
250 Ok, did nothing
quit
hobbes:/home/davecb/projects/active/sdmp/src>
- --dave
----------------------------------------------------------------------
Date: 28 Aug 1996 19:37:37 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: Multiple implementations
Blindingly stupid question, I admit: what is the problem with having
a central database running an SQL server and all shared registries
using an ODBC-driven front end? Too bulky?
I ask not as a serious consideration, but to find out what the common
feeling is as to why *not* to use this strategy. Humour me. :-)
Christopher Ambler
President, Image Online Design, Inc.
----------------------------------------------------------------------
Date: 28 Aug 1996 19:51:51 -0700
From: Michael Dillon
Subject: Re: Multiple implementations
On Wed, 28 Aug 1996, Christopher Ambler wrote:
> Blindingly stupid question, I admit: what is the problem with having
> a central database running an SQL server and all shared registries
> using an ODBC-driven front end? Too bulky?
Yes. SQL is pretty bulky to begin with and was never designed for this
kind of transaction oriented stuff. ODBC just makes it worse.
That's why I favor using a CGI based transaction protocol that just
requires HTTP POST transactions from the client. And an email form based
protocol for non 7/24 conected sites.
> I ask not as a serious consideration, but to find out what the common
> feeling is as to why *not* to use this strategy. Humour me. :-)
Some of us started programming relational database applications almost
twenty years ago ( or more ) so we know it can be done without the
incredibly complex multilayer stuff that is being flogged in PC Magazine
these days.
I was quite serious when I said that a moderate sized registry could be
run on an MAI Basic 4 minicomputer of late 1970's vintage with its serial
ports hooked up to a terminal server in order to provide Internet
connectivity.
Of course I wouldn't do it that way with cheap Pentiums and FreeBSD or
SCO UNIX readily available.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 28 Aug 1996 20:02:43 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: Multiple implementations
>Yes. SQL is pretty bulky to begin with and was never designed for this
>kind of transaction oriented stuff. ODBC just makes it worse.
Okay, that's what I thought. What brought this up is that we've based
our .WEB registry on Microsoft SQL Server 6.5, and made all the
in-house interfaces out of an ODBC front end. It works very well
for us, and supports thousands of queries a minute, as well as a nice
locking strategy for multiple people doing database additions/changes
while offering a very workable interface to the web.
In putting it all together, however, I'm very convinced that it's a
solution for a single registry, but would start to overburden a
shared model. Not coming from a database background (I've been doing
protocols for the last 12 years), this was a learning experience.
Christopher Ambler
President, Image Online Design, Inc.
----------------------------------------------------------------------
Date: 28 Aug 1996 20:15:55 -0700
From: "Richard J. Sexton"
Subject: Re: Multiple implementations
Wadda ya mean "bulky".
mSQL appears to be fairly resonable.
----------------------------------------------------------------------
Date: 28 Aug 1996 20:19:16 -0700
From: Michael Dillon
Subject: Re: Multiple implementations
On Wed, 28 Aug 1996, Christopher Ambler wrote:
> Okay, that's what I thought. What brought this up is that we've based
> our .WEB registry on Microsoft SQL Server 6.5, and made all the
> in-house interfaces out of an ODBC front end. It works very well
> for us, and supports thousands of queries a minute, as well as a nice
> locking strategy for multiple people doing database additions/changes
All relational databases do that.
> while offering a very workable interface to the web.
And this is pretty easy to do with PERL scripts on any platform with any
database.
> In putting it all together, however, I'm very convinced that it's a
> solution for a single registry, but would start to overburden a
> shared model. Not coming from a database background (I've been doing
> protocols for the last 12 years), this was a learning experience.
People doing large quantities of transactions against a database usually
go for a product like Oracle, Informix or Progress running on a UNIX
server. These systems can scale up to size huge just by running on an SMP
UNIX system and adding CPU's and RAM. And because they are heavy duty
commercial products they should all provide a way to easily maintain a
fallback mirrored system although you may have to do a little scripting to
tie it all together.
Nevertheless, hardware has gotten powerful enough that even stuff from the
GUI environments can usually handle a moderately large load of
well-defined transactions such as the shared TLD scenario.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 28 Aug 1996 20:25:03 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: Multiple implementations
>People doing large quantities of transactions against a database usually
>go for a product like Oracle, Informix or Progress running on a UNIX
>server. These systems can scale up to size huge just by running on an SMP
>UNIX system and adding CPU's and RAM. And because they are heavy duty
>commercial products they should all provide a way to easily maintain a
>fallback mirrored system although you may have to do a little scripting to
>tie it all together.
We did initial testing on a Pentium 133 with 32 megs of RAM, and then
moved it to a Pentium 166 with 32 megs of RAM. Not much difference.
Taking it to 64 megs made quite a difference, so we're going to put
it on a dual processor Pentium Pro 200 with 256 megs of RAM and
forget about it. We can take the machine up to 4 processors and a gig
of ram if need be, though I doubt we'll have to.
Okay, enough pontificating on what won't work, let's not lose focus
that we're working on things that *will* work :-)
(but I have to say, I have more respect for people that hack databases
these days)
Christopher Ambler
President, Image Online Design, Inc.
