telecom@eecs.nwu.edu (10/07/89)
TELECOM Digest Thu, 5 Oct 89 20:35:25 CDT Special: Eat Crow!
Today's Topics: Moderator: Patrick Townson
Moderator Takes His Medicine Like a Man Child!! (Patrick A. Townson)
----------------------------------------------------------------------
Date: Thu, 5 Oct 89 20:18:28 CDT
From: TELECOM Moderator <telecom@eecs.nwu.edu>
Subject: The Roar of the Crowd
Well.....
The messages excerpted below speak for themselves, I guess. There were
some additional messages marked 'not for publication', and they are not
included, but correspondents should be assured all have been read and
considered.
Regards the list which started this thread, if anyone wants it who cannot
aquire it through the suggested instructions, they should write to me
at 'ptownson@eecs.nwu.edu' -- NOT to the telecom address. I will send a
compressed copy unless you specify you have no way to uncompress it on
your end. If you prefer 'uuencode' and 'uudecode' instead, please specify
that method.
So here is the consensus --
====================
From: jsol@bu-it.bu.edu
I second the motion. What R. E. Seastrom doesn't realize is that the
command "telnet foo 21" will do the same thing as "ftp foo". The
connection that is used in a FTP command is not compressed nor is it
load-reduced in any frame of mind. I want my FTP jobs to get done
FAST, I don't want to background them just because some twit wants to
play nethack on a machine across the country. This is more legitimate
than playing games.
Now, if the program could be offered compressed and uncompressed that
would be useful. The host table is currently compresed, however the
host port on the NIC.DDN.MIL machine that you can use (by telnet
nic.ddn.mil <portno>) to receive the host table is the same way and it
is definitely official business.
Saying that the Internet growth has to be slowed is a good idea, but
you pointed your gun at the wrong issue.
jsol
====================
From: Will Martin <wmartin@stl-06sima.army.mil>
Well, anti-social or not, I've tried the given command from BOTH a Sys V
system (Unisys) and a BSD system (VAX) and all I get as a response is:
"telnet: connect: Connection timed out"
However, I must say that it DOES seem rather strange that the original
message quoted by the moderator says this:
>If you don't have tail or compress, just redirect the telnet output
>into a file.
That indicates the file is coming in uncompressed mode. What is the
purpose of them telling the requesters to feed it into compress and
end up with a compressed file, anyway? To use it you would have to
then uncompress it. That appears to be what Mr. Seastrom was pointing
out. Am I missing something here?
Regards, Will Martin
====================
From: Paul Fuqua <pf@islington-terrace.csc.ti.com>
The file does not travel compressed, it is compressed because you pipe
it through compress on your end. Go telnet to 128.146.1.5, port 4666,
without the piping stuff, and see what shows up on your screen.
Since hpuxa does not provide anonymous FTP, I can see why they'd
choose this somewhat weird method of distribution, but maybe they'd be
better off talking to the CIS department --
osu-cis/tut.cis.ohio-state.edu provides both anonymous FTP and
anonymous UUCP.
Paul Fuqua pf@csc.ti.com
{smu,texsun,cs.utexas.edu,rice}!ti-csl!pf
Texas Instruments Computer Science Center
PO Box 655474 MS 238, Dallas, Texas 75265
====================
From: Doug Faunt N6TQS 415-688-8269 <faunt@cisco.com>
Err, Mr. Seastrom overreacted, but he's correct. Using the script
given, the compression takes place at your machine, and the file is
transmitted uncompressed. I suspect that Dan Bernstein has not got
official approval of what he's doing, which is why the strange method
of file transfer, and therefore an address at ohio-state, or nyu gives
him no standing from that. Compressing the file before the transfer,
and using anonymous FTP is the standard way of doing this type of file
distribution. A server, for both mail and telnet requests, is another
alternative.
You over-reacted also, and as moderator, it's part of your job to cool
flames, not fan them.
respectfully, doug faunt <faunt@cisco.com>
====================
From: Frank Prindle <prindle@NADC.ARPA>
Patrick,
One small correction - the list is transmitted via telnet (TCP/IP
protocol) and is not transmitted as (and cannot be transmitted as) a
compressed file, because telnet protocol supports only text
transmissions. The suffix .Z does indicate a compressed file (not .z,
but .Z), but the Unix command line given does the compression at the
receiving end (for what purpose, I'm not sure, since it is not too
much fun to search the file that way).
Also, any claim that this is a nearly complete list of internet users
is highly exaggerated. It appears to be a compendium of registered
members of a small subset of Arpanet mailing lists, certainly not all,
and extremely far from a complete list of users; NADC.arpa alone has
over 1000 users capable of sending and receiving internet mail, and at
least 100 active in one or more mailing lists; the subject list
includes precisely 3 (curiously, I am one).
Several substantially larger and more organized lists exist: one, a
commercial venture called National E-Mail Registry includes all
commercial E-Mail systems in addition to
Arpanet/Milnet/UUCP/Bitnet/etc..... Another is the "whois" database
maintained at SRI-NIC.arpa. Both of these allow voluntary free
registration; the fact that they rely on individual manual
registration means that they still each cover only a minor subset of
the total population they are trying to list, but do list such things
as address, phone number, etc.
I realize that you were just relaying a bit of seemingly useful
information, and ended up caught in the middle of a controversy. It
would have raised a lot less eyebrows if it just appeared as a
compressed file on some SIMTEL20 FTP database, and probably conserved
a lot of net resources too. You might just pass this back to it's
creator.
====================
From: Pat Stephenson <patrick@cs.cornell.edu>
Patrick,
First of all, I would like to congratulate you on the way in
which you run telecom digest. I read it on Usenet; comp.dcom.telecom
is one of the best groups around. Keep up the good work!
However, I believe that you made a misstep today. Mr Seastrom
pointed out two facts about Bernstein's methods of data transfer, and
drew the conclusion that Bernsteins method was *not a good thing*. I
do *not* agree with Mr Seastroms conclusion. His facts are, however,
correct.
Seastrom's two points were:
1) The data is *TRANSFERRED OVER THE NETWORK* UNCOMPRESSED.
2) The data is COMPRESSED *WHEN IT ARRIVES AT A RECEIVING SITE*
(thus, overall, the compression is done many, many times instead of
once)
Lets's look at Bernstein et al's command line:
> telnet 128.146.1.5 4666 | tail +4 | compress > userlist.Z
1) the *only* data transfer command is "telnet".
2) the "tail" command will buffer the data as it arrives.
2) the "compress" command will compress the output of the tail
command.
Note that both "tail" and "compress" will run on the *local machine
only*. Thus Seastrom's points of fact are correct - data is
transferred uncompressed, and compression takes place at every
receiver.
(In fact, one could get an uncompressed version of the data by saying:
telnet 128.146.1.5 4666 | tail +4 > userlist
)
Again, I don't think these two points justify Seastrom's flame. But,
as points of fact, they are true.
Patrick, I have the greatest regard for the way in which you run the
digest. I think it is appropriate for you to keep up your high
standards by admitting when you are wrong, and apologizing to Mr
Seastrom.
Pat Stephenson.
====================
From: David Albert <albert%endor@husc6.harvard.edu>
In article <telecom-v09i0426m02@vector.dallas.tx.us> telecom@eecs.nwu.edu
(TELECOM Moderator) writes:
>What a laugh. Frankly, Mr. Seastrom, you don't know what you are talking
>about.
I'm afraid the laugh is on you, at least as far as the compression
argument is concerned.
>Please note also that contrary to the misguided information from the
>previous correspondent, the file *does come compressed*.
No it doesn't. Reread the following instruction line, which have now
posted twice and emphasized once:
> telnet 128.146.1.5 4666 | tail +4 | compress > userlist.Z
What this line does is, first, to transmit over the net the entire,
uncompressed file, and only *afterwards* to pipe it through "compress"
at the *recipient's* end, creating, to be sure, a file ending in ".Z".
>Mail any lengthy comments to this address. If you complain about the
^^^^^^^^^^^^^^^^^^^^^^^^^
>operation of the list, make sure to suggest something better.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which is exactly what the previous poster did: he suggested that the
site decide offer anonymous ftp access, and that it compress the file
at its end. His language may have been somewhat strong, but it was
not without at least some justification.
Please reread what you posted.
David Albert | "What are you trying to do,
UUCP: ...!harvard!albert | change the world?"
INTERNET: albert@harvard.harvard.edu | "No, just our little corner of it."
====================
From: Andy Behrens <andyb@coat.com>
In article <telecom-v09i0426m02@vector.dallas.tx.us> our Moderator writes:
(stuff deleted)
Robert Seastrom is correct.
Patrick Townson is wrong.
The file *is* transmitted uncompressed. If you follow the instructions
supplied by Ohio State
telnet 128.146.1.5 4666 | tail +4 | compress > userlist.Z
You will transmit the uncompressed file (all 450K of it) to your own
machine, where it will be compressed and saved under the name
userlist.Z. Compress is run at the receiving end to conserve disk
space; it has no effect on the way that the file is transmitted.
(There are apparently technical reasons why the ohio-state.edu machine
is unable to transmit compressed files in this case, but that's not
relevant here).
Snide remarks about "lessons for the elementary beginning student",
and "maybe RGS will go back and read it again" have little place in
this Digest, particularly when the statements being derogated are
correct. If anyone else posted remarks like this to the Digest, I
would hope that the moderator would rebuke them. As it is, I think
Patrick owes Robert Seastrom an apology.
====================
From: Bill Fenner <wcf@hcx.psu.edu>
In article <telecom-v09i0426m02@vector.dallas.tx.us> you write:
|X-TELECOM-Digest: volume 9, issue 426, message 2 of 8
(stuff deleted)
Sorry, Patrick, RGS was right. The list is not compressed as it is
sent. If you look at that pipeline, | tail +4 removes the telnet
header, and | compress compresses the file locally. To make sure, I
tried to telnet 128.146.1.5 4666 without any pipeline afterwards; it
was pure text.
|If you don't have tail or compress, just redirect the telnet output
|into a file.
Implying that it doesn't come compressed. If you don't have compress,
you can't uncompress a compressed file.
Bill
Bitnet: wcf@psuhcx.bitnet Bill Fenner | aaaaaaaaa
Internet: wcf@hcx.psu.edu | r
UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | g
Fido: Sysop at 1:129/87 (814/238 9633) \hogbbs!wcf | h
====================
From: "John R. Levine" <johnl@esegue.segue.boston.ma.us>
In article <telecom-v09i0426m02@vector.dallas.tx.us> you write:
(stuff deleted)
You know, it never hurts to be polite even when you're sure you're
right, because sometimes you're not. This command line sucks the
uncompressed file over the net, throws away the first four lines which
are presumably headers, compresses it locally, and stores it in a
file. You can't send compressed data through telnet because it's not
a transparent connection. Blatting 900K of uncompressed data over the
chronically overloaded Internet is pretty antisocial; it's not hard to
find someone willing to make a compressed version available via FTP.
Or better, they could come up with a server that will string search
for a name and just return a short answer, like the NIC has.
Regards,
John Levine, johnl@esegue.segue.boston.ma.us, {spdcc|ima|lotus}!esegue!johnl
====================
From: kenr@bbn.com
In article <telecom-v09i0426m02@vector.dallas.tx.us> you write an
unfortunate retort to a complaint about a transfer of a large
uncompressed file.
The instructions are
> telnet 128.146.1.5 4666 | tail +4 | compress > userlist.Z
>followed by a line of anything, terminated by a line feed (not carriage
>return). After a few minutes, depending on your network speed, telnet
>will finish and the compressed list will be in userlist.Z. If you
So far so good.
If you're going to be a unix pedant you should try to get it right.
The file doesn't "come compressed," and that's exactly why it has to
be piped through "compress," on the receiving host after transmission.
It ends up compressed because of that command (hence the .Z), but the
compression occurs on the local system, and it's pretty clear from the
instructions that the data gets sent along uncompressed.
>What a laugh. Frankly, Mr. Seastrom, you don't know what you are talking
>about.
Sigh. Indeed?
Mr. Bernstein, would you consider revising the operation of special
port 4666 to allow for a compressed transmission?
KENR@BBN.COM
===============================
Thanks very much to one and all who wrote; even those who requested that
they not be published. Sorry, Mr. Seastrom.
Issue 431 is in the hopper now. Watch for a couple Digests between now
and Friday morning.
Patrick Townson
------------------------------
End of TELECOM Digest Special: Eat Crow!
*****************************