HDTenEightyP/NetNews huggingface dataset:
From: r0mill01@ulkyvx.louisville.edu
Subject: (Fwd: *C&CD*) Daedalus Info (4)
Date: Thu, 28 Jan 1993 08:38:35 GMT
Organization: University of Louisville


Entry: 4
Date: Tue, 26 Jan 93 08:57:32 CST
From: "Ralph L. Wahlstrom" <rwahlstr@hp.uwsuper.edu>
Subject: Daedalus Info (4)
Message-id: <32257.rwahlstr@hp.uwsuper.edu>
Comments: X-Popmail-Charset: English
Reply-to: Computers & Composition Digest (R. Royar) <R0MILL01@ULKYVX.BITNET>

I hate to resurrect the Daedalus, but I've let a lot of the discussion pass
me by.  Now I'm looking to buy conferencing software, and I like Daedalus
(I used it during Cindy Selfe's seminar in Houghton last summer).

Who distributes Daedalus?  Does anyone know of other
comparable software for IBM?  Dickie, If you're out there listening, talk
to me.

By the way, if you or your department budget can raise the cash, Cindy
Selfe, Trent Batson, and Gail Hawisher will be presenting another Computers
in Writing-Intensive Classrooms this summer (June 14-25) at Michigan Tech.
With any luck, it won't snow this year, and even if it does, it's worth it.
Ralph W.
rwahlstr@uwsuper.edu



------------------------------
Newsgroups: comp.edu.composition
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Determining Port Numbers & The RPC Portmapper
Date: 22 Jan 93 04:00:39 GMT
Organization: Auspex Systems, Santa Clara

>I was just wondering if it is possible to connect and send commands to the 
>RPC portmapper without using RPC calls (svc_xxx or pmap_xxx) but tli or 
>socket calls.

Well, yes, it is possible - after all, ultimately, the code that
implements RPC calls generally does so using sockets or TLI calls....

I.e., yes, you can do it, but the commands you send to it are just RPC
calls, so the only way to avoid using the RPC routines is to do just
what they do....

>The protocol specifications for the portmapper (appendix A of the RFC1057) 
>does not say anything about the low level commands that the portmapper 
>recognizes.

Yes, it does.  It gives a description, "in RPC Language", of the port
mapper protocol.  If the fact that the description is given "in RPC
Language" doesn't tell you that the port mapper is an RPC service, the
fact that section 7.4.2 says, in as many words:

   Broadcast calls use the Port Mapper RPC service to achieve their
   semantics.  See Appendix A for more information.

should sure give you a clue that it's an RPC service....

I.e., no, this isn't like an SMTP or FTP server, wherein you can just
type commands at it; it's an RPC server that's just like any other RPC
server, except that it has to have a well-known port number - after all,
it's kind of hard to ask the portmapper what the port number of the
portmapper is if you don't *already* know what its port number is.
From: lars@spectrum.CMC.COM (Lars Poulsen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Sequence Numbers in TCP/IP
Date: 26 Jan 93 07:19:09 GMT
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA

In article <andreas-220193121931@i2pc5.informatik.rwth-aachen.de>
   andreas@informatik.rwth-aachen.de (Andreas Fasbender) writes:
>What is the reason for the difference in the lenght of the window-field
>(16) and the sequence-number-field (32 bit).
>Using 16-bit-numbers for sequencing
>and acknowledging could spare 4 byte in each packet.

First, let me acknowledge that I understand the question. Since these
quantities are of the same dimension, they could be expected to be in
the same units.

(1) When the protocol was specified, the typical longhaul link speed
    was 56 kbps, and the maximum bytes-in-flight tended to work out to
    around 2000, so 64KB of window seemed adequate.
    Today, we are trying to run this across the country (300 ms round
    trip delay) on Gigabit pipes, so 64 KB of window is too little.
    An addendum to TCP allows larger windows to be specified.
(2) On a gigabit link, even the sequence numbers might wrap around
    during the packet lifetime. The "large windows" TCP extension
    includes PAWS - protection against wrapped sequence.

It would not be unreasonable to specify 64 bits for each of these fields
in a new protocol suite (or count both in frames instead of bytes - the
ISO way).
-- 
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
  CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262	
  Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256
Newsgroups: comp.protocols.tcp-ip,comp.protocols.ppp
From: liu@samui.trl.OZ.AU (Richard Liu)
Subject: tn3270 emulation over PPP or slip lines
Reply-To: r.liu@trl.oz.au
Organization: Telecom Research Labs, Melbourne, Australia
Date: Tue, 26 Jan 1993 06:00:55 GMT

  I am  asking this question on behalf of a colleague. Is it possible
to run a tn3270 block mode emulation over asynchronous dial up slip
or PPP lines ? Is this the way to go ? Is there a better option.
The requirment is to have access via dial up slip or PPP lines to 
3720 hosts as well as unix hosts.



Newsgroups: comp.protocols.tcp-ip,comp.unix.admin
From: reh@wam.umd.edu (Richard Huddleston)
Subject: Subnet Fields > 8 bits: SUMMARY
Followup-To: poster
Keywords: IP Subnet Fields, Internet IP Addressing
Organization: Workstations at Maryland, University of Maryland, College Park
Distribution: usa
Date: Fri, 29 Jan 1993 02:29:49 GMT


Summary of results/responses from my posting re: what the hell gives
with subnet masks greater than 8 bits ( on a Class A or B net ID ) ?
 
The answer, briefly, is: nothing gives.  Provided there are at least
two bits for the host IDs, you can do anything ya want.  There were
numerous caveats about which particular subnet schemes would be supported
by routing hardware; for example, non-contiguous bitmasks aren't always
supported, and neither are mixed-field-length subnets.
 
Relevant RFCs were
 
 917
 919
 922
 940
 950
 
I'd like to thank everybody who took the time to respond to my posting, and
for the high quality, as well, of the responses.  Low BS to content ratio.
 
 

-- 
Richard Huddleston
University of Maryland at College Park

Personal opinions
Newsgroups: comp.protocols.tcp-ip
From: birchall@pilot.njin.net (Shag)
Newsgroups: comp.protocols.tcp-ip,comp.windows.x
Subject: PC<->Unix connection, free/cheap?
Keywords: Xremote SLIP CSLIP not-expensive?
Date: 22 Jan 93 02:17:36 GMT
Followup-To: comp.protocols.tcp-ip
Organization: Screaming in Digital, the Queensryche Digest

My current connection:
	PC -normal dialup-> Cisco -> Sparc-II

My desired connection:
	PC -better dialup-> Cisco -> Sparc-II

I'm interested in establishing a PC-Unix connection over a dialup line,
with the connectivity listed above.  Any protocol (Xremote, SLIP, CSLIP,
maybe PPP) is an option, preference given to those which I could run an
X-server over.

I've had the opportunity to look at a few products so far:

CUTCP	-	Advantages: PD, cheap, not picky about what else it will run
		with.  Disadvantages: Not on the list of things that other
		picky programs will run with. :)

PC-Xview -	Advantages: X-windows, easy to configure.  Disadvantages: 
		Expensive, doesn't support PD connection protocols, works 
		best with X-Remote, which is also expensive.

PCTCP -		Advantages: Widely used, well known, terribly comprehensive.
		Disadvantages: Not PD, difficult to configure.

The Cisco in question currently supports X-Remote connections, but doesn't
have SLIP active.  I can bug The Powers That Be to turn on SLIP if that's my
only choice... X-windows would be very nice, though.

My PC is a '286, not capable of running Windows or Linux (sorry, for those
who were about to suggest those! ;), with 4 megs of RAM (well, it's capable
of running Windows, but I'm one of those annoying people that actually likes
software to execute at a usable speed! ;), 80mb hard drive (50mb free), VGA
greyscale, and a v.32bis/42bis (14400) modem.

