From cdd443e94cf950f9022899744bf33cea11effd2a Mon Sep 17 00:00:00 2001 From: starcom <> Date: Thu, 3 Oct 2002 06:19:40 +0000 Subject: [PATCH] Changed authorlist to reflect that Hema no longer maintains the HOWTO. Made some small cleanup changes, corrected some typos. --- .../Usenet-News-HOWTO/Usenet-News-HOWTO.sgml | 6 +-- .../docbook/Usenet-News-HOWTO/conclusion.sgml | 5 ++- .../Usenet-News-HOWTO/perspective.sgml | 42 +++++++++---------- .../docbook/Usenet-News-HOWTO/security.sgml | 2 +- 4 files changed, 26 insertions(+), 29 deletions(-) diff --git a/LDP/howto/docbook/Usenet-News-HOWTO/Usenet-News-HOWTO.sgml b/LDP/howto/docbook/Usenet-News-HOWTO/Usenet-News-HOWTO.sgml index 8c3c2ab6..3d06a2c8 100644 --- a/LDP/howto/docbook/Usenet-News-HOWTO/Usenet-News-HOWTO.sgml +++ b/LDP/howto/docbook/Usenet-News-HOWTO/Usenet-News-HOWTO.sgml @@ -23,11 +23,6 @@ Shuvam Misra - - - - Hema Kariyappa - (usenet at starcomsoftware dot com) @@ -58,6 +53,7 @@ +# &what; &pop; &software; diff --git a/LDP/howto/docbook/Usenet-News-HOWTO/conclusion.sgml b/LDP/howto/docbook/Usenet-News-HOWTO/conclusion.sgml index 7ced05b4..53020d19 100644 --- a/LDP/howto/docbook/Usenet-News-HOWTO/conclusion.sgml +++ b/LDP/howto/docbook/Usenet-News-HOWTO/conclusion.sgml @@ -20,7 +20,7 @@ systems would have remained very fragmented and superficial. Our insight into Unix came from our ``Village Elders'' in the Department of Computer Science of the IIT (Indian Institute of Technology) at Mumbai, specially from ``Hattu,'' ``Sathe,'' and ``Sapre,'' none of whom are with the IIT -today, and from Professor D.B.Phatak and others, many of whom, luckily +today, and from Professor D. B. Phatak and others, many of whom, luckily are still with the Institute. Coming to Starcom, all the members of Starcom Software who @@ -28,6 +28,9 @@ have worked on various problems with networking, Linux, and Usenet news installations have helped the authors in understanding what works and what doesn't. Without their work, this HOWTO would have been a dry text book. + +Hema Kariyappa co-authored the first couple of versions of this +HOWTO, starting with v2.0.
Comments invited diff --git a/LDP/howto/docbook/Usenet-News-HOWTO/perspective.sgml b/LDP/howto/docbook/Usenet-News-HOWTO/perspective.sgml index 81b10228..71ba29e9 100644 --- a/LDP/howto/docbook/Usenet-News-HOWTO/perspective.sgml +++ b/LDP/howto/docbook/Usenet-News-HOWTO/perspective.sgml @@ -27,40 +27,38 @@ opinion than detail, are discussed here. Ping-pong protocol: NNTP is unsuitable for - bulk streaming data transfer. + bulk streaming data transfer because the TCP sliding window feature + is unusable with NNTP. - A word of explanation on the ping-pong issue is perhaps - needed here. TCP uses a sliding window mechanism to pump out - data in one direction very rapidly, and can achieve near - wire speeds under most circumstances. However, this only - works if the application layer protocol can aggregate a - large amount of data and pump it out without having to stop - every so often, waiting for an ack or a response from the - other end's application layer. This is precisely why sending - one file of 100~Mbytes by FTP takes so much less clock time - than 10,000 files of 10~Kbytes each, all other parameters - remaining unchanged. The trick is to keep the sliding window - sliding smoothly over the outgoing data, blasting packets - out as fast as the wire will carry it, without ever - allowing the window to empty out while you wait for an ack. - Protocols which require short bursts of data from either end - constantly, e.g. in the case of remote - procedure calls, are called ``ping pong protocols'' because they - remind you of a table-tennis ball. + What is a ping-pong protocol? TCP uses a sliding window mechanism to + pump out data in one direction very rapidly, and can achieve near + wire speeds under most circumstances. However, this only works if + the application layer protocol can aggregate a large amount of data + and pump it out without having to stop every so often, waiting for + an ack or a response from the other end's application layer. This is + precisely why sending one file of 100 Mbytes by FTP takes so much less + clock time than 10,000 files of 10 Kbytes each, all other parameters + remaining unchanged. The trick is to keep the sliding window sliding + smoothly over the outgoing data, blasting packets out as fast as the + wire will carry it, without ever allowing the window to empty out + while you wait for an ack. Protocols which require short bursts of + data from either end constantly, e.g. in the + case of remote procedure calls, are called ``ping pong protocols'' + because they remind you of a table-tennis ball. With NNTP, this is precisely the problem. The average size of Usenet news messages, including header and body, is 3 Kbytes. When thousands of such articles are sent out by - NNTP, the sending server has to send the message~ID of the + NNTP, the sending server has to send the message ID of the first article, then wait for the receiving server to respond - with a ``yes'' or ``no.'' Once the sendiing server gets the + with a ``yes'' or ``no.'' Once the sending server gets the ``yes'', it sends out that article, and waits for an ``ok'' - from the receiving server. Then it sends out the message~ID + from the receiving server. Then it sends out the message ID of the second article, and waits for another ``yes'' or ``no.'' And so on. The TCP sliding window never gets to do its job. diff --git a/LDP/howto/docbook/Usenet-News-HOWTO/security.sgml b/LDP/howto/docbook/Usenet-News-HOWTO/security.sgml index a872e882..d342ffcb 100644 --- a/LDP/howto/docbook/Usenet-News-HOWTO/security.sgml +++ b/LDP/howto/docbook/Usenet-News-HOWTO/security.sgml @@ -34,7 +34,7 @@ business or occupation.
Generic server vulnerabilities Foremost among these vulnerabilities are those which render -anyserver vulnerable to intrusion attempts. +any server vulnerable to intrusion attempts. Most of these vulnerabilities are unrelated to Usenet news itself. For instance, if you have the Telnet service active on a server exposed to the Internet, then it is likely that systematic attempts by intruders