>I was always wondering, why the services offered by all those LISTSERV
>machines are not transparent, i.e. why you always have to keep in mind which
>LISTSERVer serves which list.
Because I'm not working full-time on LISTSERV, and I'm not full-time on the
computer either. But do read on.
>With a really user friendly service you should always have to just talk to
>"your" LISTSERV, and this machine would then either process your request
>itself or forward it to the nearest LISTSERV which is capable of processing
>it.
I know my memory isn't what it was in my youth, but I seem to remember having
implemented something along these lines lately. I think it was called "Release
1.5n" and would let you subscribe or signoff from just any LISTSERV, provided
both the server you send your command to and the one hosting the list are
running 1.5n.
>For this to be possible, some things would be needed:
>
>1. Every LISTSERV has to maintain a table where all nodes of the net are
> paired with "their" LISTSERVer. This will enable it to pass requests
> erroneously sent to it to the correct LISTSERV.
Ah. A NETSERV-like concept. You seem to assume that every LISTSERV provides
the same kind of service, and is willing to provide the same amount of CPU for
non-local usage. This also seems to imply static allocation, with a table that
has to be maintained manually. Anyway this table isn't needed. Try sending an
INFO REFCARD command to some LISTSERV in the States and you'll see how it
directs you back to DEARN. Without having any such table.
>2. Every LISTSERV needs a table where ALL mailing lists (netwide) are paired
> with the name of the "nearest" peer (where "nearest" is meant here with
> respect to some apropriate cost function).
Nearest to what? To the user issuing the command, I assume. Just because this
LISTSERV would be the nearest to the user and the peer would be nearest to the
LISTSERV doesn't mean the peer would be nearest to the user (it's like in a
triangle). Anyway, the present setup is that each LISTSERV knows the address
of at least one of the peers, and then each peer knows EXACTLY which peers are
available and dynamically finds the one nearest to the user (CPU cost: 0.11
sec 4341, or 0.02 sec 3090).
>4. For every mailing list, each LISTSERV maintains a list of "regional"
> recipients, i.e. recipients sitting at one of the nodes for which that
> LISTSERV is responsible. It is the LISTSERV that is primarily subscribed
> to the various lists. It then redistributes mail to the "regional"
> subscribers. Therefore subscribing will be a "regional" matter regardless
> of where the next peer resides.
Now that starts sounding like GRAND. I can already imagine the overhead when a
new LISTSERV is installed and the notion of "regional" recipient changes in
that area. I fail to see the interest of this since anyway (in an ideal
network where everybody is running 1.5n) you can subscribe to any list by
sending the request to any server, including your "regional" one, and you will
always be rerouted to the nearest peer. The load problems are best handled by
DISTRIBUTE.
>This concept looks a bit as if every LISTSERV peers every list, but this is
>only true with respect to distribution of mail, not with respect to keeping
>notebooks or other database information. This will still be the job of the
>real peers, the only difference being, that any request is sent to the
>"regional" LISTSERV first.
Well if you send database access requests (for example) to your regional
server, which then forwards it to the proper server, which forwards the reply
to the regional server, which eventually answers you, you have a significant
amount of overhead for the regional server, not to mention the problems that
may arise if it goes down.
Eric
|