Any ideas?  Throw 'em at me.

I'd really prefer e-mail responses to this (reply, don't followup), thanks...

-Shag
-- 
birchall@pilot.njin.net, shag@glia.biostr.washington.edu, birchall@njin.bitnet
  Operator of ShagNet - Rutgers/NJIN dialup access for Burlington County, NJ
     Happy and informative user of a PPI 14400 FaxModem and GeoWorks Pro
       Editor of the Queensryche E-mail Digest - "Screaming in Digital"
Newsgroups: comp.protocols.tcp-ip
From: karl@empirical.com (Karl Auerbach)
Subject: Re: Moving from coax to 10BaseT
Organization: Empirical Tools and Technologies
Date: Tue, 26 Jan 1993 03:38:09 GMT


>In a recent column in OST James Gaskin suggests that system administrators
>should be converting ethernets from coax to 10BaseT and *not* investing
>anything more in coax.  I put two questions to the readers of this group:
>
>1) Do you concur with Mr. Gaskin that coax is dead or dying?
>
>2) What options are available for small (less than a dozen nodes) networks
>currently running coax and wanting to move to 10BaseT?  For example, I
>understand that 10BaseT topology has all nodes wired to hubs - are there hubs
>available which are cost effective for small networks?

I lead the Interop "wipe out thinnet" brigade.  I strongly agree that 
thinnet should go the way of punched cards.

About the *only* remaining use for thin-net any more is where you have a 
cluster of machines, say a collection of X terminals, all in one room.  When 
we design and build Interop, that is the only way we will use cheapernet.

(We now use fiber-optic Ethernet rather than thick coax for the long runs.)

I would never run thin-net through a wall and I would never put it where 
high reliability is required.  Because coax (whether thick or thin) does not 
limit termination or shorting problems, it tends to break whenever a user 
gets it into his mind to move something.

10-Base-T, on the other hand, is much more robust.  The wire itself is more 
solid.  (And if you use the standard 4-pair stuff, you get two spare pairs, 
just in case.)  If you use level 4 or level 5 wire, you can run it quite a 
long distance.  The RJ45 connectors tend to be pretty solid, much more so 
than most coax connectors (at least with respect to how they connect to the 
cable itself.)

10-Base-T hubs also often have very nice properties -- they can block out 
screeming (jabbering) hosts, block hosts which are sending mal-formed 
packets, enforce security, etc.  They often gather interesting statistics 
about which hosts are using the net, etc.

The 10-Base-T link state light itself is worth many man-hours of saved labor 
whenever a user calls up and says "my machine isn't talking on the net."

On some hubs you can also disable retiming.  This can increase your repeater 
budget, and hence allow end-users to put in their own fan-out boxes.

			--karl--
From: art@midnight.midnight.com (Art Mellor)
Newsgroups: comp.protocols.tcp-ip
Subject: If you run 2+ nets on 1 wire, please read
Date: 26 Jan 93 15:33:37
Organization: Midnight Networks Inc., Waltham MA
Reply-To: art@midnight.com (Art Mellor 617/890-1001)
NNTP-Posting-Host: midnight.midnight.com


I've seen a lot of talk about people on the net running more than one network
on the same wire. I'd like to ask someone a bunch of possibly niave questions
and rather than waste more bandwidth, I'm asking if you do this if you could
send me your email address and let me send you my questions. Thanks.

--


...............................................................................
  Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154 
  art@midnight.com : Phone 617/890-1001 Fax 890-0028 -- Network Consulting --
From: rbz@edsr.eds.com (Rodger B Zeisler)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Info wanted on TCP/IP vs OSI 7 layer
Date: 27 Jan 93 15:44:59 GMT
Reply-To: rbz@edsr.eds.com
Organization: Electronic Data Systems

salkield@csqx.cs.rhbnc.ac.uk (Tom Salkield) writes:


>I am posting on behalf of a friend who needs to compare the layers of
>the internet protocol suite with the OSI seven layer model as part of
>his course assignment.

>I was wondering whether any reports exist, possibly available by
>anonymous ftp, on this subject ?

I just purchased a book, "TCP/IP Network Administration" by Craig Hunt.
It is a nutshell handbook from O'Reilly & Associates, Inc.  Chapter 1
is an "Overview of TCP/IP" and it explains about the 7 layer OSI standard
versus the 4 layer TCP/IP standard.


<Rodger>

+-------------------------------+-------------------------------------------+
|  Rodger B. Zeisler            |  Work Phone:  (214) 661-6241              |
|  Electronic Data Systems Corp |  Home Phone:  (214) 517-4884              |
|  7171 Forest Lane             |  INTERNET: uunet.UU.NET!edsr.eds.com!rbz  |
|  MS C210                      |        or  uunet.UU.NET!edsr!bigdaddy!rbz |
|  Dallas, TX  75230            |  COMPUSERVE:  71563,2160                  |
+-------------------------------+-------------------------------------------+
Newsgroups: comp.protocols.tcp-ip
From: jbvb@vax.ftp.com  (James B. VanBokkelen)
Subject: Re: Anyone know of a good LPR/LPD Server?
Nntp-Software: PC/TCP NNTP
Keywords: LPD servers
Reply-To: jbvb@ftp.com
Organization: FTP Software, Inc., Wakefield, MA
Date: Thu, 21 Jan 1993 10:12:08

In article <16B5BE8CE.MACE@HDQCMS2H.UTSD.ATT.COM> MACE@HDQCMS2H.UTSD.ATT.COM writes:

    We have 10 LaserJet printers which we would like to connect to a LPD
    server, for access by our OS/2, DOS/Windows and IBM VM/CMS users.
    ...
    We have looked at the Lantronix equipment, but that does not really
    offer LPD; since we have a diverse user community, we want to use the
    LPR and LPRMON software that is provided with the TCP/IP implementations.
     
A number of the DOS TCP/IP vendors offer LPD servers of varying
capabilities (B&W, Sun, FTP Software at least).  Ours is sold as a
separate product, and handles multiple simultaneous printers, spools
while printing, allows you to define multiple virtual printers with
different initializations on a single physical printer, etc. (the
same spooler is bundled into our OS/2 product).  There is also a
freeware LPD, which I think can be found on tacky.cs.olemiss.edu.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

Newsgroups: comp.protocols.tcp-ip
From: barr@pop.psu.edu (David Barr)
Subject: Re: Moving from coax to 10BaseT
Organization: Penn State Population Research Institute
Date: Mon, 25 Jan 93 13:52:28 GMT

In article <1993Jan25.095134.25886@ica.philips.nl> geertj@ica.philips.nl (Geert Jan de Groot) writes:
>Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>
>>In a recent column in OST James Gaskin suggests that system administrators
>>should be converting ethernets from coax to 10BaseT and *not* investing
>>anything more in coax.  I put two questions to the readers of this group:
>>1) Do you concur with Mr. Gaskin that coax is dead or dying?
>
>No, most certainly not. 10baseT is point-to-point. Which means that you
>have to have a separate connection between the HUB and every apparatus
>in your office. In my case, this would mean that I'd fill more than one
>hub, just for my own equipment!

	You aren't limited to single-star topolgies.  Buy small
(10-12 port) hubs and chain them together with AUI cables.  If you're
starting from scratch, 10BaseT is the way to go, IMHO.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
What does it profit a man if he gains the whole world, but still runs DOS?
Newsgroups: comp.protocols.tcp-ip
From: ronf@panther3.panther.mot.com (Ron Feigen)
Subject: Re: Determining Port Numbers & The RPC Portmapper
Organization: Motorola Panther Project, Chandler, AZ
Date: Thu, 21 Jan 1993 15:54:57 GMT

In article <1jki9vINNmr9@aludra.usc.edu> smiller@aludra.usc.edu (Stephen B. Miller) writes:
>In article <1993Jan20.162611.25831@walter.bellcore.com> maritza@espresso.bae.bellcore.com (Maritza Ramirez) writes:
>>
>>
>>I am trying to look for a solution to the problem of determining an 
>>unknown remote port number. I will appreciate any comments on the 
>>following situation:
>>
>> [text deleted, see earlier posting]
>>
>>Maritza
>>
>
>I am beginning to work an identical problem here, but have not come up with
>much more than you.  I have considered trying the dynamic update features in
>the BIND 4.8.3 code, but they are so poorly documented that I might be better
>off writing my own application.  My situation is further complicated by then
>need to change the port number assignments dynamically, which might be done
>by deregistering and reregistering with the portmapper.  If anyone else has
>ideas please feel free.....
>
>Steve Miller - smiller@aludra.usc.edu
>
>

registerrpc will register a prog#/ver# with portmapper. Portmapper assigns the
port #.  svc_unregister() removes the entry.  pmap_getport() looks up a prog#/
version# on a host.  You must of course know the host name, prog# and version#
in advance.  Be careful about having the same prog# with different version #s.
Portmapper returns the port of a program with a match on prog #, but will give
you the latest (I believe) version # if it doesn't find an exact match.

Dig through the man pages, the info is skinny but most of it is there.  There is
also a book called "The Art of Distributed Application"  by John R. Corbin.
It is supposed to give lots of detail about Portmapper  It is part of the Sun
Tech Reference Library, published by Springer-Verlag.


Ron



-- 

>
Ron Feigen
ronf@panther.mot.com
Newsgroups: comp.protocols.tcp-ip,comp.sys.sequent
From: brians@atlastele.com (Brian Sheets)
Subject: Nameserver help?
Organization: Atlas Telecom Inc.
Disclaimer: Views expressed do not necessarily represent those of my employer.
Date: Mon, 18 Jan 1993 13:00:31 GMT

I have set up a nameserver on my machine and some weird things are happening and
I was wondering if someone could help me out.

I am running Dynix 3.0.17.10  on an S3 using a dialup slip connection to PSI
The probles I see are, 1) when I lose my connection I can't seem to talk on 
my local ethernet, When I telnet in to the the system  it is very slow with 
a login  prompt. One really weird thing is that "talk" say "target machine does not 
recoginize you". This happens whenever I am using named.


