[42] in Athena_Backup_System
Re: Issues raised at the "High-Level Design" review
daemon@ATHENA.MIT.EDU (Diane Delgado)
Fri Dec 2 18:06:20 1994
To: athena-backup@MIT.EDU
In-Reply-To: Your message of "Fri, 02 Dec 1994 15:54:23 EST."
<199412022054.PAA02996@the-other-woman.MIT.EDU>
Date: Fri, 02 Dec 1994 18:05:56 EST
From: Diane Delgado <delgado@MIT.EDU>
>There were several issues brought up at the design review that took
>place several months ago. The most notable of these issues were our
>plans to use three technologies not developed in I/S. Have we
>addressed all of these issues?
I agree; it's good to review these to be sure that we have everything
understood, since I'd bet someone will undoubtedly raise the same issues.
Feel free to add any more info:
ONC - It's my understanding that (most) people agreed during the
end of the review and after the review that ONC is perfectly
acceptable for us to use.
Concerns about ONC:
1. Source access - Peple felt more at ease if we have this.
We do have source for ONC. I currently have two versions,
the latest and a bsd-based version which is a few years old.
The goal is to use the lastest version on those systems
which support the X/TI interface (X/Open Transport Interface)
(SOLARIS, AIX, ULTRIX). The old sockets based version would
be used if we need to port to something that does not
support this. The versions claim to be interoperable.
2. Documentation - Both versions of ONC come with the following
documentation: man pages, application developer guides, and
a short paper describing the implementation of the new version.
3. Learning Curve - ONC is a fairly simple protocol which is layered
on top of sockets or streams. I've spent a lot of time looking
at the code recently and I didn't find the learning curve to
be high at all. (My experience has been as user of various RPC's with a
small/moderate exposure to RPC internals).
I've been also keeping notes as I've been doing the porting
so anyone who needs to read the ONC code will know what we
had to change.
4. I will leave MIT and no one will know how ONC works - I'm not
planning on leaving soon, and secondly anyone who is on the
implementation team will be highly familiar with ONC from a
development/debugging point of view by time we are through, so
the knowlege will be spreading amongst several people.
5. The technology isn't standard - Well it is a standard, in fact
It's an IETF standard. It's also shipped by almost every unix
vendor. The only minus is that the vendor code isn't usually
kerberized, which is what we will be doing.
Commercial Database
This wasn't decided at the review, but somehow was resolved outside
of the review. I heard rumors about how, but I'm not going to repeat
them. Tim probably can comment more on the conjecture that this
issue has been resolved and that people understand why we are going
this route.
I also note that during the review, those who objected most also
described the public domain databases as "garbage", so no-one has
yet come up with a better alternative.
Threads
This was the only item of the three which was subject to compromise.
One valid objection centered around the use of threads with the
DBMS libraries, and that all DBMS vendors don't support threads
safe client DBMS libraries. So what we've done here is to not
have a fully threaded master server which can handle multiple calls.
The design and implementation will, however, take into account the
fact that we may need to implement full threads support in the
future. Thus we program in a threads-safe fashion, although we
aren't really using threads at this time.
We do use two threads in the Master server, one for all of the main
server work and a second thread which initiates the automated jobs.
This isn't a problem for the following reasons:
1. The scope of the auto job thread is limited and there isn't
expected to be a lot of overlap with other work in the master.
The interaction between the two threads will be limited and
not hairy.
2. The use of threads in this case is very simple and easy to
understand, and it's a good introduction to threads for
the person who will be implementing it.
3. The threads implementation is more elegant than other options
(e.g., signals) and its interaction with other things like the
dbms libraries is more predictable.
To implement automatic job scheduling, what we are really doing
is performing a context switch wherein at a pre-appointed time,
we stop what we are doing and perform a different task which is
the initiation of the automatic jobs, and then resume the previous
task. The simplist way to effect this context switch is via threads,
since it's already done for us by the threads package.
Since the target platform for the master is solaris and solaris
has native threads, we might as well take advatage of them.
I've actually prototyped this and it works.
4. Porting issues - For the Master, it isn't necessary that it run
on all platforms. If we need to migrate there are a few options:
a. use the target vendor's threads, if they exist. It isn't
uncommon for threads to exist so this is a possiblity.
b. Use user-space threads - we have a user space threads package
that we can port to platforms (DCE threads, which is already
ported to rios, hpux, mips).
c. Emulated the functionality someother way with signals
or whatever else is available.
5. Note that the lastest version of the ONC-RPC library has been
made threads safe!
The last threads objection to address is : no one in dcns-dev knows
how to program with threads. This is not true. I've programmed with
threads, and guess what AFS is based on threads, so surely someone
here knows AFS? Thinking about threads while programming will also
introduce some good programming habits, such as using global variables
sparingly which contributes to readability.
