On Tue, 30 Oct 90 18:08:08 IST Zvika Bar-Deroma (Tel. +972 4 292706; FAX: +972 4
>This may sound trivial but I'll risk  it: what is the benefit of PEERing
>in the  days of DIST2 ?  I'm a bit confused  and have my own  ideas, but
>would like to make sure I know what's going on.
 
I would like to re-beat a dead horse here, after trying to explain this to
someone else and ending up confusing myself again (know that feeling?).
I'm sure someone can pipe in here and correct me if, well lets just say where,
I'm wrong.
 
Regular peered lists send people to the nearest peer.  Peered lists are to
optimize service to the subscriber.  But distribution is another issue.
 
Regular lists send out 1 file to each recipient, unless:
* the target node has a mailer, then it sends out 1 copy for every 5
  recipients,
- but does it fold in sites with the same Mailer?  or for clusters?
 
DIST2 figures out who all is on the list, what backbone servers they are
closest to, then routes a copy through the backbone to the appropriate servers
to cover everyone on the list.  Sort of like all backbones are peers.  But
that's where things go awry.  To get single-recipient "To:" fields, these
DIST2 lists send one copy per recipient (except it groups INTERBIT recipients
into one BSMTP posting and replaces the RFC822 'To:' with 'Multiple recipients
of list foobar').
 
There was talk some time ago about having DIST2 follow the multiple-recipient
behavior of the original lists, but I don't recall anything coming out of it.
DIST2 is much more efficient on the front end, transferring fewer copies over
the long paths to the backbone servers; but then its near worst-case
inefficient in the final split.  Sure, it looks good only having yourself as
the only recipient in the 'To:' field; but there is a price to be paid for it.
Is there some way to have the DIST2 final delivery be done via the old way,
ie, grouping multiple recipients?
 
/Jeff/