Can someone help me out here???
-- 
Brian Sheets		    _   /|  	"TRUCK?! What truck?"
Support Engineer  	    \`o_O'    	 
Atlas Telecom Inc. 	      ( ) 	   -Raiders of the Lost Ark
brians@atlastele.com           U
From: kenh@leps5.phys.psu.edu (Ken Hornstein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LPR and Fortran flow control RFC 1179
Date: 27 Jan 1993 11:21:33 GMT
Organization: Penn State, Laboratory for Elementary Particle Science

In article <1993Jan26.072251.8942@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>In article <1993Jan22.170024.2775@vax1.mankato.msus.edu>
>   robin@vax1.mankato.msus.edu writes:
>>For output we get a complete printout on the host... but the fortran flow
>>control is NOT interpreted and the "1" "0" "+".. etc. are printed.
>
>The file is printed as transmitted. How would the print server host know
>that this file came from FORTRAN ?

Isn't there a code you can send using the lpr protocol that tells the
print server host that the client is using FORTRAN carriage controls?
I thought there was, but it's been a while ....

--Ken
From: ian@agranat.Agranat.com (Ian Douglas Agranat)
Newsgroups: comp.protocols.tcp-ip
Subject: IP Multicasting across routers
Date: 25 Jan 1993 19:47:10 -0500
Organization: Agranat Systems Inc.
Distribution: world
NNTP-Posting-Host: agranat.com

I am designing a proprietary application for which IP multicasting across 
routers may be desirable.  I am curious if anyone has any information regarding:

	1. Which router vendors support RFC 1112 for routing IP multicast 
	   packets across subnets?

	2. What kind of performance penalty or processing overhead is typically
	   associated with IP multicasting both within a host and within the
	   routers?

	3. What kinds of applications use IP multicasting today?  How widely
	   used are they?

	4. What policies exist for the registration of well-known IP multicast
	   addresses?

I don't have time to read this group often, so please send replies directly to
me at ian@Agranat.COM.

Any help would be greatly appreciated.


-- Ian Douglas Agranat
   Agranat Systems, Inc.
   ian@Agranat.COM
From: skibo@florida.wpd.sgi.com (Thomas Skibo)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Sequence Numbers in TCP/IP
Date: 23 Jan 93 02:45:51 GMT
Organization: Silicon Graphics, Inc.

In article <16594@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
|> >The window is how much the other end is prepared to accept (65535 implies
|> >infinite). (this is bigger than the maximum packet size on every network
|> >I have ever seen)
|> 
|> Yes, but, as far as I know, it's not required that the sending TCP stuff
|> everything into one packet, and there's a "TCP Big Window" option
|> mentioned in RFC1106, to increase the maximum window size beyond 64K. 
|> 
|> There's also an RFC, RFC1110, entitled "A Problem with the TCP Big
|> Window Option"; both date back to mid-1989, and not being a full-time
|> networking weenie, I don't know what the state of Big Windows in TCP is
|> (except that I seem to remember Vernon Schryver talking about cranking
|> the window size up when using FDDI, in order to light the fibre up, so I
|> suspect there's at least a semi-stable standard for Big Windows).

RFC 1323 is the latest RFC describing big windows.  It is basically an
update to RFC's 1072 (window scaling, time-stamps for rtt measurement,
and selective acknowledgements) and 1185 (using the same time-stamps for
rejecting old, duplicate segments).  The selective acknowledgement was
dropped from 1323 because it was felt that more research needed to be
done.

RFC 1106 was another method of getting >64K windows.  I don't know much
about it.  The problem with big windows described in RFC 1110 (that a 32-bit
sequence number isn't good enough with 30-bit windows) was addressed in RFC
1185 and refined in RFC 1323.

RFC 1323 is pretty solid.  SGI's next major OS release will include a
TCP that can do RFC 1323 (both window scaling, and time-stamps).

Vernon nearly saturates an FDDI ring with a couple of Indigos and a single
TCP connection with a 60K window (no window scaling needed).  But, he likes
to crank up the window to 128K+ to squeeze the last 0.2 MBytes/s out.
Since the "big windows" will be available soon, you'll be able to try this
at home.


-- 
---
Thomas Skibo         Advanced Networking, Silicon Graphics     skibo@sgi.com
From: cricket@hpcc01.corp.hp.com (Cricket Liu)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Why not automatically do reverse domains?
Date: 27 Jan 93 17:10:36 GMT
Organization: the foot of the ivory tower, with vertigo

William LeFebvre writes:

    There is such a tool, but it is not (yet) part of the bind
    distribution.  It's called "h2n" and is a perl script written by the
    authors of "DNS and BIND in a nutshell".  It converts a file in
    "/etc/hosts" format into the appropriate bind zone files.  Off hand, I
    don't know of an archive site that carries it.  Cricket?  You out
    there?

Sorry it's taken me so long to reply to this--my NNTP server can't decide
whether it wants me to read comp.protocols.tcp-ip.domains or not.  Some
days yes, some days no....

Anyway, h2n is available via anonymous ftp from ftp.uu.net in
/published/oreilly/nutshell/dnsbind/dns.tar.Z and from ftp.ora.com in
/pub/nutshell/dnsbind/dns.tar.Z.  As Bill mentioned, it does build both
forward and reverse mapping files from /etc/hosts, with the help of a few
command-line options.

cricket
Newsgroups: comp.protocols.tcp-ip.domains,comp.sys.dec,comp.sys.sun.admin