🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.protocols.misc
4 messages
4 total messages Started by "NJITX::HXN8477" Fri, 04 Nov 1988 03:18
Mailing lists and the BW they consume
#878
Author: "NJITX::HXN8477"
Date: Fri, 04 Nov 1988 03:18
54 lines
3398 bytes
I have been thinking about an idea which can reduce the network traffic 
greatly.  It is about the bandwidth that the mailing lists unnecessarily
consume.  

It is no secret that much of the traffic on the Internet, and some other
networks for that matter, today is due to mailing lists.  Mailing lists
have been rapidly proliferating and the number of subscribers is always on
the rise.  Almost every one I know is on some mailing list or another and
some of them get more mail from the lists than from persons.

Seemingly, the designer(s) of the mail protocol didn't have in mind this
lists phenomenon.  What is happening today is amazing.  Suppose there are
50 subscribers on host x in New Jersey to a given list based at host Y in 
California.  Then if a message sent to the list, 50 identical copies are
sent all the way from host y in CA to host x in NJ.  If only one copy is
sent to host x in NJ and the duplication takes place locally, rather than
at host y, a great deal of unnecessary traffic can be eliminated.  All that
is needed is software at each host to do the duplication.  The envisioned
protocol works as follows:

1. Joe at host x subscribes to the mailing list at host y. 
2. The moderator of the list subscribes the host, rather than Joe, to the
   list.  At the same time the moderator sends Joe's user's id to 
   the duplication software on host x, for this particular list.
3. When a new message arrives to the list, copies are made only to the 
   subscribing hosts.
4. Each host identifies the list from which the copy arrives.  And with the 
   help of the table containing the names of people on this list, it places
   a copy in each subscriber's mail box.

While totally transperant to the user, this protocol can significantly
reduce the amount of traffic due to mailing lists.  It should be noted
that this does not decentralize the mailing list, and therefore does not
require the sophstication of a distributed mailing list.  
It should also be noted that the duplication can be done at the domain
level, rather than the host level, which may have some advantages but also
some drawbacks..



                  .;;;.             ..                              
    /\           //^|^\\          .'..;                             
   /  \  /\         |     _/~~\_.'.'    
  /    \/  \  /\    |   ,(_      )         "Blanked until further notice" 
 /      \   \/  \   |   '  \~~~|'           
/        \   \   \  |      |   |           
+---------------------------+------------------------------------------------+
|Hamed Nassar               |Internet  : hxn8477%njitx.decnet@njitc.njit.edu |
|EE Department              |UUCP      : bellcore!argus!mars!nancy           |
|NJ Institute of Technology |CompuServe: 74000,130                           |
+---------------------------+------------------------------------------------+

------
Re: Mailing lists and the BW they consume
#879
Author: Nobuyoshi Tanaka
Date: Fri, 04 Nov 1988 18:15
17 lines
1184 bytes
In article <8811040331.AA00880@rutgers.edu> "NJITX::HXN8477" <hxn8477%njitx.decnet@njitc.njit.edu> writes:
>If only one copy is
>sent to host x in NJ and the duplication takes place locally, rather than
>at host y, a great deal of unnecessary traffic can be eliminated.  All that
>is needed is software at each host to do the duplication.

RFC822 defines this way of delivery, isn't it?
--Nobu
--
 Nobuyoshi Tanaka         Internet: ntanaka@cs.cmu.edu
  NEC Corporation         Voice:    +1 (412) 268-7673
  (currently at CMU)                         CMU-ROSE :-)

-- 
 Nobuyoshi Tanaka         Internet: ntanaka@cs.cmu.edu
  NEC Corporation         Voice:    +1 (412) 268-7673
  (currently at CMU)                         CMU-ROSE :-)
Re: Mailing lists and the BW they consume
#881
Author: Wonderly
Date: Sat, 05 Nov 1988 04:09
33 lines
1727 bytes
From article <8811040331.AA00880@rutgers.edu>, by hxn8477%njitx.decnet@NJITC.NJIT.EDU ("NJITX::HXN8477"):
> 
> I have been thinking about an idea which can reduce the network traffic 
> greatly.  It is about the bandwidth that the mailing lists unnecessarily
> consume.  

What you describe involves separating the envelope from the mail message.  The
MMDF mailer does this for the PHONENET protocol (dial up traffic).  The SMTP
protocol allows this as well, and since it is widely used on the internet
already (despite someones blunder with debug/sendmail) I suspect that a lot
of traffic is already eliminated.  SMTP goes like

MAIL FROM: <user@domain>
RCPT TO: <user1@domain>
RCPT TO: <user2@domain>
...
DATA

...
.

With as many RCPT TO: lines as recepients.  As long as the origination
point or some point along the ways does not resort to uucp or other
'one message per user' routing, things will be pretty much optomized.

(Now all we have to do is convince the world that it is NOT UN*X's fault,
 just a programming blunder.  Of course the media loves this and couldn't
 care less if it could have been prevented.)


-- 
It isn't the DREAM that NASA's missing...  DOMAIN: gregg@ihlpb.att.com
It's a direction!                          UUCP:   att!ihlpb!gregg
Re: Mailing lists and the BW they consume
#882
Author: Jon Zeeff
Date: Thu, 10 Nov 1988 04:10
16 lines
1012 bytes
In article <9034@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes:
>
>With as many RCPT TO: lines as recepients.  As long as the origination
>point or some point along the ways does not resort to uucp or other
>'one message per user' routing, things will be pretty much optomized.


Uucp here certainly sends only one copy of mail going to two users at
another site.  I find it interesting that someone posting from AT&T knows
more about SMTP than uucp.



-- 
Jon Zeeff      			Ann Arbor, MI
umix!b-tech!zeeff  		zeeff@b-tech.ann-arbor.mi.us
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads