MCNTP - Multicast News Transport Protocol
MCNTP is used to distribute NetNews articles via IP multicast. In the classical sense news are transferred via nntp on point to point links or sometimes batches of articles over uucp. The following considerations on- ly apply to the distribution over nntp as the transport over uucp is most often used these days only towards hosts that are not always online. Even if the (virtual) net of hosts exchanging news is densely meshed, there is no optimal use of the mesh as articles often cross the same physical link multiple times. This can be prevented by installing news servers at every major node which get the articles only one time and then distribute them only to their direct neighbors. This is hardware and support intensive.
Now with IP multicast the idea comes to mind that articles are fed into the multicast backbone and everyone who wishes to receive articles just subscribes the appropriate multicast group to receive the news articles. Multicast routers only deliver articles to those who want them and arti- cles only cross the physical links once as the routers only duplicate the packets when they need to.
The communication between mcxmit(8) and mcrcv(8) can be compressed (by using libz(3) ) and crypted. Compression can save even more bandwidth, but uses some cpu cycles. Cryption can be used to provide private news- groups over the public mbone. Note that cryption is heavily dependent on the law as there are countries which don't allow to use encryption tech- nologies to be used.
Before sending, mcxmit signs every article with the private key of the sender. Mcrcv checks the articles with the public key of the sender of the packet. If the signature is not valid, the article is thrown away and a log entry is made.
With MCNTP you have at the provider site some sender processes, mcxmit(8) , that bring the articles on the wire and the receiver sites run mcrcv(8) to get the articles of the wire and into their news system. That process is coordinated by a some controlling daemon processes, yawgmoth(8) . yawgmoth(8) and mcrcv(8) can limit the senders that they accept messages from by setting up access control lists.
With this setup articles will cross links usually only once resulting in savings in line cost. As the transfer via IP multicast is not reliable, you still have to run the classical nntp connections, but which will only be ihave already got it streams most of the time especially if you use delayed nntp as for example provided by nntplink(8) or innxmit(8) jobs that are just run once every five minutes. Mcntp is quite fast in use -- running it in parallel with nntplink(8) shows that more than the half of articles can be transferred with mcntp even if nntplink does not delay the articles.
As you might already have guessed, mcntp need a working IP multicast in- frastructure and hosts that have the appropriate extensions to their ker- nels. This paper won't describe how to achieve this, but your provider might be able to help you out. Also http://www.mbone.com and http://www.mbone.de/ will be of help.
Here comes a very short description of every module of the mcntp project; each one of it has its own man page(s) to look for more information.
Sender program. It receives a article path in the spool, message id and article age on stdin, gets the article from the file system and sends it to the appropriate multicast group.
Receiver program. This one tunes into the appropriate multicast group(s) for the selected news groups, fetches the articles from there and feeds them to a local nntp server.
Coordinator. This tool is used to coordinate the relation between newsgroup names and multicast group numbers. It must run on every host that also wishes to run mcxmit(8) .
Measurement tool. It can be used to find out packet loss rate be- tween two multicast hosts.
Debugging tool. Dumps the relation between newsgroup names and mul- ticast group numbers as communicated between yawgmoth(8) processes.
Example. Little chat program a bit like talk(1) that uses multicast for communication with chat partners. Shows how one can use the functions of libmc(3) to program a simple chat program with only a few lines of code.
Example and helpful tool. acltest(1) is a tool to validate given access control lists. These lists can then be used to limit recep- tion of control messages and articles.
tool to create private and public keys for use with mcntp. This is also used to manipulate the keyring, where public keys from senders that you trust, are kept.
The Library that provides a higher level multicast api than the normal socket interface. libmc(3) is needed to get all the pro- grams work that come with mcntp.
acltest(1) , mcxmit(8) , groupdump(1) , mcrcv(8) , yawgmoth(8) , mcntp.conf(5) , rctest(1) , nntplink(8) , innxmit(8) , libmc(3) , libz(3) , news(5) , innd(8)
The Usenix paper from Rich Salz, where he first presented the INN
system at ftp://ftp.uu.net/networking/news/nntp/inn/inn.usenix.ps.Z
A overview paper for those that are not familiar with nntp and news by Tom Podnar <firstname.lastname@example.org> at ftp://bones.wcu- pa.edu/pub/nntp.ps
The data format used by the zlib library is described by RFCs (Re- quest for Comments) 1950 to 1952 in the files ftp://ds.inter- nic.net/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format). These documents are also available in other formats from ftp://ftp.uu.net/graphics/png/docu- ments/zlib/zdoc-index.html
The documentation of RIPEMD-160 can be found in the ripe-md160 di- rectory of the mcntp distribution.
MCNTP is the diploma thesis Transport of NetNews via IP-multicast of the author.
Heiko W.Rupp (email@example.com)
None known yet. If you find any, then please report them via the bug trackers at http://sourceforge.net/projects/mcntp/
Table of Contents