Skip site navigation (1)Skip section navigation (2)
Date:      15 May 1996 00:14:36 -0500
From:      "Richard Wackerbarth" <rkw@dataplex.net>
To:        "Terry Lambert" <terry@lambert.org>
Cc:        "questions@freebsd.org" <questions@freebsd.org>, "Tony Kimball" <alk@Think.COM>
Subject:   Re(2): why so many ways to stay in sync?
Message-ID:  <n1380003191.78965@Richard Wackerbarth>

next in thread | raw e-mail | index | archive | help
In response to
> >    > Doesn't ctm obsolete sup?

Terry said:

> Sup is a connection per site, whereas CTM can be distributed by
> FTP mirrors.  CTM distribution is closer to usenet because it's
> closer to store-and-foward flood model distribution.
> 
> The problem with store-and-forward is that it is an unreliable
> delivery mechanism; SUP is closer to demand mirroring, and so
> is really more useful.

I think that you are under-rating the utility of "store and forward". As we
all know, the entire internet is based on store and forward of packets. The
primitive delivery mechanism is unreliable.
However, that does not prevent its effective use.

The salvation of unreliable delivery is the ability to detect the non-delivery
and initiate corrective action. With CTM, we have that ability. Out of
sequence updates are not applied, but are held awaiting the earlier ones. This
is much like the TCP window. The recovery mechanism is presently ftp. However,
it could easily be implemented with an ftp by mail service.

The advantage is that the end user does not ever REQUIRE a connection to the
distribution site. It also has the major advantage of giving resource
allocation control to the source of the information rather than to the
destination.

I also think that you need to recognize that the dropped update rate is not at
all very high.

> SUP snapshots tend to be more buildable (in my experience).
This is a "locking" problem on the master source and is related to the lack of
disipline on the part of committers who do not always (often?) make atomic
updates.

> Finally, using SUP seems to let me sync multiple trees easier than CTM.
I don't understand this. There is only one tree. You should be using the
composite tree (CVS). The method of delivery does not affect the usefulness.

> The real problem is that CVS sucks for people with commit privs... it would
be better if there were a method ...

Again, this is a problem with the message and not with the messenger.

The big advantage that I see to the sup scheme is that it provides a mechanism
to restore a partially trashed tree without transferring or storing the entire
source. However, in most cases that I have seen, the need to do this was
created by the user's misuse of the distribution. IMHO, the distribution needs
to be treated as "read only"

I think it would greatly help if we would look at source distribution as a
mini release (multiple times per day for some things) and have all of the
necessary information distributed so that it is possible to use any of the
four distribution channels (tarballs, live tree on CD, CTM, and SUP) to move
from one point to another. In other words, have sup distribute a CTM release
(complete with the .ctm_status file identifying it) rather than some other
arbitrary snapshot. Similarly, we should assure that the information on the
CD's matches an identifiable point in the CTM sequence.

I recognize that this does not really address the problems of committing
changes to a rapidly moving target

Richard

--

"No amount of theoretical understanding can replace the 
sight of a giant electronic computing system in operation. 
One must see what it really looks like, hear the sounds, 
and feel the atmosphere of the computing room.  ... 
At the far end of the evenly lit room is a big metal box. 
It is about 9 feet high, 14 feet long, 8 feet deep..."

(c) 1957 - Sperry Rand Corporation



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1380003191.78965>