ok, ok... I never said I was not going to implement any service area, my
point was just that service areas are STATIC and should therefore be used
only when links-distance is not sufficient... A few changes:
1) The notification letter for SUBSCRIBE is now sent to owners cc: newguy.
2) You can now indicate a specific listname in "Peers=", eg:
Peers= EB0UB011,CLVM,DEARN,MD40@CMUCCVMA,CLVM
3) You now have an optional "Service=" keyword. Format is "Service= s1<,s2<,s3>
>>", with each of the si being either a country name, a node name, "xxx*",
"*yyy" or "xxx*yyy".
4) MOVE, ADD, SUBSCRIBE, EXPLODE, support items (2) and (3), untested.
However, service areas don't work as you might intuitevely except it. Let me
describe how they work and I'll explain why later.
a) If the guy is not from BITNET, a search is done in DOMAIN NAMES to find the
gateway's node. If not found, *sigh* peers are disregarded.
b) If we have peers, and if there is a peer nearer than us, then the request
gets forwarded to that peer. Service areas are ignored.
c) Now service area, if any, is checked, and the request is denied if the guy
is outside our service area.
Hold on your flame a little while:
1) My experience of relay shows that:
a) Having a SYNCHED service area file for each list on all the servers is
impossible. You will always have at least one peer which will install
the new file one week after everybody. In the meanwhile... :-(
b) Maintaining a serious service area is just IMPOSSIBLE. Because of the
unexisting naming conventions on BITNET, it is not possible to name,
say, "BN*" to get all the Namur nodes. You'd catch BNL and BNLDAG too,
and those are in the states. A comprehensive listing would take about
10 lines of node names, to be maintained every time the master nodes
file is updated. Not to mention the havoc when a new peer is added in
the vicinity.
2) Therefore the suggested modus operandi is the following:
a) Local-node-only lists set "Service= Local", e basta.
b) Local-institution lists set "Service= node1,node2..." or "xxxx*" (if at
all possible)
c) Other lists set "Service= country,country..." If there are several peers
in the same country, no problem, the request will be forwarded to the
nearest one. As I said before, I believe that a decent links weight file
should route people correctly in 80% of cases, and is not a big problem
to maintain because the same file is used in all the servers.
3) Another advantage: assume that postmaster D... at node F... is very lazy. He
has a LISTSERV set with "Service= something*". Now YOU create a peer to this
server, and realize that all your users get bumped to F... Not good... Espe-
cially since D... never answers your mail, nor does he take time to change
the list header, and of course he didn't give you privs on his list. In that
case you'd be very happy to have service areas the way I defined them. I
will of course try to avoid this kind of problems by not giving the listserv
code to people who don't answer mail and suchlike, but you can always have a
nasty surprise and there are also people I couldn't refuse to ship the code
to if they asked for it.
Eric
|
