The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1994)
DOCUMENT: TCP-IP Distribution List for January 1994 (618 messages, 380176 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1994/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 94 06:58:44 GMT
From:      ianh@resmel.bhp.com.au (Ian Hoyle)
To:        comp.protocols.tcp-ip
Subject:   Re: Australian file transfer program - help?

jasonh@chineham.euro.csg.mot.com (Jason Haar) writes:

>Hi,
 
>Last year (1992 ;-) I heard about a program some bright spark had written in
>Aussie that allowed users to send files to each other without knowing 
>passwords (not Email/rcp/...).


Hmmm, I know what it is, but since I'm home I haven't got the doco handy :-(

It was written by Piers Lauder (piers@cs.su.oz.au) and Bob Kummerfeld at
Sydney University.

Wait ....... I just found it!!

It is on ftp.cs.su.oz.au in the directory

ftp> pwd
257 "/TCPmsg" is current directory.
ftp> ls
200 PORT command successful.
150 Opening data connection for /bsd43/bin/ls (134.18.1.6,3870) (0 bytes).
total 1021
-r--r--r--   3 1          90683 Nov 25 18:47 IPsendfile.tar.Z
-r--r--r--   3 1          90683 Nov 25 18:47 tcpmsg-1.1-tar.Z
-r--r--r--   1 1         242027 Oct 13 18:57 tcpmsg.1.1.daved.tar.Z
-r--r--r--   3 1          90683 Nov 25 18:47 tcpmsg.tar.Z


Hope that helps ......

Cheers,

	ian
-- 
   /\/\     :  Ian Hoyle,  Senior Research Scientist
  / / /\    :  BHP Research - Melbourne Laboratories
 / / /  \   :  245 Wellington Rd, Mulgrave, 3170, AUSTRALIA
/ / / /\ \  :  Phone    +61-3-560-7066
\ \/ / / /  :  E-mail   ianh@resmel.bhp.com.au
 \  / / /   :  
  \/\/\/    : "perl - the swiss army chainsaw of UNIX tools"
            :               -- Rob Kolstad

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 1994 11:32:51 +0100
From:      zok@popp.ins.de (Andreas Frackowiak)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: DOS TCP/IP as an IP GATEWAY ?

kenw@skyler.arc.ab.ca (Ken Wallewein) writes:
>In article <757205395.AA07206@compsol.fidonet.org> ben@compsol.fidonet.org (Ben Elliston) writes:
 
>    > VB:   I would like to use a PC under DOS to act as an IP GATEWAY
>    > VB: between 2 networks
>    > VB: (an Ethernet network and an ISDN network). I have to use this
 
>   Nope.  Nor can NT.  But OS/2 1.3 or better can do it.  We do just that
>   in order to backup our LANMan resources from a Unix box.
 
>   For DOS?  I don't like your chances.
 
>Asking for this functionality under DOS is pushing your luck.  Under

It is not the operating system that's important, but the application above.

We've developed the IP-SWITCH as a commercial tcp/ip router 
for DOS.  It runs fine with 640 KB but needs a 386 (we use dumb 
ISDN cards to route tcp/ip via ISDN).

We use DOS only as a kind of  "bootstrap-loader" :-)

a happy and healthy new year,
Andreas

-- 
Andreas                                        Inter Networking Systems
Frackowiak                                     Internet Services & Consulting
af@ins.de                                      FAX: +49-2305-25411
                                               info@ins.de

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Jan 1994 13:21:37 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP References in RFC1122 - where are they?

>> [TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
>>      August 1988.
>
>Are these papers available by anonymous ftp?
>If so, could someone suggest a site.

A PostScript copy of this paper is available via anonymous FTP from the host
ftp.ee.lbl.gov in the file congavoid.ps.Z.  I've never seen an ftp'able
version of Karn & Partridge.

	Rich Stevens  (rstevens@noao.edu)

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Jan 1994 10:07:53 GMT
From:      dan@gandalf (Dan Romascanu)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on the Same Interface

Michael,

This is a first answer I got on my (our) question concerning multiple
Ip interfaces.
Dan

=======================================================================


Chuck Smoko - E81 (csmoko@relay.nswc.navy.mil) wrote:
: Dan,
: I found this posting in my archives.  It describes just what you want.
: I have it working, on Sunos 4.1.X w/ some small changes.  If you want
: to runs on sunos, I can send the changes on request.
 
: 						chuck smoko
 
: PS: I am posting because your e-mail address seems hosed, and I think
: others may be interested.
 
: > From ji Mon Feb 17 17:39:51 EST 1992
: > From: ji@polaris.ctr.columbia.edu (John Ioannidis)
: Subject: Multiple IP addresses on a single Ethernet interface
: Date: 13 Feb 92 19:33:56 GMT
: Status: OR
 
: This is a topic that comes up once in a while on comp.protocols.tcp-ip
: and other newsgroups. The question is, how to get a machine with one
: network interface to respond to more than one IP addresses.
 
: The other day, a colleague forwarded to me a request from the
: namedroppers mailing list for exactly that. Here's my response:
 
: > In article <1992Feb1.082712.18549@mahler.ntt.jp> hitoaki@mahler.ntt.jp (Hitoaki Sakamoto) writes:
: >    >In article <216@pivot.sbi.com> jordan@pivot.sbi.com (kuo-lin Hu) writes:
: >    > >But it is just out of my curiousity that whether it is possible
: >    > >I can assign dual IP addresses to a single controller?
 
: >    >No,you can't.
: >
: > Is this restriction common among UNIX TCP/IP implementations?
: > Has anybody tried to modify this?
: >
: > -- Kenji
: > --
: > Kenji Rikitake
: > kenji@macrofield.or.jp // kenji@macrofield.org // ...!uunet!reseau!kenji
 
: I have a solution than might suit you.  For my doctoral work (there's
: a paper about it in this year's ('91) SIGCOMM, also available for
: anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm*.ps.Z), I've
: developed what I call the "Virtual Interface" (VIF). To the networking
: code, it looks like an interface. It gets ifattach()ed when you open
: the /dev/vif* device, and then you can ifconfig it as you like. It
: does not have an if_input procedure; it only has an if_output. Packets
: that it receives (from higher-level protocols) which have its
: IP address, it simply loops back (like any well-behaved if driver).
: Packets that it receives that are destined for some other address, it
: encapsulates in an encapsulation protocol I call IPIP (IP-within-IP,
: protocol number IPPROTO_IPIP == 94), and sends it to another machine
: that groks that encapsulation protocol. This feature you won't need,
: but here's how to have multiple IP addresses on a machine with a
: single real interface:
 
: Let's say your primary interface's IP address is 198.3.2.1, and you
: also want it to respond to addresses 198.4.3.2 and 198.5.4.3 (note
: that these are three distinct class C addresses in three distinct
: class C nets). Here are the ifconfigs:
 
:   ifconfig le0 198.3.2.1 up -trailers	# config primary interface
 
:   ifconfig vif0 198.4.3.2 up 		# config first virtual interface
:   route delete net 198.4.3 198.4.3.2	# delete spurious route
:   route add host 198.4.3.2 198.4.3.2 0	# add route for this i/f
 
:   ifconfig vif1 198.5.4.3 up		# config second virtual interface
:   route delete net 198.5.4 198.5.4.3	# delete spurious route
:   route add host 198.5.4.3 198.5.4.3 0	# add route for this i/f
 
: The route deletes are needed because the ifconfig creates a default
: route to the interface's network, which can cause problems; all that's
: needed is the (host) route to the interface's address.
 
: Now, get le0's ethernet address (say, 8:0:20:3:2:1), and add the
: following static ARP entries:
 
:   arp -s 198.4.3.2 8:0:20:3:2:1 pub
:   arp -s 198.5.4.3 8:0:20:3:2:1 pub
 
: This will cause any ARP requests for the VIF addresses to be replied
: with your machine's ethernet address.
 
: Now, make sure your default route is to your segment's gateway,
: throught the real interface. FInally, make sure your routers and/or
: hosts on the same segment as yours know that 198.4.3.2 and 198.5.4.3
: are on that cable.
 
: Here's what you've accomplished.
 
: ARP requests for any of your host's addresses will be replied to with
: the host's ethernet address (the real one, because that's what it is,
: the virtual ones because of the public static arp entries). Packets
: reaching your host with any of these addresses will be accepted by the
: ip_input routine because they match the address of one of the host's
: interfaces. Packets leaving your host can have any of its addresses
: (real and virtual).
 
: The code for vif follows. To use it, put the stuff in netinet/if_vif.c
: and netinet/if_vif.h, configure your kernel with the number of
: virtual interfaces you want using a line like:
 
: pseudo-device	vif4		# Virtual IP interface
 
: in your configuration file, and two lines like
 
: netinet/if_vif.c	optional vif device-driver
: netinet/if_vif.hc	optional vif device-driver
 
: in the files file. Also, add the appropriate entries in conf.c, so
: that you can access the if_attach() routine when you open the device:


: ------------------------in conf.c------------------------------------------
 
: add this in the appropriate place in the headers of conf.c:
 
: --------------------
: #include "vif.h"
: #if NVIF > 0
: int	vifopen(), vifclose(), vifread(), vifwrite(), vifselect(), vifioctl();
: #else
: #define vifopen		nodev
: #define vifclose	nodev
: #define vifread		nodev
: #define vifwrite	nodev
: #define vifselect	nodev
: #define vifioctl	nodev
: #endif
: --------------------
 
: then, way down in the definition for cdevsw[]:
 
: --------------------
: 	vifopen,	vifclose,	vifread,	vifwrite,	/*31*/
: 	vifioctl,	nodev,		nodev,		0,
: 	vifselect,	nodev,
: --------------------
 
: Make sure you remember the correct major device number!
 
: ------------------------in conf.c------------------------------------------
 
: Finally, here's the code. It has the tunneling pieces removed (you
: need more code to use that anyway), and it comes from a Mach 2.6
: kernel; it should compile on any berkeley-derived unix with minor
: changes (most likely only in the includes).
 
: ---------------------netinet/if_vif.h--------------------------------------
: typedef struct
: {
: 	struct ifnet	vif_if;
: 	struct ifnet	*vif_sif;	/* slave interface */
: 	int		vif_flags;
: } vif_softc_t;
 
: #define	VIFMTU	(1024+512)
: ---------------------------------------------------------------------------
 
: and
: ---------------------netinet/if_vif.h--------------------------------------
: /*
:  * HISTORY
:  * $Log:$
:  */
 
: /*
:  * $Header:$
:  *
:  * Virtual IP interface module.
:  */
 
: #include <multicast.h>
 
: #include "param.h"
: #include "systm.h"
: #include "mbuf.h"
: #include "socket.h"
: #include "errno.h"
: #include "ioctl.h"
 
: #include "../net/if.h"
: #include "../net/netisr.h"
: #include "../net/route.h"
 
: #ifndef MACH
: #include "../machine/mtpr.h"
: #endif
 
: #ifdef	INET
: #include "../netinet/in.h"
: #include "../netinet/in_systm.h"
: #include "../netinet/in_var.h"
: #include "../netinet/ip.h"
: #endif
 
: #ifdef NS
: #include "../netns/ns.h"
: #include "../netns/ns_if.h"
: #endif
 
: #include "in_pcb.h"
 
: #include "ip_var.h"
: #include "ipip.h"
: #include "ipip_var.h"
: #include "micp.h"
: #include "micp_var.h"
 
: #include "if_vif.h"
: #include "vif.h"
 
: vif_softc_t vif_softc[NVIF];
 
: int vifs_inited = 0;
 
: int	vifoutput(), vififioctl();
 
: vifattach()
: {
: 	register int i;
: 	register struct ifnet *ifp;
: 	
: 	for (i=0; i<NVIF; i++)
: 	{
: 		ifp = &vif_softc[i].vif_if;
: 		ifp->if_name = "vif";
: 		ifp->if_unit = i;
: 		ifp->if_mtu = VIFMTU;
: #if	MULTICAST
: 		ifp->if_flags = IFF_MULTICAST | IFF_NOARP;
: #else	MULTICAST
: 		ifp->if_flags = IFF_NOARP;
: #endif	MULTICAST
: 		ifp->if_ioctl = vififioctl;
: 		ifp->if_output = vifoutput;
: 		if_attach(ifp);
: 	}
: }
 
: vifopen(dev, flag)
: int dev, flag;
: {
: 	int unit;
: 	
: 	if (!vifs_inited)
: 	{
: 		vifattach();
: 		vifs_inited = 1;
: 		printf("vif initialized\n");
: 	}
: 	
: 	unit = minor(dev);
: 	if ((unit < 0) || (unit >= NVIF))
: 	{
: 		return ENXIO;
: 	}
: 	
: 	return 0;
: }
 
: vifclose(dev, flag)
: int dev, flag;
: {
: 	return 0;
: }
 
: vifread()
: {
: 	return ENXIO;
: }
 
: vifwrite()
: {
: 	return ENXIO;
: }
 
: vifselect()
: {
: 	return ENXIO;
: }
 
: vifoutput(ifp, m0, dst)
: 	struct ifnet *ifp;
: 	register struct mbuf *m0;
: 	struct sockaddr *dst;
: {
: 	int s;
: 	register struct ifqueue *ifq;
: 	struct mbuf *m;
: 	struct sockaddr_in *din;
: 	
: 	if (dst->sa_family != AF_INET)
: 	{
: 		printf("%s%d: can't handle af%d\n",
: 		       ifp->if_name, ifp->if_unit,
: 		       dst->sa_family);
: 		m_freem(m0);
: 		return (EAFNOSUPPORT);
: 	}
 
: 	din = (struct sockaddr_in *)dst;
: 	
: 	if (din->sin_addr.s_addr == IA_SIN(ifp->if_addrlist)->sin_addr.s_addr)
: 	{
: 		printf("%s%d: looping\n", ifp->if_name, ifp->if_unit);
: 		
: 		/*
: 		 * Place interface pointer before the data
: 		 * for the receiving protocol.
: 		 */
: 		if (m0->m_off <= MMAXOFF &&
: 		    m0->m_off >= MMINOFF + sizeof(struct ifnet *)) {
: 			m0->m_off -= sizeof(struct ifnet *);
: 			m0->m_len += sizeof(struct ifnet *);
: 		} else {
: 			MGET(m, M_DONTWAIT, MT_HEADER);
: 			if (m == (struct mbuf *)0)
: 			  return (ENOBUFS);
: 			m->m_off = MMINOFF;
: 			m->m_len = sizeof(struct ifnet *);
: 			m->m_next = m0;
: 			m0 = m;
: 		}
: 		*(mtod(m0, struct ifnet **)) = ifp;
: 		s = splimp();
: 		ifp->if_opackets++;
: 		ifq = &ipintrq;
: 		if (IF_QFULL(ifq)) {
: 			IF_DROP(ifq);
: 			m_freem(m0);
: 			splx(s);
: 			return (ENOBUFS);
: 		}
: 		IF_ENQUEUE(ifq, m0);
: 		schednetisr(NETISR_IP);
: 		ifp->if_ipackets++;
: 		splx(s);
: 		return (0);
: 	}
 
 return EHOSTUNREACH;
: }
 
: /*
:  * Process an ioctl request.
:  */
: /* ARGSUSED */
: vififioctl(ifp, cmd, data)
: 	register struct ifnet *ifp;
: 	int cmd;
: 	caddr_t data;
: {
: 	int error = 0;
 
: 	switch (cmd) {
 
: 	case SIOCSIFADDR:
: 		ifp->if_flags |= IFF_UP;
: 		/*
: 		 * Everything else is done at a higher level.
: 		 */
: 		break;
 
: 	default:
: 		error = EINVAL;
: 	}
 return (error);
: }
 
: vifioctl(dev, cmd, arg, mode)
: dev_t dev;
: int cmd;
: caddr_t arg;
: int mode;
: {
: 	int unit;
: 	
: 	unit = minor(dev);
: 	if ((unit < 0) || (unit >= NVIF))
: 	  return ENXIO;
: 	
: 	return EINVAL;
: }
: ----------------------------------------------------------------------------
 
: To use it, compile your kernel, and reboot. Then create the vif
: device:
 
: # mknod /dev/vif c 31 0
 
: (or whatever major number it ended up being), and echo something into
: it:
 
: # echo > /dev/vif
 
: This will cause the device to be opened, which will if_attach the
: interfaces. If you feel like playing with the code, you may want to
: kmem_alloc() the vif_softc structrure at open time, and use the minor
: number of the device to tell it how many interfaces to create.
 
: Now you can go ahead and ifconfig etc.
 
: I'll be happy to answer minor questions, and hear about success and
: failure stories, but I cannot help you if you don't already know how
: to hack kernels.
 
: Good luck!
 
: /ji
 
: In-Real-Life: John "Heldenprogrammer" Ioannidis
: E-Mail-To: ji@cs.columbia.edu
: V-Mail-To: +1 212 854 8120

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 94 12:31:52 GMT
From:      bill@banana.dis.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   Can telnet report origin?

Is it possible to find out where a telnet session originates?  I have an
application that needs to report the IP address and TCP port number of
the device that originated the telnet session.

The scenario would be:

1) a user telnets to a host
2) the user runs a particular application
3) the application determines the originating IP address and TCP port.
4) the application logs the origin info
5) the user goes merrily about his way

Any help would be greatly appreciated.

Thanks,

bill daniels
-- 
these ravings are in no way sanctioned by federal express corp
bill daniels                    | voice:  (901)797-6328
federal express corp            | fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.dis.fedex.com

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Jan 1994 18:07:47 GMT
From:      stanf@cscns.com (Stan F./ InfoTec Development)
To:        comp.protocols.tcp-ip
Subject:   TELNET/LINUX/BBS

  Have a situation that I would like to drop in the net and see if anyone
has come across a configuration like this, or would know how to set it up.
I run a BBS on a DOS system where I would like to allow user access to my
LINUX box.  The networking proper is all set up.  I can load the CRYNWR
drivers, and successfully telnet to the LINUX box using the NCSA Telnet
software from the DOS prompt.
  Calling in though, I can't seem to get the configuration right to route
telnet i/o on the BBS computer through the comm port.  I tried the -n and
-t options, but no change.

  Any help with this would be appreciated.

___ Blue Wave/QWK v2.12
                                                                                                                               
-- 
=====================================================================
Stan Foy				internet: stanf@cscsn.com
Infotec Development INC.       		 fidonet: 1:128/128
4575 Galley Road, Suite 100   		   phone: (719)574-9991

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 00:53:29 GMT
From:      morley@suncad.camosun.bc.ca (Mark Morley)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET/LINUX/BBS

Stan F./ InfoTec Development (stanf@cscns.com) wrote:
>   Have a situation that I would like to drop in the net and see if anyone
> has come across a configuration like this, or would know how to set it up.
> I run a BBS on a DOS system where I would like to allow user access to my
> LINUX box.  The networking proper is all set up.  I can load the CRYNWR
> drivers, and successfully telnet to the LINUX box using the NCSA Telnet
> software from the DOS prompt.
>   Calling in though, I can't seem to get the configuration right to route
> telnet i/o on the BBS computer through the comm port.  I tried the -n and
> -t options, but no change.
 
>   Any help with this would be appreciated.

Try FTP'ing my Indoors/TELNET door from suncad.camosun.bc.ca in the
/pub/morley directlry (IDTEL*.ZIP).

This is a proper BBS door that implements Telnet for BBS's.  It uses
packet drivers on the network side, and FOSSIL drivers on the comm port
side.  It allows you to set up a menu of telnet sites, or have it
automatically telnet to a particular site apon invocation.  Lot's of
features and it works with most DOS BBS's that support DOOR.SYS, CHAN.TXT,
DORINFO?.DAT, etc. dropfiles.

There should be a new version coming out in the next couple of weeks as well.

Mark

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 1994 13:46:10 -0600
From:      baji@bnr.ca (Baji Edupuganty)
To:        comp.protocols.tcp-ip
Subject:   Hashing of IP addresses


I'm working on an application that will key off of IP addresses; therefore
I'm looking for a hash alg. that will hash IP addresses to something in the
range 2000. Anyone, know of any PD algs, or code that I can leverage? Any 
help will be appreciated. My e-mail addr is "baji@bnr.ca". Thank you.



-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 07:05:05 GMT
From:      gmvu@pool.info.sunyit.edu (Monali Ullal)
To:        comp.protocols.tcp-ip
Subject:   IPC using TLI: question about TCP under SunOS


This is for a friend, I hope the reply-tp takes care of it..

Ive been trying to use TLI under SunOS 4.1.3. In going over the tutorial
on advanced IPC using TLI in the answerbook, I found suggested server
addresses like "1" or "server" as the name associations.
 
Such server addresses seem to fail for TCP which is the only available
transport on the system.
 
 
I get the following runtime error:
 
: t_bind failed for listen_fd: Incorrect address format
 
Any pointers to more documentation on TLI using TCP will be helpful?

Thanks is advance.
Shyam Kamadolli
Kaman Sciences Corp

shyam@kaman.com



-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1994 01:56:05 -0800
From:      c2a192@rick.cs.ubc.ca (Kazimir Kylheku)
To:        comp.protocols.tcp-ip
Subject:   Re: Two PC Network... :-((

In article <2fj0poINNbi7@owl.csrv.uidaho.edu>,
Harrington <harri906@crow.csrv.uidaho.edu> wrote:
>HELP ME!
>	I am having trouble with networking my two computers here at our 
>home...
>I have a paralell ports connected by a paralell cable, the CRYNWR PLIP 
>driver (paralell port packet driver that supports ETERNET CODING) and 
>little else... 
>I know about things such as CUTCP, WATTCP etc but HOW do you set it up???
>all they are talking about are things like "ask your sysadmin about 
>nameservers and ip addresses"....
>WHAT IF I AM THE "SYSADMIN"????
>HELP!
>Thanks a LOT!
>Dan Harrington

I presume that two-way links implemented using the centronics parallel
printer interface are not symmetric, since the interface was designed
for one-way communication between a computer and a printer, I think.
Thus each packet driver needs to know whether it's a "printer end" or
a "computer end".

Once that is sorted out, and you have the packet drivers running on
both machines, you need some software that will use these drivers to
perform something useful.

I use a package from NCSA that includes an MS-DOS version of telnet,
ftp, rexec, finger and others. The telnet program also has a built-in
FTP server that allows a remote machine to FTP "into" my PC.

To find a site that has the NCSA package, try using archie:

   telnet archie.rutgers.edu
   login: archie
   type the command "prog ncsa"
   capture the list that you get, choose a site, and get the goodies!

The NCSA package needs a bit of configuring to work. Using the
CONFIG.TEL file, you can arbitrarily assign an IP address to each
machine, and specify the other machine's IP as a host. In the config
file there are other options as well. For instance, to have the telnet
program TELBIN.EXE also start up the FTP server in the background, you
need to have the command "ftp=on" in the CONFIG.TEL file. Then, you
can start up telnet on one side, and use "ftp
<ip_address_of_other_machine>" to make an ftp connection. Of course,
you need to define at least one username/password in the special ftp
password file... These kinds of configurations are accompanied by
a myriad of details, needless to say!

The NCSA package is quite boring, because the only server-mode program
they offer is the ftp. In other words, it could offer you MS-DOS file
transfers over the parallel port - an area that is already covered by
programs dedicated to that purpose, although I'd personally get a lot
more gratification from TCP/IP! All the other NCSA programs that I
have are clients that are not useful unless you connect to a host that
offers supporting services.

You might consider experimenting with the Linux operating system if
you'd liketo more fully network the two machines together. 






-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 94 15:38:14 GMT
From:      lparsons@exlogcorp.exlog.com (Lee Parsons)
To:        comp.protocols.tcp-ip
Subject:   Practical Network Trouble Shooting Books

I saw the Unix and TCP/IP book by Quarterman and Leffler the other
day and at first glance was impressed by the Network Debugging 
Chapter. I realized that I haven't seen too many books that talk 
much about actually finding a problem on the wire. 

My impression of most books on the market is that they spend 300
pages reprinting RFCs and then take 10 pages to say "Then you use
ping and netstat to find the problem."

Is that a fair assement of the state of TCP Books on the market?
Am I over looking a better reference?
-- 
Regards, 

Lee E. Parsons                  		Baker Hughes Inteq, Inc
Oracle Database Administrator 			lparsons@exlog.com 

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 1994 16:39:28 GMT
From:      gagrawal@cs.tamu.edu (Gopal Agrawal)
To:        comp.protocols.tcp-ip
Subject:   Re: Need ttcp code for Fddi on Solaris 2.x

 We have a couple of cisco fddi cards running on Sparc Classic 
 stations (Solaris 2.x).  The ttcp code for testing them is 
 apparently different from the ones that I could find
 in the public domain. I guess they use DLPI commands or 
 some such things (I'm not yet a networking guru).  The 
 ttcp was originally implemented at the US Army Ballistics
 Reseach Lab. 
 
 Does anyone know if the source code for it exists in 
 public domain (and where) ? 
 
regards,
--   
    ______ ______ ______ ______ __  |\/\/\/|
     ____/  __  /  __  /  __  /  /  |  \  /|  LIFE's COMPLEX - IT HAS
    / __   /   /  /   /  /   /  /   | (o)(o)  REAL & IMAGINARY PARTS.
   /   /  /   /   ___/  __  /  /    C      _) 
 _____/ _____/ __/   __/ __/ ______/ | \___|  
 E-mail - gagrawal@cs.tamu.edu       |   /   All Std. Disclaimers apply.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 17:07:44 GMT
From:      shotokan@diku.dk (Kim H|glund)
To:        comp.protocols.tcp-ip
Subject:   Re: Practical Network Trouble Shooting Books

lparsons@exlogcorp.exlog.com (Lee Parsons) writes:
>I saw the Unix and TCP/IP book by Quarterman and Leffler the other
>day and at first glance was impressed by the Network Debugging 
>Chapter. I realized that I haven't seen too many books that talk 
>much about actually finding a problem on the wire. 
>
>My impression of most books on the market is that they spend 300
>pages reprinting RFCs and then take 10 pages to say "Then you use
>ping and netstat to find the problem."
>
>Is that a fair assement of the state of TCP Books on the market?
>Am I over looking a better reference?

I think you're right: most books on TCP/IP concentrate on how the protocols
are supposed to work and talk little or not at all about how you go about
handling problems with your network.  I have, however, recently come across
a book that looked promising:

  Troubleshooting TCP/IP -- Analyzing the Protocols of the Internet
  by Mark A. Miller
  M&T Books, ISBN 0-13-953167-X
  588 pages

It is co-published for sale outside North America by Prentice Hall
International.  It seems that the author uses a lot of case studies with
output from a Sniffer Network Analyzer to illustrate how actual problems
are tracked down.

I have not read this book but would like to see comments from others who
have.

--Kim

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 18:40:46 GMT
From:      craigp@world.std.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP References in RFC1122 - where are they?

In <757377952snz@sirius.demon.co.uk> dhaslam@sirius.demon.co.uk (David Haslam) writes:

>RFC1122 refers to the following papers:
 
>> [TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
>>      SIGCOMM-87, August 1987.

The paper has not historically been on-line due to ACM copyright issues.
However, re-reading the copyright notice this morning, I realized I am allowed
to make copies available provided I include some copyright information.
So I've touched up the paper to include the copyright info and it is
available as:

    sics.se:pub/craig/karn-partridge.ps (just 65K -- not worth compressing)

Craig

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 1994 19:33:22 GMT
From:      ewu@agsm.ucla.edu (Eric Wu)
To:        comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Need solutions for bootp on IBM Token Ring network

Hi Everyone,

We have a PC lab using IBMTOKEN.COM, ethernet packet driver for IBM token
ring network.  We also use IBM 8209 bridge to bridge between token ring 
and ethernet network.  Due to the need of news reader, gopher, 
and mosaic for windows client software for students, we tried to use
bootp in the token-ring PC lab.  The bootp server is running on an Unix 
machine(ethernet).  Our problem is the bootp server receives the request from
client and broadcasts out the information, but the PC client software 
never receives any information back from the bootp server.  

I am sure that I have correct entries in the bootptab file.  Please send
any suggestion or comment to my e-mail address.

Thank you.


--
     _/      _/_/_/_/_/ _/_/_/_/ _/      _/ Eric Wu
   _/ _/    _/         _/       _/_/  _/_/ tel: +1 310 825 8399
  _/_/_/   _/  _/_/_/ _/_/_/_/ _/  _/  _/ fax: +1 310 825 4835
 _/   _/  _/      _/       _/ _/      _/ internet: ewu@anderson.ucla.edu

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Jan 1994 21:46:00 GMT
From:      mark@cyantic.com (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: Practical Network Trouble Shooting Books

In article <1994Jan3.170744.18684@odin.diku.dk> shotokan@diku.dk (Kim H|glund) writes:
>lparsons@exlogcorp.exlog.com (Lee Parsons) writes:
>>I saw the Unix and TCP/IP book by Quarterman and Leffler the other
>>day and at first glance was impressed by the Network Debugging 
>>Chapter. I realized that I haven't seen too many books that talk 
>>much about actually finding a problem on the wire. 
>>
>I think you're right: most books on TCP/IP concentrate on how the protocols
>are supposed to work and talk little or not at all about how you go about
>handling problems with your network.  I have, however, recently come across
>a book that looked promising:
>
>  Troubleshooting TCP/IP -- Analyzing the Protocols of the Internet
>  by Mark A. Miller
>  M&T Books, ISBN 0-13-953167-X
>  588 pages
>
>It is co-published for sale outside North America by Prentice Hall
>International.  It seems that the author uses a lot of case studies with
>output from a Sniffer Network Analyzer to illustrate how actual problems
>are tracked down.
>
>I have not read this book but would like to see comments from others who
>have.

I have Miller's book and have used it as a reference a few times over the
last few months.  It is loaded with technical information on protocols and
so forth, which I believe must be the foundation for any debugging process.

It has proved useful when I needed it. The reference sections and indexes
can be very informative. I don't think you'd curl up in front of a
fireplace with this one though.
-- 

Mark T. Dornfeld, CYANTIC Systems             Voice: (416) 234-9048
101 Subway Crescent Suite 2103                Facsimile: (416) 234-0477
Etobicoke, Ontario, M9B 6K4 CANADA            Email: mark@cyantic.com

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 23:22:30 GMT
From:      nectar@world.std.com (Nectar Nirvana)
To:        comp.sys.novell,comp.protocol.tcp-ip
Subject:   RIP and LAN Workplace for DOS

Why doesn't Novell's LAN Workplace for DOS support RIP?  Is there
anything out there that will let it support RIP?

How else can a PC running LAN Workplace for DOS determine the correct
route for an IP packet?  It seems I can't even set up static routes ...
only a default router.  What if that router goes down?

Any suggestions/comments welcome!

----
Nectar Nivrana --><--   | It's not what you see, so much as it's
nectar@world.std.com    |   how you see it ...
E-mail me for a free lobotomy consultation!

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Tue,  4 Jan 94 10:56:00 -0640
From:      john.will@satalink.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Two PC Network... :-(

C >I presume that two-way links implemented using the centronics parallel
C >printer interface are not symmetric, since the interface was designed
C >for one-way communication between a computer and a printer, I think.
C >Thus each packet driver needs to know whether it's a "printer end" or
C >a "computer end".

Actually, you assume incorrectly. :-)  They use 5 bits of handshake 
signal lines for the input on each side, and they are symmetrical.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 03:16:11 GMT
From:      nectar@world.std.com (Nectar Nirvana)
To:        comp.protocols.tcp-ip
Subject:   Frame types!

Could somebody please explain to me the relationship of the following
frame types and maybe the merits of each? e.g. which ones are standardized,
which ones are _de facto_ standards, which ones work with TCP/IP, IPX/SPX.
And if I missed some (Token Ring & Ethernet are all I'm trying to list here), 
please add'em in!

Much appreciated!

Token Ring:
        Token Ring 802.5, Token Ring SNAP, Token Ring 802.2?
Ethernet:
        Ethernet II, Ethernet 802.3, Ethernet 802.2

----
Nectar Nivrana --><--   | It's not what you see, so much as it's
nectar@world.std.com    |   how you see it ...
E-mail me for a free lobotomy consultation!

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1994 17:00:10 -0800
From:      c2a192@rick.cs.ubc.ca (Kazimir Kylheku)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET/LINUX/BBS

In article <CJ0L0z.4xp@cscns.com>,
Stan F./ InfoTec Development <stanf@cscns.com> wrote:
>  Have a situation that I would like to drop in the net and see if anyone
>has come across a configuration like this, or would know how to set it up.
>I run a BBS on a DOS system where I would like to allow user access to my
>LINUX box.  The networking proper is all set up.  I can load the CRYNWR
>drivers, and successfully telnet to the LINUX box using the NCSA Telnet
>software from the DOS prompt.
>  Calling in though, I can't seem to get the configuration right to route
>telnet i/o on the BBS computer through the comm port.  I tried the -n and
>-t options, but no change.
>
>  Any help with this would be appreciated.

I have NCSA Telnet as well. It's just like most MS-DOG programs,
because it displays its output through direct screen writes, or
optionally through the BIOS calls (to suppress snowing on the old CGA
adapters).  Unless the NCSA Telnet program has some option somewhere
to redirect its output, you will have to get yourself another Telnet!
Either that, or use some sort of remote-access software that will map
the screen buffer of your BBS machine to the user's screen over the
modem.  (I have used PCAnywhere once to access a Novell LAN this way).
I think the choice here is quite clear! Dump the Telnet program!

- Kaz


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1994 13:43:39 GMT
From:      derek@shadow.fulcrum (Derek Jean-baptiste)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or

In article 2D2485E0@biochemistry.cwru.edu, ashok@biochemistry.cwru.edu (Ashok Aiyar) writes:

>CSLIPPER is a packet driver.  Any TCP stack that supports the packet driver
>interface will work over CSLIPPER.
>
>The more appropriate question perhaps is whether Novell LWP and B&W support
>packet drivers.  I believe that the latter does, but am not sure about the
>former.
>
>Later,
>Ashok
O.K.,
	Does anyone know if B&W or Novell support packet
drivers?
Derek
---

 [The Above Opinions are MY OWN and NOT those of Salomon Bothers]
---------------------------------------------------------------------------
Derek Jean - Baptiste					"...End Racism..."
----------------------------------------------------------------------------
US Postal Mail		|E-Mail				|Phone
Salomon Brothers	|Zip	:derekj			|Work:(212) 783-1572
7WTC			|Salomon:derekj@zip		|FAX :(212) 783-4838
N.Y., NY. 10048		|I-net	:djeanbaptiste@sbi.com	|Beep:(212) 646-7200


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 15:27:51 GMT
From:      rjberke@berke.itg.ti.com (Richard Berke)
To:        comp.protocols.tcp-ip
Subject:   Multiple subnets, advertising them via RIP

I'm confused about router configurations to serve multiple subnets on an 
interface.  I need clarification of either standard practices, pointers to 
RFC's, or just the benefits of others' experience:

We have large sites with 800+ TCP/IP enabled workstations, for which we've 
allocated subnets using the full octet.  Networks are xxx.yyy.1, xxx.yyy.2,
etc. with netmask of 255.255.255.0.  We need help with our routers to enable 
the UNIX workstations to learn via RIP which networks exist and the appropriate 
routers to aim through.  We DON'T want to have to manually configure each 
workstation with one or more default gateways.  We're concerned about excess 
overhead of RIP packet broadcasts - we have over 150 nets of either other 
subnetted class B, or class C, and RIP therefore uses multiple packets per 
cycle of advertising routes.

Other sites ---+
               |
             Router A    UNIX 1      UNIX 2
               |           |           |
    -----ethernet A--------+-----+-----+-------
                                 |
                               Router B
                                 |
    -----ethernet B--------------+-----+-------
                                       |
                                     UNIX 3

UNIX 1 and 2 above are in separate subnets logically, and both need to 
communicate with UNIX 3 and other sites.  Router A has multiple addresses 
on its interface.  Router B has just one address so far.  What should Router A 
and B advertise on ethernet A?

Should Router A advertise just 'Other sites' on ethernet A, and to both 
broadcast addresses of nets listened to by UNIX 1 and UNIX 2?  Should Router B 
advertise on ethernet A only the nets it routes to on ethernet B, and advertise 
all networks it knows of to ethernet B which UNIX 3 listens to?  Should router 
A advertise on ethernet A that he knows of router B's attached nets?  

If router A doesn't supply advertisement to all its subnets on ethernet A, then 
UNIX 1 and UNIX 2 won't know they can reach them.  If router B is in only one 
of the subnets, then router A must tell UNIX 1 and 2 how to reach UNIX 3.

This get's even more complex when router B actually has other sites attached. 
Should it have multiple addresses on ethernet A and advertise which routes, 
across both addresses?

I think I understand that common router implementations only use one address 
for advertisement, and all additional-network customer UNIX stations get 
configured to default to the router's other addresses.  I think this is what's 
meant by 'split horizons'.   I need help to understand better.

Thanks,
Richard Berke
Texas Instruments
Richard.Berke@lobby.ti.com
Richard Berke   RBRK   Richard.Berke@lobby.ti.com  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 94 20:54:01 EDT
From:      mckee@pacs.sunbelt.net
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for PD TCP/IP for VAX/VMS

In article <1994Jan4.194646.7063@tolten.puc.cl>, ostertag@orden.cl (Eduardo Ostertag) writes:
> Hi there:
> 
> I'm looking for a public domain version of TCP/IP for
> VAX/VMS. Either source code or binary is OK. Any pointers
> would be greatly appreciated. Please reply by mail.
> 
> Thanks in advance,
> 
> Eduardo Ostertag
> ostertag@orden.cl

Look in ftp.sunbelt.net directory [anonymous.vms.????] for the CMUIP package.

This is probably not the latest version, you will need to read the newsgroup
in vmsnet.tcpip.cmu... something or another like that anyway.

Tim McKee

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 17:53:53 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Frame types!

In article <xzDAjq$Op7K7yarn@world.std.com> nectar@world.std.com writes:
>Could somebody please explain to me the relationship of the following
>frame types and maybe the merits of each? e.g. which ones are standardized,
>which ones are _de facto_ standards, which ones work with TCP/IP, IPX/SPX.
>And if I missed some (Token Ring & Ethernet are all I'm trying to list here), 
>please add'em in!
>
>Much appreciated!
>
>Token Ring:
>        Token Ring 802.5, Token Ring SNAP, Token Ring 802.2?
>Ethernet:
>        Ethernet II, Ethernet 802.3, Ethernet 802.2

Ethernet II is the current state of the original Ethernet as standarized by
DEC, Intel and Xerox (DIX).  IEEE later specified standards for LAN access
protocols (802.X).  All of the MAC layers standardized by IEEE (.3, .4, .5)
are SUPPOSED to use the 802.2 Logical Link Control (LLC) protocol to identify
next higher level clients.  Since LLC has very limited addressing space,
(effectively 6 bits), it is extremely hard to get standard LLC LSAP values
assigned.  This led to the development of an extended mechanism to allow
greatly expanded flexibility in demultiplexing.  This new mechanism is the
SubNet Access Protocol (SNAP), which is technically a new sublayer identified
by a specific LLC LSAP value (0xaa).  SNAP introduces a field to identify the
assignment authority and a protocol type under that authority.  By convention,
the use of zero for the assignment authority (OUI) identifies the protocol
types to be those administered by Xerox for Ethernet II.  Ethernet II and
802.3 are electrically compatible, but differ slightly in the packet headers.
Ethernet II has a protocol type field where 802.3 has a length field.  Ethernet
II also does not use LLC whereas 802.3 is supposed to.  Since valid 802.3
lengths have a limited range and most Xerox assigned protocol codes were above
that, Xerox agreed to reassign the small number that conflicted.  Thus both
Ethernet II and 802.3/802.2 packets can be carried on the same cable and are
distinguished by the value in the type/length field.

There is one big exception though.  Novell netware was being implemented before
the standards were set, and ended up using 803.3 WITHOUT 802.2 LLC.  This is
often called "RAW IPX" mode.  Luckily?, IPX also always ran with the IPX
checksum turned off.  This (by chance) caused the first two bytes of the IPX
headet to be all 1s.  Since this is where where the LLC LSAP fields are, these
packets can be distinguished as a special case of LSAP values which would not
normally be found.  This raw mode was the default for Netware out of the box
until recently with Netware 4.X.  I believe as of Netware 4.X, Ethernet interfaces
can be configured to use Ethernet II, 802.3/raw, 802.3/802.2 or 802.3/802.2/SNAP,
with 802.3/802.2 the default.

Virtually all IP implementations on Ethernet use Ethernet II encapsulation.
Only a few use 802.3/802.2, including ISO CLNP (and maybe IBM SNA?).  A few
use 802.3/802.2/SNAP, including Appletalk Phase-2.

On token ring, most protocols seem the use SNAP, to be able to use the same
protocol code they use on Ethernets.  IP (and ARP) on TR use SNAP.  IPX can
be configured to use 802.5/802.2 with an LSAP that is not standarized with
the IEEE, or can be configured to use 802.5/802.2/SNAP with the Ethertype
that they use on Ethernets.  Appletalk used 802.5/802.2/SNAP, but ISO CLNP
and IBM SNA use 802.5/802.2.

Hope this helps,
Art


-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1994 19:12:06 GMT
From:      heathh@cco.caltech.edu (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: Frame types!

art@acc.com (Art Berggreen) writes:

>There is one big exception though.  Novell netware was being implemented before
>the standards were set, and ended up using 803.3 WITHOUT 802.2 LLC.  This is
>often called "RAW IPX" mode.  Luckily?, IPX also always ran with the IPX
>checksum turned off.  This (by chance) caused the first two bytes of the IPX
>headet to be all 1s.  Since this is where where the LLC LSAP fields are, these
>packets can be distinguished as a special case of LSAP values which would not
>normally be found.  This raw mode was the default for Netware out of the box

	Are you _Sure_ it was being implemented before the standards were 
set?  I wouldn't put it past Novell to just say "to he.. with the standards,
let's do it our way!"  After all, these *are* the yahoos that turned off
checksum calculation as a speed improvement.
	Also, FWIW, I have read numerous reports of databases, etc., running
over IPX getting corrupted data.  In all the cases I have heard of, the fix 
was to either change to a version of Novell that calculates and verifies
checksums, or install routers that encapsulate Novell packets in checksum'ed
wrappers.  In other words, not doing the checksum thing may be faster, but
it is dangerous.

Later,
Heath

-- 
--
From the Home for Amnesiac Computer Scientists....
  heathh@cco.caltech.edu


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 19:35:02 GMT
From:      nectar@world.std.com (Nectar Nirvana)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!

In article <1994Jan4.175353.22612@acc.com>, Art Berggreen wrote:
> In article <xzDAjq$Op7K7yarn@world.std.com> nectar@world.std.com writes:
> >Could somebody please explain to me the relationship of the following
> >frame types and maybe the merits of each? e.g. which ones are standardized,
> >which ones are _de facto_ standards, which ones work with TCP/IP, IPX/SPX.
> >And if I missed some (Token Ring & Ethernet are all I'm trying to list here), 
> >please add'em in!
> >
> >Much appreciated!
> >
> >Token Ring:
> >        Token Ring 802.5, Token Ring SNAP, Token Ring 802.2?
> >Ethernet:
> >        Ethernet II, Ethernet 802.3, Ethernet 802.2
> 

[Much information hopefully summarized accurately here with
 some additions and deletions:

Ethernet frame types:
        Ethernet II (Novell's ETHERNET_II) - original Ethernet _de facto_
         standard established by DEC, Intel, and Xerox
        Raw Ethernet 802.3 (Novell's ETHERNET_802.3) - frame type used by
         Netware.  Established before IEEE 802.2/802.3 was completed.
        Ethernet 802.3 (Novell's ETHERNET_802.2) - IEEE standard Ethernet
         frame using LLC (802.2).
        Ethernet SNAP (Novell's ETHERNET_SNAP) - The IEEE 802.2/802.3 frame
         with LSAP 0xAA and an additional layer (the SubNet Access Protocol)
         to identify protocol type.  It is unclear to me if SNAP is part
         of an IEEE standard or a _de facto_ standard.

Token Ring frame types:
        Token Ring 802.5 (Novell's TOKEN-RING) - IEEE standard Token Ring
         frame using LLC (802.2).
        Token Ring SNAP (Novell's TOKEN-RING_SNAP) - Much like Ethernet 
         SNAP, this frame type is the IEEE 802.2/802.5 frame with LSAP 0xAA
         and the SubNet Access Protocol layer.
]  

> Hope this helps,
> Art
 
That helped a tremendous amount.  If anyone else has anything to add,
such as where SNAP came from, I'd like to hear.

----
Nectar Nivrana --><--   | It's not what you see, so much as it's
nectar@world.std.com    |   how you see it ...
E-mail me for a free lobotomy consultation!

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 19:46:46 GMT
From:      ostertag@orden.cl (Eduardo Ostertag)
To:        comp.protocols.tcp-ip
Subject:   Looking for PD TCP/IP for VAX/VMS

Hi there:

I'm looking for a public domain version of TCP/IP for
VAX/VMS. Either source code or binary is OK. Any pointers
would be greatly appreciated. Please reply by mail.

Thanks in advance,

Eduardo Ostertag
ostertag@orden.cl

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 21:17:30 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or

Derek Jean-baptiste <derek@shadow.fulcrum> wrote:
>ashok@biochemistry.cwru.edu (Ashok Aiyar) writes:
>>CSLIPPER is a packet driver.  Any TCP stack that supports the packet driver
>>interface will work over CSLIPPER.
>>
>>The more appropriate question perhaps is whether Novell LWP and B&W support
>>packet drivers.  I believe that the latter does, but am not sure about the
>>former.
>>

Both support packet drivers.  I got LWP to work over
CSLIPPER but could never get B&W to do the same.

Erick


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 21:38:23 GMT
From:      mcs@unislc.slc.unisys.com (Michael Sontum)
To:        comp.protocols.tcp-ip
Subject:   Re: Practical Network Trouble Shooting Books

Lee Parsons (lparsons@exlogcorp.exlog.com) wrote:
: I saw the Unix and TCP/IP book by Quarterman and Leffler the other
: day and at first glance was impressed by the Network Debugging 
: Chapter. I realized that I haven't seen too many books that talk 
: much about actually finding a problem on the wire. 
 
: My impression of most books on the market is that they spend 300
: pages reprinting RFCs and then take 10 pages to say "Then you use
: ping and netstat to find the problem."
 
: Is that a fair assement of the state of TCP Books on the market?
: Am I over looking a better reference?
: -- 
: Regards, 
 
: Lee E. Parsons                  		Baker Hughes Inteq, Inc
: Oracle Database Administrator 			lparsons@exlog.com 


I have read Mark Miller's book and I would buy the Comer and Steven's books
first and then get the Miller book as a good reference. I really liked that
he has an acronym dictionary in the book.  How many times has someone said
,"Yeah it's just like the CMIP protocol." and you know from his reaction
you should know this but don't have the foggiest idea what the acronym is.
I didn't like that about 1/3 of the book is appendix.  I really liked that
he has actual traces from the problems and covers most of the basic well
known problems. It did cover a lot of protocols.  That can be good or bad
depending on your situation. I mostly want good ole ehternet tcp/ip stuff
and don't benefit from knowing a lot of token ring ,etc.


           Mike


____________________________________________________________________________
Mike Sontum (mcs on unislc)           
Internet:mcs@unislc.slc.unisys.com    SLC,Utah 84116
UUCP:...!{sun,uplherc}!unislc!mcs


        "Excuse me, could you help me? I'm a spy."
                -Tom Baker





-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 22:16:21 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Illustrated Vol 1

Well, I just bought W. Richard Stevens new book and it looks pretty
good so far.  How many volumes will there be, and is there a schedule
yet for their release?


-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Jan 94 07:12:04 PST
From:      D1CAMERO@bcsc02.gov.bc.ca
To:        comp.protocols.tcp-ip
Subject:   <none>

Is there a standard C interface or batch interface to FTP?
 
I would like to transmit files "in batch" with reasonable error control.
We are using AIX, Sun and SCO/Unix.
 
 thanks
 
 
 
 
 
Don Cameron
Data Management Branch, BC Ministry of Health
2nd Floor Rotherham, Victoria, B.C., V8W 3C8
(604)952-2362  D1CAMERO@bcsc02.gov.bc.ca

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 94 00:46:00 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Illustrated Vol 1

> Well, I just bought W. Richard Stevens new book and it looks pretty
> good so far.  How many volumes will there be,

Unknown at this point.  I have ideas for many more, but there are only
24 hours in a day.  I also have to get back and revise "UNIX Network
Programming" soon [for Wayne's World 3, of course :-)]

> and is there a schedule yet for their release?

No, but you'll hear about forthcoming volumes months in advance.

	Rich Stevens  (rstevens@noao.edu)

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 00:56:30 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!

In article <cJSAjq$OptR9yarn@world.std.com> nectar@world.std.com writes:
>        Ethernet SNAP (Novell's ETHERNET_SNAP) - The IEEE 802.2/802.3 frame
>         with LSAP 0xAA and an additional layer (the SubNet Access Protocol)
>         to identify protocol type.  It is unclear to me if SNAP is part
>         of an IEEE standard or a _de facto_ standard.

SNAP is defined in the more recent IEEE 802.1 standards.

>That helped a tremendous amount.  If anyone else has anything to add,
>such as where SNAP came from, I'd like to hear.

SNAP was added to the IEEE 802 standards after intense pressure from groups like
the IETF to find a way to extend the capabilities of LLC demultiplexing.  What
became SNAP was a major topic of the first TCP interoperability conference (which
developed into InterOp) in Monterey several years back.

Art


-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 01:47:24 GMT
From:      fred@maccs.mcmaster.ca (Fred Whiteside)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or

In <2gbrqb$ih3@sbi.sbi.com>, derek@shadow.fulcrum writes:
>In article 2D2485E0@biochemistry.cwru.edu, ashok@biochemistry.cwru.edu (Ashok Aiyar) writes:
>
>>CSLIPPER is a packet driver.  Any TCP stack that supports the packet driver
>>interface will work over CSLIPPER.
>>
>>The more appropriate question perhaps is whether Novell LWP and B&W support
>>packet drivers.  I believe that the latter does, but am not sure about the
>>former.
>	Does anyone know if B&W or Novell support packet
>drivers?

	To the best of my knowlege, Novell's LWP does not support
packet drivers natively.  It is possible that some combination of the
various shims would get you there, although I can't think of one that
presents an ODI interface while talking to packet drivers.  LWP has
its own SLIP and PPP drivers.

	We support class1 and 6 (ethernet and SLIP) packet drivers natively.

Fred Whiteside
Fred Whiteside   Beame & Whiteside Software - PC Networking Software
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 17:12:45 -0500
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: location of RFC's

In article <stan.huyge.20.000EB1CA@clemsonsc.ncr.com>,
Stan Huyge <stan.huyge@ClemsonSC.NCR.COM> wrote:
>I'm just starting to get my toes wet and I was hoping someone could tell me a 
>good place to pick up RFC's.

ftp.internic.net:/rfc

--Dave
-- 
"It is much safer to obey than to rule." - Thomas à Kempis

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 11:05:50 GMT
From:      lschan@hk.super.net (Mr Leonard Chan)
To:        comp.protocols.tcp-ip
Subject:   KA9Q problem

Dear all,

I don't know if here is the proper place for this question. I have a 3c503
ethernet card on my PC. Somebody told me that ka9q is the best solution for
setting up a TCP/IP router between my 3c503 and SLIP connection.

When I collected the ka9q package and set up the SLIP, I found that my 3c503
didn't receive any TCP/IP packet by looking at "ifconfig". My SLIP connection
worked perfectly, but I must make my 3c503 connection work so that I can get
this machine running as a router. Any feedback is appreciated.

THANKS

Leonard Chan


-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 11:40:52 GMT
From:      ag129@ucs.cam.ac.uk
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!

In article <1994Jan5.005630.23896@acc.com> art@acc.com (Art Berggreen) writes:
>In article <cJSAjq$OptR9yarn@world.std.com> nectar@world.std.com writes:
>>        Ethernet SNAP (Novell's ETHERNET_SNAP) - The IEEE 802.2/802.3 frame
>>         with LSAP 0xAA and an additional layer (the SubNet Access Protocol)
>>         to identify protocol type.  It is unclear to me if SNAP is part
>>         of an IEEE standard or a _de facto_ standard.
 
>SNAP is defined in the more recent IEEE 802.1 standards.

Is this the standard SNAP with the first 3 bytes of the SNAP header
being an assigned Organisation Identifier, as used in MAC addresses?
Novell IPX frames use the zero OID with the "EtherType" field, which
I always thought was only a de facto convention, since EtherTypes are 
maintained via the Internet Assigned Numbers and not IEEE.  (AppleTalk 
phase II, btw, uses the Apple OID and is thus completely standard.
There is no reason for Novell not to use their own OID.)

>SNAP was added to the IEEE 802 standards after intense pressure from 
>groups like the IETF to find a way to extend the capabilities of LLC 
>demultiplexing.  

They may have put it this way, but what they were really after was
 - data aligned on 4-byte boundaries
 - a way of carrying ARP, since they had been refused an LLC SAP
 - a migration path/mapping from old-style Ethernet, hence a need
   to carry the 2-byte type field.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 94 18:37:13 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

In article <2gfcfgINN1vm@marvin.is.wdi.disney.com>, Mark D. Eggers <mdeggers@wdi.disney.com> writes:
> I have a newbie question that I would appreciate some help with:
> 
> 
> I have been exploring some performance issues between a client and a 
> remote server.  I have found the following:
> 
> Scenario 1
> 
> Ethernet - Net X         Ethernet  - Net X
> ----------+-----------+-----------+---
>           |           |           |
>         Host A      Router      Host B
> 
> If 'Host A' and 'Host B' are on the same class B network (both on 
> Ethernet), then packets up to the MTU (1500 octets) are sent.  The 
> class B network is subnetted, and all hosts are using the proper 
> subnet mask (ie., no proxy ARP via the router).
> 
> Scenario 2
> 
> Ethernet - Net X        Serial - Net Y   Ethernet - Net Z
> ----------+-----------+----------------+--------+--------
>           |           |                |        |
>         Host A      Router           Router    Host B
> 
> If this configuration exists, packets from 'Host A' to 'Host B' and 
> the return are limited to 576 octets.
> 
> The routers have an MTU of 1500 octets for the serial link.  
> Etherfind on a SUN reveals that the sending host actually generates 
> these small packets.
 <part omitted> 
> Is this how things should work?  I was under the impression that IP 
> fragmentation would occur at the router, and the host would always 
> use the MTU of the physical network that it is attached to.  I 
> understand that this may place an extra burden on the router to 
> perform IP fragmentation, but if the MTU does not require 
> fragmentation, then sending the larger packets should improve 
> performance.
> 
> Thanks for helping me out on this - /mde/
> 
> Mark D. Eggers                          Walt Disney Imagineering
> Principle Programmer / Analyst          1401 Flower Street
>                                         Glendale, CA 91221
> Internet:                               mdeggers@wdi.disney.com
> PacTel:                                 (818) 544-7866 (WDI)
------------------
	It's the way things should work, quotes. To avoid fragmentation,
which is expensive and a pain, hosts sending traffic off the local net
frequently revert to an MSS or MTU of 576 bytes which by convention most
routers are asked to pass intact. The change from a large value to 576
is done deep in the code on most systems. While large MTU's do increase
performance between a given pair of systems they can also bother systems
of lesser capabilities by filling their lan adapters (of limited memory)
with these big things; many PC class machines will go deaf for minutes on
end after a blast of full length back to back packets. It's a compromise
situation.
	Joe D.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 13:50:21 GMT
From:      ppvx@litsun.epfl.ch (Patrick Pleinevaux)
To:        comp.protocols.tcp-ip
Subject:   Internet System Handbook

Could anybody remind me the names of the editors, publisher and year of publication
of the (excellent) Internet System Handbook ? I forgot mine at home and need to complete
a bibliography today

Thanks,

P. Pleinevaux
Swiss Federal Institute of Technology, Lausanne
Computer Engineering Dept.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 14:42:14 +0000
From:      steve@one47.demon.co.uk (Stephen R Davies)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or

In article <CJ4J58.Cv4@watserv1.uwaterloo.ca> erick@sunee.uwaterloo.ca (Erick Engelke) writes:
>Derek Jean-baptiste <derek@shadow.fulcrum> wrote:
>>>
>>>The more appropriate question perhaps is whether Novell LWP and B&W support
>>>packet drivers.  I believe that the latter does, but am not sure about the
>>>former.
>>>
>
>Both support packet drivers.  I got LWP to work over
>CSLIPPER but could never get B&W to do the same.
>
Yes, B&W will support packet drivers (I use it that way sometimes), but
using it with CSLIPPER is a waste of time as B&W has it's own compressed
SL/IP support, and quite a nice dialler to go with it.

Steve.
======================================================================
  _/_/_/ _/_/_/ _/_/_/  _/  _/  _/_/_/ Trebor Bassett Limited,
 _/       _/   _/      _/  _/  _/       Hertford Place, Denham Way,
   _/    _/   _/_/    _/  _/  _/_/       Maple Cross, Herts, WD3 2XB
     _/ _/   _/       _/ _/  _/           Tel.: +44 (0)923 896565
_/_/_/ _/   _/_/_/     _/   _/_/_/  steve@one47.demon.co.uk
== PGP 2.x public key available === 100275.3177@compuserve.com =======

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 16:34:57 GMT
From:      Richard.Berke@lobby.ti.com (Richard Berke)
To:        comp.protocols.tcp-ip
Subject:   Multiple subnets advertisement by routers

I appreciate the replies I've received.  
Thanks:  Tony Li (Cisco), Chris Ranch/J'aime Amadeo (Amadeo&Associates),
Michael Bethune (Michael Bethune and Assoc.)

I still have questions...

I've added to the diagram a bit to try to clarify:


>     
>     Other sites ---+
>                    |        x.y.1.2      x.y.2.2
>                  Router A    UNIX 1      UNIX 2
>            x.y.1.1 | x.y.2.1   |           |
>         -----ethernet A--------+-----+-----+-------
>                               x.y.1.3| x.y.2.3
>                                    Router B
>                                      | x.y.3.1
>         -----ethernet B--------------+-----+-------
>                                            | x.y.3.2
>                                          UNIX 3
>     

One of our sites has Cisco routers (9.1.7) and SUN workstations (SUN OS 
4.1.2?) The UNIX workstations are on different subnets for physical reasons 
and for our attempt at simplified subnetmask settings.  We therefore have 
about approx. 250 per subnet, with small sites only needing one subnet and 
large ones needing multiple subnets.

I think I understand from Tony's description of no-split-horizon that we 
would see advertisements on ethernet A from:

Router		Networks in RIP pkts	Destinations
------------	---------------------	---------------
Router A:	Other sites          	x.y.1.255
		x.y.1                   x.y.2.255
		x.y.2
		x.y.3 ( via Router B)
Router B:       x.y.1                	x.y.1.255	
		x.y.2                   x.y.2.255
		x.y.3                  
		Other ( via Router A)

If I've got it correctly, the double transmissions of however many packets 
it takes to advertise the full set of all known routes is what we DON'T 
want.  With split-horizons, Cisco advertises once on a physical interface, 
and uses only its primary address for that interface.  With no-split- 
horizons, Cisco transmits advertisements on each of its logical networks as 
if they were separate physical interfaces.

The complexity and loading we want to avoid is where Router A's wide area 
has 100+ networks, and Router B's is about 70+.  RIP on ethernet A results in multiple packets to convey the list of routes.   With a local subnet set of actually 5 nets today, the transmission by Routers A and B of what each has attachd AND the other has

I'm concerned about the above from any router.
Why would I EVER want UNIX 1 or 2 to hear from Router A on ethernet A, that 
x.y.3 is accessible via Router B, when B is advertising on ethernet A?
I think I don't ever.  If Router B is alive, always rely on it.  If it's 
down, then Router A is superfluous and perhaps harmful in its 
advertisements.  

In principal, I think I'm agreeing with an approach of 'don't transmit on a 
physical interface advertisements of nets that you learned from 
advertisements received on that physical interface.'  I think I 
need advertisements transmitted to each configured logical network with 
contents of nets learned on other physical interfaces than the one 
the logicals are configured across.

I think I need Router A to advertise what IT'S ATTACHED to only, and not 
spray back out Router B's attached nets.   Router B should do similar 
advertisement: it's attached nets but not the 'Other sites' which are heard 
of via Router A.

Am I really asking for wrong behavior per published guidelines/standards?

I think I understood from Michael Bethune that what I want is proper 
behavior.  I don't know if that turns out to be just theoretical or if 
products exist that can be configured to do so.

Tony - have I correctly understood the limits of current Cisco features?

Other readers: do other products support what I describe above?  

Thanks for your patience and comments on this.

Richard Berke   RBRK   Richard.Berke@lobby.ti.com  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 94 17:12:53 GMT
From:      my@laverde.nsc.com (Mike Yip)
To:        comp.protocols.tcp-ip
Subject:   How many CRC are needed?

Hi there,

Seems like every layer of the stack add its checksum (for either the header or
whole packet), do you really think that checksums in all layers are necessary?

For example, the Ethernet MAC will add the FCS at the end of a packet,
IP has it own header checksum, and TCP and UDP have their own packet checksum.
Does FTP do a checksum on the whole file also?  How about Telnet and NFS?

---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 	Of course, this is my own opinion!
| 	I don't get paid enough to speak for my company.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 17:33:31 GMT
From:      adamson@itd.nrl.navy.mil (Brian Adamson)
To:        comp.protocols.tcp-ip
Subject:   Determining Local Full Hostname?

Excuse me if this isn't the correct group for this (or if a FAQ covers
this, let me know where to find it) .... but what is the best way (in
C) to determine your local host's full, complete hostname including
correct domain extensions .... gethostname() & getdomainname() don't
seem to be always reliable here ... I thought I'd check for an easy
answer before plunging into getting a good name from the nameserver
using the dotted notation address which I am always successfully able
to divine ...



Brian Adamson
Information Technology Division
Naval Research Laboratory

<adamson@itd.nrl.navy.mil>

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 18:39:16 GMT
From:      D.Nash@utexas.edu  (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?


In article <1994Jan5.171253.25083@berlioz.nsc.com>, my@laverde.nsc.com
(Mike Yip) writes:
>Seems like every layer of the stack add its checksum (for either the
>header or
>whole packet), do you really think that checksums in all layers are
>necessary?
>
>For example, the Ethernet MAC will add the FCS at the end of a packet,
>IP has it own header checksum, and TCP and UDP have their own packet
>checksum.
>Does FTP do a checksum on the whole file also?  How about Telnet and
>NFS?

IP needs its own header checksum to provide end-to-end integrity on the header.
Link-level CRCs and checksums do not protect a packet while it is in a router's
memory, but end-to-end checksums do.  If the IP header gets corrupted, the
packet could get delivered to the wrong address or have other unhappy things
happen to it.

TCP and UDP have entire-packet checksums to provide end-to-end integrity on
the data they are delivering.  The IP header checksum obviously only covers
the IP header, leaving the payload of the IP datagram unprotected.  This is
why TCP and UDP have their own checksums on the entire packet (actually on
the entire TCP segment or UDP datagram, not including the IP header itself).

All of the protocols which use TCP (like FTP and telnet), don't do their own
checksumming because TCP guarantees reliable delivery.  NFS doesn't do
checksumming either because it relies on UDP checksumming.  UDP checksums
can be disabled (they are optional), and people get into trouble by disabling
them to increase NFS throughput.  They usually turn them back on again when
they start getting file system corruption due to smashed NFS packets not
being detected.

                                ++Don Nash

Internet:  D.Nash@utexas.edu    The University of Texas System
THEnet:    THENIC::DON          Office of Telecommunication Services

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 18:57:09 GMT
From:      sob@TMC.EDU (Stan Barber)
To:        comp.protocols.tcp-ip
Subject:   Unix Telnet client that implement RFC 1096 for SVR4

I need to find a SYSVR4 Unix telnet client that implements RFC 1096. The one
shipped with both Solaris and Unix i386 System VR4 I have don't have a telnet
that implements this important option.

The "Cray" telnet will compile, but does not work properly. I can  probably
spend the time to fix the Cray version, but would rather find one already 
fixed.

I will summarize. Reply directly to me.


-- 
Stan           internet: sob@bcm.tmc.edu         Executive Director, Technology
Olan           uucp: rutgers!bcm!sob             Architecture & Planning
Barber         Opinions expressed are only mine. Baylor College of Medicine

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 19:07:18 GMT
From:      bowling@cebaf4.cebaf.gov (Bruce Bowling)
To:        comp.protocols.tcp-ip
Subject:   WATTCP is right???


I am looking for a Berkeley socket package
for the PC.  I was told to look at the 
WATTCP package for such an animal.
I downloaded the package, and I don't
seem to locate "callable" routines,
or any documentation on using them.

Am I doing the correct thing???  Is
there documentation available for the
WATTCP package (other tahn what is 
provided), or what are the routines?

Thanks in advance

Bruce Bowling
Continious Electron Beam Accelerator facility.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Jan 94 19:18:38 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Can cslipper run on Beam&whiteside or

In article <2gbrqb$ih3@sbi.sbi.com> derek@shadow.fulcrum writes:

   In article 2D2485E0@biochemistry.cwru.edu, ashok@biochemistry.cwru.edu (Ashok    Aiyar) writes:

   >CSLIPPER is a packet driver.  Any TCP stack that supports the packet driver
   >interface will work over CSLIPPER.
   >
   >The more appropriate question perhaps is whether Novell LWP and B&W support
   >packet drivers.  I believe that the latter does, but am not sure about the
   >former.

           Does anyone know if B&W or Novell support packet drivers?

B&W yes, Novell yes but only by using PDETHER.

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 19:41:34 GMT
From:      stan.huyge@ClemsonSC.NCR.COM (Stan Huyge)
To:        comp.protocols.tcp-ip
Subject:   location of RFC's



Hi,

I'm just starting to get my toes wet and I was hoping someone could tell me a 
good place to pick up RFC's.  I've tried NIC.DDN.MIL, but the response is 
terrible and I can't keep a connection.

Stan Huyge

stan.huyge@clemsonSC.ncr.com

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 19:45:15 GMT
From:      mmoore@hpcc01.corp.hp.com (Mike Moore)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

> Sorry if this is FAQ or in wrong group (which probably is the 
> case :). Is it possible access CompuServe-network from Internet. 
> And I don't mean mail, I want files. Can we use FTP (on what 
> IP-address) ? What kind of uid's we'd use in this case (we have 
> already some uid's to CompuServe, used with phone access) ?

You may telnet to compuserve via hermes.merit.edu by typing
compuserve at the prompt.

I haven't heard of any FTP access yet... 

Mike


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 21:27:26 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1

Frank Lofaro (ftlofaro@unlv.edu) wrote:

: Umm, isn't 127.x.x.x with x anything supposed to be loopback??
: What does the spec say?
: Although most people just use 127.0.0.1.
 
: Some TCP/IP implementations will send out over the net a 127.0.0.2, for example!
 
: I pinged 127.0.0.2 from a system here in Las Vegas, and it made it all the way 
: to San Diego before getting chucked with an ICMP Unreachable!
 
: That is weird.
 
: Is that a bug? I think it should never have gotten out, it should've been 
: looped back.
 
: Linux treats all 127.x.x.x addresses as loopback, IMHO the correct behavior.
: Most other un*xes do not.
 
: BTW: PC/TCP's telnet client will send 127.0.0.1 over the net! I did a telnet 
: 127.0.0.1 from an PC a while back, and got connected to the login prompt of 
: a router just a couple of hops from the backbone! So much for PC/TCP! 

This and the above example you mention are due to things responding to
arp requests for this network. Plus a combination of routing tables
containing only an entry for 127.0.0.1 as a host.
Strictly nothing should respond to an arp for any 127.x.x.x anything seeing
it on an incoming packet should silently discard it.
PC implimentations may not recognise this network, and thus send to a router,
which should ignore it.

The implimentation of this appears to be broken in quite a few cases.


-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 21:46:24 GMT
From:      Mark D. Eggers <mdeggers@wdi.disney.com>
To:        comp.protocols.tcp-ip
Subject:   Packet sizes from hosts through routers

I have a newbie question that I would appreciate some help with:


I have been exploring some performance issues between a client and a 
remote server.  I have found the following:

Scenario 1

Ethernet - Net X         Ethernet  - Net X
----------+-----------+-----------+---
          |           |           |
        Host A      Router      Host B

If 'Host A' and 'Host B' are on the same class B network (both on 
Ethernet), then packets up to the MTU (1500 octets) are sent.  The 
class B network is subnetted, and all hosts are using the proper 
subnet mask (ie., no proxy ARP via the router).

Scenario 2

Ethernet - Net X        Serial - Net Y   Ethernet - Net Z
----------+-----------+----------------+--------+--------
          |           |                |        |
        Host A      Router           Router    Host B

If this configuration exists, packets from 'Host A' to 'Host B' and 
the return are limited to 576 octets.

The routers have an MTU of 1500 octets for the serial link.  
Etherfind on a SUN reveals that the sending host actually generates 
these small packets.

Host A

	SUN Sparc II SunOS 4.12
	IBM PC 486, DOS 5, FTP Software 2.3
	Macintosh Quadra 950, System 7.1, MacTCP
	
Host B
	SUN Sparc II, SunOS 4.12
	VAX 6620, VMS 5.5-3, Multinet
	
The software is a small client-server application using XDR to send 
and receive 200 short integers across the network via TCP.  The 
resulting 800 octets should be sent in one packet, but will be sent 
in two packets if scenario 2 is in place.

Is this how things should work?  I was under the impression that IP 
fragmentation would occur at the router, and the host would always 
use the MTU of the physical network that it is attached to.  I 
understand that this may place an extra burden on the router to 
perform IP fragmentation, but if the MTU does not require 
fragmentation, then sending the larger packets should improve 
performance.

Thanks for helping me out on this - /mde/

Mark D. Eggers                          Walt Disney Imagineering
Principle Programmer / Analyst          1401 Flower Street
                                        Glendale, CA 91221

Internet:                               mdeggers@wdi.disney.com
PacTel:                                 (818) 544-7866 (WDI)

I speak for myself, not "The Mouse"

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 22:32:31 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!

In article <ag129.468.000BAEC5@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk writes:
>In article <1994Jan5.005630.23896@acc.com> art@acc.com (Art Berggreen) writes:
>>SNAP is defined in the more recent IEEE 802.1 standards.
>
>Is this the standard SNAP with the first 3 bytes of the SNAP header
>being an assigned Organisation Identifier, as used in MAC addresses?

Yes, the SNAP header is defined in IEEE 802.1 with the OUI defined to
be the IEEE assigned manufacturers code.

>Novell IPX frames use the zero OID with the "EtherType" field, which
>I always thought was only a de facto convention, since EtherTypes are 
>maintained via the Internet Assigned Numbers and not IEEE.

Actually Ethertypes are officially registered with Xerox. IANA only includes
a partial list in the Assigned Numbers RFCs.  But you are probably right
about the use of OUI 00-00-00 being a defacto standard.  I have never seen
an IEEE document which "grandfathers" the Xerox Ethertypes under that OUI.

> (AppleTalk 
>phase II, btw, uses the Apple OID and is thus completely standard.
>There is no reason for Novell not to use their own OID.)

Actually, Ethertalk Phase-2 is schitzoid.  Ethertalk DDP packets use an
OUI of 08-00-07 and AARP packets use 00-00-00.  Multimedia bridge vendors
would prefer if all traffic on Ethernets would use Ethenet encapsulation
when using Ethertypes and use nonzero OUIs with SNAP.

>>SNAP was added to the IEEE 802 standards after intense pressure from 
>>groups like the IETF to find a way to extend the capabilities of LLC 
>>demultiplexing.  
>
>They may have put it this way, but what they were really after was
> - data aligned on 4-byte boundaries
> - a way of carrying ARP, since they had been refused an LLC SAP
> - a migration path/mapping from old-style Ethernet, hence a need
>   to carry the 2-byte type field.

My memory from Monterey may be suspect, but this is what I remember.
It was believed at that time that IEEE 802.x/802.2 was going to be
the standard for LANs.  IP had already been assigned LSAP 06, but needed
ARP to run on LANs.  The limited demux space (64 codepoints) made IEEE
refuse to allocate one for ARP (TCP/IP and the Internet in those days
was just beginning to become a real force, IEEE was expecting ISO protocols
to become dominant).  Several ideas were kicked around, with the SNAP
proposal the one most people got behind.  Once it was agreed that a new
header was being added, fixing the alignment that 802.2 broke, was a
natural feature.

Art


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 20:57:50 +0100
From:      agulbra@tigern.nvg.unit.no (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Local Full Hostname?

In article <CJ63Fw.44@ra.nrl.navy.mil>,
Brian Adamson <adamson@itd.nrl.navy.mil> wrote:
>Excuse me if this isn't the correct group for this (or if a FAQ covers
>this, let me know where to find it) .... but what is the best way (in
>C) to determine your local host's full, complete hostname including
>correct domain extensions .... gethostname() & getdomainname() don't
>seem to be always reliable here ... I thought I'd check for an easy
>answer before plunging into getting a good name from the nameserver
>using the dotted notation address which I am always successfully able
>to divine ...

I use the following code, which should be able to execute without
any nameserver calls on most configurations.  There's a kludge in
there for /etc/hosts lines like

123.45.67.89 pluto mailhost pluto.cc.xx-state.edu pluto.cc

which seems to find the full name most of the time.  I'd appreciate
comments to the code:

char myfqdn[256]; /* 256 characters is the max allowed (?) */

void whoami(void) {
    struct hostent * he;
    if (gethostname(myfqdn, 32)) {
/*
 * no program should work on a machine which is configured so
 * badly that this fails.
*/
        perror("gethostname");
        exit(EX_OSERR);
    }
    if ((he = gethostbyname(myfqdn)) == NULL) {
        perror("gethostbyname");
        exit(EX_OSERR);
    }
    strncpy(myfqdn, he->h_name, 256);
    if (strchr(myfqdn, '.') == NULL) {
        char ** alias;
        alias = he->h_aliases;
        while( alias && *alias )
            if (strchr(*alias, '.') && (strlen(*alias)>strlen(myfqdn)))
                strncpy(myfqdn, *alias, 256);
            else
                alias++;
    }
}

If this isn't good enough, do a PTR query to the name server.

Btw, getdomainname() returns the YP/NIS domain (where I live, at
least), which in principle has nothing to do with the DNS domain.

--Arnt

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 22:45:44 GMT
From:      cracraft@rice-chex.ai.mit.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip
Subject:   5/4/3 repeater rule


I am configuring a network and have been reading the IEEE 802.3 
specification regarding repeater configurations on a network.

In reading the IEEE 802.3 spec, there is a constant reference
to a "link segment." The repeaters I am using utilize thin
co-ax ethernet (10base2). My configuration already has the
maximum number of co-axial segments (3) with station attachments.

Can I use thinwire ethernet as a "link segment" between two repeaters
or must that link segment be composed of a true point-to-point medium
such as 10base-T or 10base-FL?

Thankyou in advance for your replies,

	Stuart



-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 23:19:08 GMT
From:      my@laverde.nsc.com (Mike Yip)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article D.Nash@utexas.edu  (Donald L. Nash) writes:
>IP needs its own header checksum to provide end-to-end integrity on the header.
>Link-level CRCs and checksums do not protect a packet while it is in a router's
>memory, but end-to-end checksums do.

Interesting  If we cannot trust the internal of the router, why should we
trust the internal of the computer that we are using.  If something went wrong
in the memory of a router, then shouldn't a parity be generated or corrected
by ECC.  If a router/bridge can randomly corrupt packet inside the box, then
may be we shouldn't buy from that vendor.  Do you know what kind of error
detection/correction router/bridge boxes do?  Or they try to save money by
not adding parity to the data paths and memory.


>... If the IP header gets corrupted, the
>packet could get delivered to the wrong address or have other unhappy things
>happen to it.

Agree.  But if the router is good, then the problem must be on the link and
the link layer FCS will be able to detect and throw away the packet before IP
gets to process it.


>... NFS doesn't do
>checksumming either because it relies on UDP checksumming.  UDP checksums
>can be disabled (they are optional), and people get into trouble by disabling
>them to increase NFS throughput.  They usually turn them back on again when
>they start getting file system corruption due to smashed NFS packets not
>being detected.

Can you tell us more about the problem when UDP checksum is turn off?
(Assuming the error is not caused by dropped packet when link layer FCS throws
away bad packets.)  Where else did the error come from?  

Thanks for the answer.  But are we really doing too much checking?

/---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 	Of course, this is my own opinion!
| 	I don't get paid enough to speak for my company.



-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 12:39:57 -0800
From:      dave@hebron.connected.com (Dave Perlin)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25: info needed

I seem to remember a number of months ago there being some discussions on 
the performance of TCP/IP over X.25.  I'm now looking for general
info on the subject (ie. issues/problems) as well as specific real
life accounts from people on how well things run.

IF you've got copies of old news articles on the subject or suggestions
of places to look for info,  I'd very much appreciate if you could 
send me email.

Thanks,

David Perlin
davep@nanosoft.com

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 09:16:22 -0500
From:      burr@cs.unc.edu (Michael Burr)
To:        comp.protocols.tcp-ip
Subject:   connect()-connect() question

We are implementing a socket API & have run into an interesting
problem.  With the BSD implementation of TCP/IP, it is perfectly
legal for two applications to issue (nearly) simultaneous connect()
calls to each others' sockets.  As long as the TCP/IP stack for
one application receives the connect request from the other stack
before it times out its own application's connect(), everything gets
set up fine.  We are trying to evaluate the importance of mimicing
this behavior in our implementation.  Does anyone know of ANY
applications that exploit this feature of BSD sockets?  Any help or
pointers to more appropriate newsgroups would be greatly appreciated.

Thanks,
Mike Burr
burr@cs.unc.edu

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 01:27:39 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1

Frank Lofaro (ftlofaro@unlv.edu) writes:
> Some TCP/IP implementations will send out over the net a 127.0.0.2, for
> example!
> I pinged 127.0.0.2 from a system here in Las Vegas, and it made it all the
> way to San Diego before getting chucked with an ICMP Unreachable!

  The behavior you saw is probably caused by having only a host route for
  127.0.0.1 and default route.

  But this __is__ a defect specific to the 127 network, per RFC1122 3.2.1.3:

     "(g)  { 127, <any> }
           Internal host loopback address.  Addresses of this form
           MUST NOT appear outside a host."

  As to whether or not 127.* (not just 127.0.0.1) finds its way through the
  loopback interface, that will depend on vendor implementation.

-- Ken Mintz

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 04:19:01 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <1994Jan5.231908.4522@berlioz.nsc.com> my@laverde.nsc.com writes:
>In article D.Nash@utexas.edu  (Donald L. Nash) writes:
>>IP needs its own header checksum to provide end-to-end integrity on the header.
>>Link-level CRCs and checksums do not protect a packet while it is in a router's
>>memory, but end-to-end checksums do.
>
>Interesting  If we cannot trust the internal of the router, why should we
>trust the internal of the computer that we are using.  If something went wrong
>in the memory of a router, then shouldn't a parity be generated or corrected
>by ECC.  If a router/bridge can randomly corrupt packet inside the box, then
>may be we shouldn't buy from that vendor.  Do you know what kind of error
>detection/correction router/bridge boxes do?  Or they try to save money by
>not adding parity to the data paths and memory.

"If wishes were horses, the beggars would ride."  If nothing bad ever
happened, you wouldn't need parity bits.  You wouldn't need any CRC's.

The simple truth is that bad things do happen.  There are as many
ways to build router boxes as there are routers.  Not all errors are
detected by parity bits.  Some errors can be in firmware.  Some hardware
errors cause the wrong bytes but with the right parity (or ECC) to be
used instead of the right bits.  (How many address buses have parity?)
Not all bad bytes are detected by their parity or ECC bits.


> ...
>Can you tell us more about the problem when UDP checksum is turn off?
>(Assuming the error is not caused by dropped packet when link layer FCS throws
>away bad packets.)  Where else did the error come from?  

It is not a matter of "the error".  There are many sources of error.

Look on any heavily used network computer, say a big NFS server or a big
Internet fireall, that has been up for a week or two.  Ask it how many
UDP, IP, and TCP checksums errors it has counted.  You will almost
certainly find that has seen several.  Each of those errors would have
otherwise have been an undetected data error.  (`netstat` is a common
command for this purpose.)


>Thanks for the answer.  But are we really doing too much checking?

No.  

Remember that the magic of "digital" compared to "analog" for things
ranging from audio CDROMs to HDTV to fast modems is that we can
and do do all of that error detecting and correcting.


Vernon Schryver    vjs@rhyolite.com

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 16:11:06 -0600
From:      jlarocqu@promus.com (Joe La Rocque)
To:        comp.protocols.tcp-ip
Subject:   SLIP Security Issues?



	Hi!

	I would be interested in hearing your comments on the security,
	or lack thereof, pertaining to SLIP.  What are the current 
	issues today, what can be done by the sysadmin to close the
	leaks, etc.

	We are currently looking at activating a SLIP on our SCO box
	(ie, slattach), but there are some people, within the depart-
	ment that are against this because of a lack of security.

	My position on this is that a SLIP is no more secure or
	insecure than a getty.  Both require you to login to the
	system with a password (unless you are dumb enough to create
	a user without a password), you can disallow rcp/ftp (something
	you can't do with a normal serial connection: the user could
	issue sz or rz to transfer files), so I don't grasp their
	point of view.

	So, tell me I'm crazy, right, wrong or am approaching the 
	problem from the wrong direction. I would really like to hear
	from you.

	Thanks!

____________________________________________________________________________
Do not try to teach a pig how to sing. It is a waste of your time
and only annoys the pig.

	- Robert H. Heinlein
****************************************************************************
A. Joseph La Rocque     ++ I do not speak for the Promus Companies ++
Promus Companies      
jlarocqu@promus.com

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 06:16:07 +0000
From:      Mick.K.McPadden@cm.cf.ac.uk (mick)
To:        comp.protocols.tcp-ip
Subject:   Questions about the costs of using TCP

Hi,

	I've a couple of questions that I hope somebody out there might be able to answer for me, they concern the use of TCP and UDP within a small LAN such that no routing needs to take place via any intermediate systems. Please forgive my English, grammer, etc, but its been a long evening. Here goes,

1. I've read somewhere that setting up a TCP connection requires three 'messages' to be passed between two communicating partners, with a further three being required to tear down the connection, is this true, is it more, or less ?

2. If a connection has been set up, but no data has been sent through it for say 20 minutes, has there been been any TCP activity on the LAN in the meantime in order to keep that connection alive, or will network activity commence only when data are explicitly passed through the connection. In otherwords is there a hidden  overhead associated with idle connections.

3. Do TCP implementations tend to have an upper limit on the number of connections that they might have open at any one time, or is this vendor dependant ? 

4. In relation to the above what would be the things that would affect performance the more connections that any particular system entered into ?, would they for example be concerned with keeping each connection alive, managing tables of connections, or something else.

Thanks in advance for any replies (these replies preferably being by E-mail).

mick (going home for some sleep).

--
Mick, Dept of Computing Mathematics,                 E-Mail mick@cm.cf.ac.uk.
University of Wales College of Cardiff        	     Phone  +44-222 874812
PO Box 916, Cardiff, CF2 4YN, Wales, UK.             Fax    +44-222 666102

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 15:14:17 -0500
From:      martinw@epenviron.eapi.com (Martin Walker)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   smc 3016 packet driver

I need the latest packet driver for the SMC 3016/MC 10BaseT card.  I think
it's called ftp230.exe.  I am having problems downloading it from 
SMC's BBS, does anyone know if it's on the net anywhere I can download
it ?  Alternativly, is it small enough that someone can e-mail it
to me ?

thanks

-- 
=========================================================================
Martin C. Walker                                         martinw@eapi.com
Project Lead                                         Voice (513) 629-2517
Eagle-Picher Industries Inc.                           Fax (513) 629-2449

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 07:20:42 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <1994Jan5.231908.4522@berlioz.nsc.com> my@laverde.nsc.com writes:
>Interesting  If we cannot trust the internal of the router, why should we
>trust the internal of the computer that we are using.  

You shouldn't.  That's why good workstations have ECC on memory and parity
on busses, really good ones have RAID mass storage, and we make frequent
backups.

>							If something went wrong
>in the memory of a router, then shouldn't a parity be generated or corrected
>by ECC.  If a router/bridge can randomly corrupt packet inside the box, then
>may be we shouldn't buy from that vendor.  Do you know what kind of error
>detection/correction router/bridge boxes do?  Or they try to save money by
>not adding parity to the data paths and memory.

In an Internet, the end users don't have much control over the intermediate
routers.  If you're trying to make a cross-country connection, you're at
the mercy of the routers in the local and regional networks at each end,
and the backbone routers.

Some sites use inexpensive PC's as routers.  I don't think these usually
have ECC memory.

The design of TCP/IP is to make few assumptions about the reliability of
the underlying link and hardware protocols.  Some link protocols may not do
as much checking as ethernet does.

>Agree.  But if the router is good, then the problem must be on the link and
>the link layer FCS will be able to detect and throw away the packet before IP
>gets to process it.

When there are 25 routers in the path, are you really willing to bet that
all the routers, all 50 interfaces and transceivers, etc. are all working
fine?  Some of these links may not have a link layer FCS.

>Can you tell us more about the problem when UDP checksum is turn off?
>(Assuming the error is not caused by dropped packet when link layer FCS throws
>away bad packets.)  Where else did the error come from?  

I was never able to determine the precise circumstances, but before we
started using UDP checksums here, we frequently saw blocks of zeroes show
up in files.  Even when the client and server were on the same subnet.

>Thanks for the answer.  But are we really doing too much checking?

Properly implemented, the checksums add little overhead, and they provide
significant benefits.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 94 16:36:41 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

In article <CJ80Gp.Hsx@cup.hp.com>, raj@cup.hp.com (Rick Jones) writes:
> Joe Doupnik (jrd@cc.usu.edu) wrote:
> : 	It's the way things should work, quotes. To avoid fragmentation,
> : which is expensive and a pain, hosts sending traffic off the local net
> 
> Um, IP fragmentation/reassembly is not by definition "expensive" if
> you mean CPU cycles (yes, I'm probably splitting hares ;-) (and yes,
> there are some IP implementations in which IP fragmentation takes you
> into slower-speed paths - don't judge the message by the messenger :)
> It can be done quite cheaply. It doesn't have to involve data copies,
> "just" the twiddling of a few pointers. Of course, "pain" and
> "expensive" are not easily quantified.
	This is straying some from the original question, but what the
heck. Sure fragmentation is expensive. The routers must take (cpu) time
to do the fragmenting, the receiver must deal specially with getting the
pieces together (I've written such code, compact & fast), and cleaning up.
 
> : While large MTU's do increase performance between a given pair of
> : systems they can also bother systems of lesser capabilities by
> : filling their lan adapters (of limited memory) with these big
> : things; many PC class machines will go deaf for minutes on end after
> : a blast of full length back to back packets. It's a compromise
> : situation.
> 
> I've always been under the impression that the argument against IP
> fragmentation was more of a "statistical" one. That IP fragments were
> bad because losing one meant losing an entire IP datagram, which is
> (presumably) worse than losing an entire IP datagram that was not
> fragmented because more bandwidth was consumed.
	The argument against is that of facing reality: not all TCP hosts
can deal with IP frags. Yes, I know what Host Requirements says, but
RFC-1122 does not create code for people.

> Lost IP fragments will also tend to leave "orphaned" fragments sitting
> in IP fragment reassembly queues for many tens of seconds. Is this
> what you were referring to with respect to the PC class machines? "Full
> length back to back packets" is something that is not restricted to
> fragmented IP datagrams.
	Yes, correct. The size as well as rate of packets can easily
overfill many lan adapters on PCs.
	Joe D.

> rick jones
> There are my opinions, and HP's opinions, necessarily the same...

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 11:52:47 GMT
From:      etoipl@etn.ericsson.se (Ivar Plahte 66841864)
To:        comp.protocols.tcp-ip,comp.realtime,erinet.general
Subject:   tcp-ip stack for embedded system


We are looking for a tcp/ip/slip stack to be ported to an embedded system.
Our HW card is MC68302 based, the network connection is an RS232 port, 
the operating system is a small finite state machine based multi-threaded
sequencer written by ourselves.  Everything is coded in C.


Our selection will be based on the following criteria:
	- Speed of porting
	- Purchase price
	- License fees
	- Availability of ftp, tftp, and telnet

Possible trade-offs are:
	- Performance
	- Memory Requirements


#######################################################################

Ivar Plahte                   email: etoipl@etn.ericsson.se
Ericsson AS                   phone: +47 66 84 18 64
Private Networks              fax:   +47 66 98 19 15

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 Jan 94 21:54:00 -0600
From:      "Mark Lo Chiano" <p00231@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   Alternate IP & MAC Address

	We have a need to create an application that must broadcast certain
UPD messages using an IP address & MAC of several other machines.
In this application the broadcasting machine acts as a proxy for the alternate
machines.

	We are are QUITE aware that this is not a normal practice, but this
is necessary.  So flame away....

	We have identified two alternate methods for that appear 
fruitful, and would like comments on OTHER possible approaches.

	The first approach is to utilize two ethernet cards in the 
broadcast machine.  The first ethernet card would operate normally and receive
normal IP traffic.  The second card would only broadcast these special 
messages, but would not receive any traffic.  Under this approach, we 
would use fcntl() to reset the IP address of the second card prior to 
the broadcast.  This is expected to cause significant overhead, 
however, that is quite acceptable.  This approach would seem to have the
potential to allow the IP address to be altered but not the MAC address.

	The second approach is to replace the current IP layer for the machine.
Under this approach, we would essentially 'break' IP to relax the 
bind() commands built in checks.  These normal (and proper) checks prevent 
UPD socket binds that specify a local IP address from specifying an address
other that the correct local IP as configured by ifconfig.  This approach
would seem to allow both the IP and MAC accresses to be altered.

	All comments are welcome.....I realize that this is potentially a
sensitive subject, so it may be appropriate to respond via Email.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 12:02:37 GMT
From:      igb@fulcrum.co.uk (Ian G Batten)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <CJ6xBp.LIB@calcite.rhyolite.com>,
Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
> Look on any heavily used network computer, say a big NFS server or a big
> Internet fireall, that has been up for a week or two.  Ask it how many
> UDP, IP, and TCP checksums errors it has counted.  You will almost

I'd agree with Vernon.  I've just checked on our Auspex, and its IP
layer has handled 428701753 packets of which 7 were bad.  That's packets
where the ethernet checksum was OK but the payload was corrupt.  I don't
want those anywhere near my systems, especially in NFS.

ian

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 14:25:24 GMT
From:      cline+@CS.CMU.EDU (Kenneth Cline)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

Two more causes of bad packets on the internet are bugs in
communications software and hardware errors.  One particularly
nasty hardware error I have heard of cleared every other bit
of data in an ethernet buffer, resulting in bad data with
a valid checksum.

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 15:01:45 +0000
From:      daveh@fusion.demon.co.uk (Dave Hodgkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP References in RFC1122 - where are they?


Thanks very much for this. It's something I've been looking for for a
while!

Dave

+-------------------------+---------------------------------------+
| Dave Hodgkinson         |   email: daveh@fusion.demon.co.uk     |
| RFC1122 Enforcer        |   phone: +44 71 377 9009              |
| Fusion Systems Group    |   snail: 38 Spital Square, London     |
| Open Systems Architects |          England. E1 6DY              |
+-------------------------+---------------------------------------+


-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 17:57:00 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

In article <1994Jan5.183713.7076@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
>In article <2gfcfgINN1vm@marvin.is.wdi.disney.com>, Mark D. Eggers <mdeggers@wdi.disney.com> writes:
>> .
>> .
>> .
>> Is this how things should work?  I was under the impression that IP 
>> fragmentation would occur at the router, and the host would always 
>> use the MTU of the physical network that it is attached to.  I 
>> understand that this may place an extra burden on the router to 
>> perform IP fragmentation, but if the MTU does not require 
>> fragmentation, then sending the larger packets should improve 
>> performance.
>> .
>> .
>> .
>	It's the way things should work, quotes. To avoid fragmentation,
>which is expensive and a pain, hosts sending traffic off the local net
>frequently revert to an MSS or MTU of 576 bytes which by convention most
>routers are asked to pass intact. The change from a large value to 576
>is done deep in the code on most systems. While large MTU's do increase
>performance between a given pair of systems they can also bother systems
>of lesser capabilities by filling their lan adapters (of limited memory)
>with these big things; many PC class machines will go deaf for minutes on
>end after a blast of full length back to back packets. It's a compromise
>situation.

This is why the Path MTU Discovery Protocol (RFC 1191) was developed.  This
defines a method to probe the maximum packet size that can be sent to a
destination without fragmentation.  Unfortuneately, the host support is just
starting to show up and it'll probably be a while before it is widely
available.

Art


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 18:13:20 GMT
From:      Mark D. Eggers <mdeggers@wdi.disney.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

Thanks for every one that replied.

Basically, the hosts are acting in a proper (conservative) fashion.  
If all hosts implimented MTU discovery, then larger packet sizes 
might increase performance - provided that the hosts were closely 
matched.

thanks again - /mde/

Mark D. Eggers                          Walt Disney Imagineering
Principle Programmer / Analyst          1401 Flower Street
                                        Glendale, CA 91221

Internet:                               mdeggers@wdi.disney.com
PacTel:                                 (818) 544-7866 (WDI)

I speak for myself, not "The Mouse"

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 18:24:25 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

Joe Doupnik (jrd@cc.usu.edu) wrote:
: 	It's the way things should work, quotes. To avoid fragmentation,
: which is expensive and a pain, hosts sending traffic off the local net

Um, IP fragmentation/reassembly is not by definition "expensive" if
you mean CPU cycles (yes, I'm probably splitting hares ;-) (and yes,
there are some IP implementations in which IP fragmentation takes you
into slower-speed paths - don't judge the message by the messenger :)
It can be done quite cheaply. It doesn't have to involve data copies,
"just" the twiddling of a few pointers. Of course, "pain" and
"expensive" are not easily quantified.

: While large MTU's do increase performance between a given pair of
: systems they can also bother systems of lesser capabilities by
: filling their lan adapters (of limited memory) with these big
: things; many PC class machines will go deaf for minutes on end after
: a blast of full length back to back packets. It's a compromise
: situation.

I've always been under the impression that the argument against IP
fragmentation was more of a "statistical" one. That IP fragments were
bad because losing one meant losing an entire IP datagram, which is
(presumably) worse than losing an entire IP datagram that was not
fragmented because more bandwidth was consumed.

Lost IP fragments will also tend to leave "orphaned" fragments sitting
in IP fragment reassembly queues for many tens of seconds. Is this
what you were referring to with respect to the PC class machines? "Full
length back to back packets" is something that is not restricted to
fragmented IP datagrams.

rick jones
There are my opinions, and HP's opinions, necessarily the same...

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 18:31:00 GMT
From:      firth@gate.transalta.ab.ca (006600 Al Firth, T2 4E)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <1994Jan5.171253.25083@berlioz.nsc.com>, my@laverde.nsc.com writes...
> 
>Seems like every layer of the stack add its checksum (for either the header or
>whole packet), do you really think that checksums in all layers are necessary?
> 
>For example, the Ethernet MAC will add the FCS at the end of a packet,
>IP has it own header checksum, and TCP and UDP have their own packet checksum.
>Does FTP do a checksum on the whole file also?  How about Telnet and NFS?

Remember that:
1)	TCP/IP doesn't have to use Ethernet; it could use smoke signals,
	which don't (to my knowledge) have checksums :)
2)	the IP checksum only covers the header, not the data
3)	UDP checksum is optional, if you are really daring

I don't remember about FTP/telnet, (TCP checksum should be sufficient),
NFS relies on UDP checksum ...
+------------------------------------------------------------------+

Al Firth			firtha@gate.transalta.ab.ca

#include <std/disclaimer.h>
#include <std/wittystuff.h>


-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 18:35:38 GMT
From:      Sayeed Ahmed <sayeed@kaleida.com>
To:        comp.protocols.tcp-ip
Subject:   Questio on voice over TCP/IP

What does it take to implement voice over TCP/IP. How about the sampling
rates that can be
afforded in this scenario. What will be the least in no of bits that can
be used, and what will
be the speed (minimum) of an octet.
Are there any problems associated with echo and do you require echo
cancellation.
Lastly what are the inherent problems associated with voice over
TCP/IP?????

any response enlightening us all on the net will be a great asset.

sayeed.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 19:01:51 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

When I move data from my work system to home, the work system sees an
Ethernet with FCS, but it checksums in the IP and TCP layers anyway.
That is a good thing, because that packet soon leaves the Ethernet and
goes over dial-up SLIP to get to my home.  The SLIP link has no check-
summing and is error-prone.  Because of the IP and TCP end-to-end
checksums, I am protected against errors anyway.

Watch out for the trap of assuming the IP and TCP/UDP checksums cover
the same things.  Any given part of the data is only checksummed once.
There are two checksums in a UDP/IP or TCP/IP frame, but they are
complementary, not redundant.

	Stephen

-- 
Stephen Trier  KB8PWA
Work: trier@ins.cwru.edu
Home: sct@po.cwru.edu

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 19:16:28 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

Mike Yip (my@laverde.nsc.com) wrote:

: Agree.  But if the router is good, then the problem must be on the link and
: the link layer FCS will be able to detect and throw away the packet before IP
: gets to process it.

Not all link layers have checksums.

: >... NFS doesn't do
: >checksumming either because it relies on UDP checksumming.  UDP checksums
: >can be disabled (they are optional), and people get into trouble by disabling
: >them to increase NFS throughput.  They usually turn them back on again when
: >they start getting file system corruption due to smashed NFS packets not
: >being detected.
 
: Can you tell us more about the problem when UDP checksum is turn off?
: (Assuming the error is not caused by dropped packet when link layer FCS throws
: away bad packets.)  Where else did the error come from?  

How about there being a SLIP link somewhere in this, SLIP does no
checksumming.

: Thanks for the answer.  But are we really doing too much checking?

Actually implimentations could be 'clever' determining when and when not
to checksum. 
e.g. no checksum at all through the software loopback interface
more than this gets tricky.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 19:24:19 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

Mark D. Eggers (mdeggers@wdi.disney.com) wrote:

: Is this how things should work?  I was under the impression that IP 
: fragmentation would occur at the router, and the host would always 
: use the MTU of the physical network that it is attached to.  I 
: understand that this may place an extra burden on the router to 
: perform IP fragmentation, but if the MTU does not require 
: fragmentation, then sending the larger packets should improve 
: performance.

What it is possible for the host to start a TCP connection by creating
a packet as large as its MTU, with the Dont_fragment flag set.

When it gets an ICMP error about this it reduces the packet size and
retransmits the SYN.

It is also possible that you have an implimetation where the interface
size is only used for hosts which are considered directly connected
and anything going to a router used the 576 byte size.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 20:02:08 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

In article <1994Jan6.175700.10477@acc.com> art@acc.com (Art Berggreen) writes:
> ...
>>	It's the way things should work, quotes. To avoid fragmentation,
>>which is expensive and a pain, hosts sending traffic off the local net
>>frequently revert to an MSS or MTU of 576 bytes ...
 
> ...
>This is why the Path MTU Discovery Protocol (RFC 1191) was developed.  This
>defines a method to probe the maximum packet size that can be sent to a
>destination without fragmentation.  Unfortuneately, the host support is just
>starting to show up and it'll probably be a while before it is widely
>available.

Agreed. 

It is also why 4.*BSD code has had for a very long time the
"subnetsarelocal" switch to tell the host to partially ignore the standard
that says to use 576 for distant destinations.  It is also why at least
one vendor has had the "allnetsarelocal" switch for about 6 years to be
completely nasty and evil.

As was now more years ago, I think by Milo Medin, 576 (or 512) does not
make any sense any more.  You can get 1500 byte packets clear accross the
Internet.

My point is that the original questioner might benefit from looking
for such switches.


Vernon Schryver    vjs@rhyolite.com

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 20:04:18 GMT
From:      D.Nash@utexas.edu (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?


In article <1994Jan5.231908.4522@berlioz.nsc.com>, my@laverde.nsc.com
(Mike Yip) writes:
>In article D.Nash@utexas.edu  (Donald L. Nash) writes:
>>... If the IP header gets corrupted, the
>>packet could get delivered to the wrong address or have other unhappy
 things
>>happen to it.
>
>Agree.  But if the router is good, then the problem must be on the link
>and
>the link layer FCS will be able to detect and throw away the packet
>before IP
>gets to process it.

It doesn't matter how good your router is, it will fail at some time or
other.  There are a multitude of failure modes.  One good mode we've seen
had to do with interface microcode bugs.  The Ethernet interface would
calculate a proper FCS, but would garble the last byte of the frame under
certain circumstances after it had verified the FCS.  The point is, there
will aways be bugs in systems as complicated as routers, and the only way
to protect yourself is with an end-to-end checksum.

>Can you tell us more about the problem when UDP checksum is turn off?
>(Assuming the error is not caused by dropped packet when link layer FCS throws
>away bad packets.)  Where else did the error come from?  

See my above example.  If the Ethernet interface validates the FCS but then
corrupts the packet once it is no longer covered by the FCS, then you've
got problems.  This is only one possible example.  You're making the assumption
that the packet is safe once it is inside the router and the FCS has been
verified, and it isn't.  The hazards inside a router are different than those
on the network wire, but no less dangerous.

>Thanks for the answer.  But are we really doing too much checking?

Absolutely not.

				++Don

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 20:07:48 GMT
From:      stryker@phyc.ucsf.edu (Michael P Stryker)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.appletalk,comp.sys.mac.comm
Subject:   Statement of Requirments for DOS/Windows/Mac/Unix Networking Software

We are looking for a heterogeneous TCP/IP network solution for
DOS/Windows/Macintosh/Unix within a Center at our University.  We hope
for something cheap, effective, as consistent as possible among the
different environments, and easy to maintain.

I have placed a 6-page somewhat detailed draft statement of our
requirements on phy.ucsf.edu (128.218.13.5): as file
 ~ftp/pub/netreq.txt , available for anonymous ftp.  I will welcome
comments or proposed solutions from other people in similar positions
to ours or from vendors.  I can also email the draft to those who
request it.

The IP address for phy.ucsf.edu may change in a few weeks, but the
nameserver will know the new address.

--Michael Stryker (stryker@phy.ucsf.edu, fax +1 415 476-4929)


-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 21:17:18 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: connect()-connect() question

In article <2gh6fmINNhgn@currituck.cs.unc.edu>,
Michael Burr <burr@cs.unc.edu> wrote:
>We are trying to evaluate the importance of mimicing
>this behavior in our implementation.

This is a feature of TCP.  If you do not implement it, you are not
correctly implementing TCP.

IMHO, connect-connect follows naturally from a clean TCP
implementation.  Conversely, a clean TCP that doesn't do connect-
connect may have other bugs having to do with unusual connection
opening conditions.

	Stephen

-- 
Stephen Trier  KB8PWA
Work: trier@ins.cwru.edu
Home: sct@po.cwru.edu

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 94 02:19:01
From:      deraadt@fsa.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Local Full Hostname?

In article <2gf63u$o0t@tigern.nvg.unit.no> agulbra@tigern.nvg.unit.no (Arnt Gulbrandsen) writes:
   [good best-effort code deleted]

   Btw, getdomainname() returns the YP/NIS domain (where I live, at
   least), which in principle has nothing to do with the DNS domain.

I'd like to mention a `trick' that you should not be fooled into using.

In a YP domain, if you perform a gethostbyname() on `foo.' (note
trailing dot) YP will translate that into, eg. `foo.bar.com'. It will
do this even if the hosts.byname does not contain such an alias. It
looks like the trailing dot forces YP to talk to the DNS server.

Don't use or rely on this trick. I'm pretty sure it is a ypserv bug
Thinking about the semantics, I argue that `foo.' should mean that
"the host foo is at the root level of the domain space".

Use Arnt's code -- it's the best effort, and should work in all cases, ie.
DNS-only, YP/DNS, YP-only, svc.conf-based, or /etc/hosts based
configurations.
--
This space not left unintentionally unblank.		deraadt@fsa.ca

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 21:30:14 GMT
From:      MMORSE@nsf.gov (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Telnet option negotiation

I am talking to a terminal server from a PC that runs a terminal emulator 
over TCP/IP.  I telnet to the terminal server which then connects me to one 
of a pool of modems.  The terminal server (brand name withheld to protect 
the potentially innocent) has a behavior that is causing me a lot of 
problems, and sometimes sets off a option bidding war (I don't know what the 
exact jargon for this is).

Here's what the terminal server does:

 1. When the connection is made, starts the negotiation with:
        WILL ECHO

 2. If it receives a DO ECHO within 5 seconds, everything is cool (except 
    that it doesn't really echo, but that's another story).

 3. If, after 5 seconds, it doesn't receive the DO ECHO, it changes its
    mind and sends a WONT ECHO.
 
The problem is that I have some very slow PC's, and the architecture of the 
terminal emulator program adds a delay, so sometimes the PC can't return the 
DO ECHO within 5 seconds.  When that happens, the terminal server gets 
confused and forever alternates between WILL ECHO and WONT echo, frequently 
in the same TCP/IP packet.

My question:  Is this behavior allowed?  It seems to me that anything timing-
based in a TCP connection is a real bad idea, since the network might be 
real slow, but I don't see anything in the RFC that specifically prohibits 
it.  For all I know, the developers stuck it in to solve some *other* 
problem.  The problem as I see it is that once the 5 seconds pass, the 
terminal server has, in effect, contradictory options out there waiting to 
be processed, and that seems to prevent the normal loop-prevention 
mechanisms from working.  But I'd like to hear from more experienced folks 
before I complain too loudly to the vendor.

Thanks.

--Mike

Michael Morse                           Internet: mmorse@nsf.gov
National Science Foundation               BITNET: mmorse@NSF
1800 G St. N.W. Room 401               Telephone: (202) 357-7659
Washington, D.C.  20550                      FAX: (202) 357-7663

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 94 23:58:36 GMT
From:      uzn10@JUTS.ccc.amdahl.com (Uday Naik)
To:        comp.protocols.tcp-ip
Subject:   Telescript Info.


 Hi : 
 
 I am interested in getting info. on "Telescript". I would really
 apperciate if someone out there knows something about it, would
 care to drop me a e-mail :-).

 The only thing I know about it is that it is used to access Internet.
 But, I may be wrong !! 

 Thks.


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 00:59:07 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!

In article <1994Jan5.223231.2714@acc.com> art@acc.com (Art Berggreen) writes:
>Actually Ethertypes are officially registered with Xerox. IANA only includes
>a partial list in the Assigned Numbers RFCs.  But you are probably right
>about the use of OUI 00-00-00 being a defacto standard.  I have never seen
>an IEEE document which "grandfathers" the Xerox Ethertypes under that OUI.

I'm not a historical authority, but I thought the OUI 0-0-0 was
Xerox's (it makes sense that they'd give themselves the very first
OUI, I'd think), and that Xerox donated their OUI to indicate that the
last two bytes of the SNAP header was an ethernet type code.  This
wouldn't require an IEEE document any more than Novell assigning the
SNAP code 0-0-1b-81-37 to IPX would.

In this light, it's not clear why any other OUI's other than 0-0-0
should be used for the same purpose simply because a company happens
to have a network layer protocol that has to be identified in SNAP.
In fact, I'd think they'd be better off saving their OUI's for a rainy
day.  (Apple had an excuse: as I understand it, they had to invent a
different protocol ID for their newer extended network AppleTalk to
distinquish it from the older AppleTalk.)

But then, I'm not a big fan of using SNAP on ethernet to begin with
and, happily, IPX on SNAP/802.3 is not very common anyway.  (Not that
what *is* common for IPX on 802.3 networks is very pretty, but let's
not rehash that...)

>Once it was agreed that a new header was being added, fixing the
>alignment that 802.2 broke, was a natural feature.

I wish I was there for the thrill when the existing three byte OUI,
the existing two byte ethernet type values, and the existing three
byte 802.2 header all came together to form an eight byte header.  A
power of 2, no less!  I can just imagine the person that first occured
to spontaneously standing up and shouting "Jackpot!"  It sure sent a
chill down my spine when I first heard of it: destiny!  I wonder who
first thought of it?

						don provan
						donp@novell.com

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 94 01:14:45 GMT
From:      ibeshir@nyx.cs.du.edu (Ibrahim)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wwanted security door fro pctcp


Hi
	Maybe this a FAQ question. I am looking for a security
	front fro tcpip, public domain comperical.
	any information helps

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 94 02:28:00 GMT
From:      john.will@satalink.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are need

I >I'd agree with Vernon.  I've just checked on our Auspex, and its IP
I >layer has handled 428701753 packets of which 7 were bad.  That's packets
I >where the ethernet checksum was OK but the payload was corrupt.  I don't
I >want those anywhere near my systems, especially in NFS.

I have to jump in on this bandwagon too. :-)  I can't imagine sending
packets through the diverse layers they have to go through on the Internet
without some sort of end-to-end data integrity.  I wonder if the original
poster would send serial data through the phone lines with no checksums? :-)

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 09:11:08 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <2gip1q$sk5@klaava.Helsinki.FI> Tom.Soderlund@Helsinki.FI writes:
    
    I would like to point out that the IP header checksum is counted
    hop-by-hop.  This is because routers change the IP header (e.g., Time To
    Live and Options fields).  Counting the header checksum hop-by-hop
    doesn't actually provide end-to-end integrity on the header.  There is a
    possibility that the header changes (e.g., the Destination field) due to
    some error before the router counts new header checksum.  In this case
    hop-by-hop integrity is achieved (from the routers' point of view;
    checksum is correct) but end-to-end integrity is broken.  The datagram
    might go to wrong destination.  (I guess this is one of the reasons why
    TCP and UDP use a pseudo header when counting end-to-end checksums). 

Quite true, except that in the normal course of events, routers do not
recalculate the IP header checksum.  Instead, they just modify the existing
one to compensate for the change in TTL.  Thus, even if corruption occurs
in the router after the header checksum is verified, the corruption would
not be reflected in the outbound checksum, and the packet would be found in
error at the next hop.  While this is not true end-to-end integrity, it's
better than just hop-by-hop integrity.

Tony




-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 09:47:58 GMT
From:      edward@comserv_fddi.itri.org.tw (Chao-Chi Yang 37h3100)
To:        comp.protocols.tcp-ip
Subject:   Question about Packet Fragmentation

Hi,

   I try to write a testing program for transmitting
digital video between two Sun Sparc machines running
SunOs 4.1.3.  

   The question is - how to send a packet which
has size greater than 1500 octets (Ethernet MTU)   
by TCP/IP datagram service.

   When the packet size is large than 1500, the socket
primitive 'sendto' will set 'errno' to 40 (message too
long).  Does I must deal with the packet fragmentation
myself ? 


Thanks.

Edward Yang 

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 06:39:22 +0200
From:      soderlun@klaava.Helsinki.FI (Tom Soderlund)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

Donald L. Nash <D.Nash@utexas.edu> wrote:

>IP needs its own header checksum to provide end-to-end integrity on the
>header. [...]

I would like to point out that the IP header checksum is counted
hop-by-hop.  This is because routers change the IP header (e.g., Time To
Live and Options fields).  Counting the header checksum hop-by-hop
doesn't actually provide end-to-end integrity on the header.  There is a
possibility that the header changes (e.g., the Destination field) due to
some error before the router counts new header checksum.  In this case
hop-by-hop integrity is achieved (from the routers' point of view;
checksum is correct) but end-to-end integrity is broken.  The datagram
might go to wrong destination.  (I guess this is one of the reasons why
TCP and UDP use a pseudo header when counting end-to-end checksums). 
-- 
Tom.Soderlund@Helsinki.FI

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1994 01:15:51 -0800
From:      glenc@halcyon.com (Glen Clark)
To:        comp.protocols.tcp-ip
Subject:   Wanted: PD Source for Telnet Daemon

Looking for sample source to a telnet daemon, server 
or what ever.  Any input would greatly be appreciated.

Sincerely,
Glen Clark
ESDL, Inc.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 14:11:12 GMT
From:      weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or

fred@maccs.mcmaster.ca (Fred Whiteside) writes:

>	To the best of my knowlege, Novell's LWP does not support
>packet drivers natively.  It is possible that some combination of the
>various shims would get you there, although I can't think of one that
>presents an ODI interface while talking to packet drivers.  

Well, there is pdether, doing just that for ethernet. If my assumption, that
the slip packet driver in question pretends to be ethernet towards the
application, is correct, then this one should run.

Regards

Christoph Weber-Fahr


-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de 
  Universitaet Kaiserslautern,  KIT     |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-67653 Kaiserslautern
--------------------------  My personal opinion only    ---------------------

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Jan 94 15:24:23 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Unix routing considered harmful


		Unix Routing Considered Harmful
	Copyright 1994 by Russell Nelson <nelson@crynwr.com>
	    Distribute freely but acknowledge authorship


Unix systems[1] have the idea that they sit on a subnet[2].  On this
subnet are a number of machines, all with addresses on the same
subnet.  Therefore, you may associate a subnet with an interface[3].
All hosts directly reachable by that interface are on the subnet, and
vice-versa.  Any routers reachable by that host are on that machine's
subnet. This idea is dead wrong.

Subnet/interface correspondence causes two problems: hosts must
respond to a different IP address on each subnet they're on
(multihoming) and each SLIP link must be its own subnet.

Multihoming is not forced on us by the TCP/IP protocol suite.  It is
an artifice of the subnet/interface correspondence.  Since the only
reachable hosts are on the interface's subnet, then a Unix host that
is on two subnets must have two IP addresses.

The TCP/IP protocol suite, on the other hand, merely requires that
each host have at least one IP address.  And, there is reason why a
host might want to have sequentially-numbered addresses.  Say, for
example, you were providing TCP/IP services for multiple parties.
Each party would want to appear as if it had its own host.  So
instead of creating a cname record for server.customer.com that
points to your machine, you would create an A record for one of the
multiple addresses.  Then your server would provide the services you
sold to the party.

Unix routing is similarly confused about SLIP links.  You will hear
people repeat, as if it were a mantra, that each SLIP link
must have its own address.  This is only true for Unix because Unix
wants to route to subnets.

The prescription I propose is to remove the subnet/interface
correspondence.  Split the TCP/IP address space up into bands, and
route each band onto the appropriate interface or router.  If you
route something to a router, then you must have a route *to* the
router.  So, routing for my net might consist of

# All of my hosts are on my Ethernet, which has 24 bits set in net mask.
route add 192.203.178.0/24 eth0
# Only, when I call in with my laptop, its packets go out the slip link
route add 192.203.178.17 slip0
# Everything else goes out my router
route add default 192.203.178.254


	[1] Every Unix I've seen.  Perhaps someone's gotten it right.
	[2] One or more subnets.
	[3] Ethernet, Token Ring, SLIP, PPP, etc.

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 17:24:55 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X.25: info needed

In article <2ghsut$a42@hebron.connected.com> dave@hebron.connected.com (Dave Perlin) writes:
>I seem to remember a number of months ago there being some discussions on 
>the performance of TCP/IP over X.25.  I'm now looking for general
>info on the subject (ie. issues/problems) as well as specific real
>life accounts from people on how well things run.

Having been around IP over X.25 for a long time, I thought that I'd add my $0.02.

There tends to be two major problems, running a connectionless data stream over a
connection oriented service, and the behavior of most typical X.25 networks.

To run the connectionless data over X.25, you have to derive the information for
X.25 call management by analysis of the traffic streams.  When, and if extra VCs
should be opened, and when VCs should be closed can get tricky under some particular
circumstances.

The end-to-end flow control and typical X.25 window sizes (both packet size and
packet window) tend to inhibit the performance of X.25 networks and cause them to
exhibit farily large delays.  (not that better X.25 nets can't be built, just that
what is typically found is usually not well suited for IP)  A default packet size
of 128 bytes and a window of 2 is a very small amount of data to be in flight
compared with typical TCP windows (say 8k, and getting larger).  If the X.25
packet size and/or window can't be negotiated up, then it may be possible to open
multiple VCs to the same destination. to increase the effective available window.
But this complicates VC management and allows reordering of IP packets.  Also,
it is difficult to distinguish between congestion caused by windowing limitations
vs exit congestion at the other side of the X.25 network.  Opening extra VCs
because of exit congestion just wastes valuable VC resources (which are typically
limited in number) and often costs more.

Art


-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 19:03:14 GMT
From:      markm@kandinsky.intel.com (Mark Morrissey)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful

nelson@crynwr.com (Russell Nelson) writes:


>		Unix Routing Considered Harmful
>	Copyright 1994 by Russell Nelson <nelson@crynwr.com>
>	    Distribute freely but acknowledge authorship

You haven't said how UNIX routing is harmful.  All that you
have said is that you want to do range-based forwarding to
an interface ala a router.

Maybe you can explain the relationship of your title to your
argument.

--mark
---
Mark Morrissey                    Intel Corp.
Senior Engineer                   Portland, Oregon  USA
UNIX & NT Operating Systems       +1 503 696 2068
markm@kandinsky.intel.com         #include <disclaimer.std>
"I don't speak for them.  They don't speak for me."

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 19:07:55 GMT
From:      mcquill@keen.ccit.duq.edu (Tod McQuillin)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful

Russell Nelson (nelson@crynwr.com) wrote:

: Unix routing is similarly confused about SLIP links.  You will hear
: people repeat, as if it were a mantra, that each SLIP link
: must have its own address.  This is only true for Unix because Unix
: wants to route to subnets.

This isn't true of BSD derived Unix, since the network interface (en0, un0,
sl0, etc.) is stored along with the network/host IP address in the kernel's
routing table.  I run multiple slip connections on a 4.3BSD machine, and
all of the slip interfaces have the same IP address as the ethernet
interface.  This setup has been working flawlessly for over a year now.
--
Tod McQuillin

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 19:12:03 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <CJ8Ctq.q2@atlas.abccomp.oz.au> paul@atlas.abccomp.oz.au (Paul Brooks) writes:

>	TCP/IP can't assume that every link a packet travels over between
>Vancouver and Mawson Base in Antarctica is protected by a link-level
>error check - and ship-board radio is not known for its error-free properties!

One reason to use an RF link protocol with a checksum is the known
noise of RF channels.  Most RF link protocols in common use DO include
a link-layer checksum for this reason.  All the RF link protocols that
I am aware of do include a link layer checksum.  It is only prudent.

The IP header checksum does not, in practice, buy much for anyone and
it can be fairly expensive.  Use of the UDP checksum should be
mandatory for the end-to-end integrity.  Sun ships their OSs with the
UDP checksum turned off, but that is easily fixed fortunately.

Ran
atkinson@itd.nrl.navy.mil

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 19:13:46 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

PATH MTU DISCOVERY is the right technology for this problem.
Please go beat on your vendors if they aren't already implementing it.

Ran
atkinson@itd.nrl.navy.mil




-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 19:28:03 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful

In article <757956263snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
   Unix systems[1] have the idea that they sit on a subnet[2].  On
   this subnet are a number of machines, all with addresses on the
   same subnet.  Therefore, you may associate a subnet with an
   interface[3].  All hosts directly reachable by that interface are
   on the subnet, and vice-versa.

Non-broadcast interfaces can reach destinations not on the same
subnet.

   two problems: hosts must respond to a different IP address on each
   subnet they're on (multihoming) and each SLIP link must be its own
   subnet.

Why must each SLIP link be its own subnet?  How wasteful of the
address space!

   Since the only reachable hosts are on the interface's subnet, then
   a Unix host that is on two subnets must have two IP addresses.

If a UNIX host has an interface on each of two broadcast networks,
then each interface must have a different address.  If a UNIX host has
point-to-point links to each of two hosts, the local end of each
point-to-point link may have the same address, though the links'
destinations must differ.

   Unix routing is similarly confused about SLIP links.  You will hear
   people repeat, as if it were a mantra, that each SLIP link must
   have its own address.  This is only true for Unix because Unix
   wants to route to subnets.

This is only true of some SLIP implementations.  UNIX routes to
destinations.

   [1] Every Unix I've seen.  Perhaps someone's gotten it right.

I think this is a limitation of the SLIPs you've seen, not of the
UNIXes you've seen.

   [3] Ethernet, Token Ring, SLIP, PPP, etc.

Ah, here's the basis of the misunderstanding (yours and the authors of
the SLIPs you've used): An interface on an Ethernet or Token Ring
network is not the same as a point-to-point link.  A point-to-point
link is not a network, it's a way to get to a particular host.

As an example, here's a snapshot of one of the systems (SunOS 4.1.2)
on our network.  le0 is its interface on our Ethernet LAN, and du* are
its "DialUp" PPP and SLIP links to various remote systems.  Note that
(1) the local end of most of the point-to-point links use the same
address (coincidentally, also the same address as this system uses on
its Ethernet interface), (2) some of the local ends are different, (3)
the remote ends of some point-to-point links are on the same network
as the local ends, and (4) the remote ends of some point-to-point
links are on different networks from the local ends.

# ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
	inet 137.175.2.7 netmask ffffff00 broadcast 137.175.2.255
	ether 8:0:20:7:73:e4 
lo0: flags=49<UP,LOOPBACK,RUNNING>
	inet 127.0.0.1 netmask ff000000 
du0: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.2.7 --> 137.175.6.13 netmask ffffff00 
du1: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.2.7 --> 137.175.6.6 netmask ffffff00 
du2: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.2.7 --> 137.175.2.6 netmask ffffff00 
du3: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.2.7 --> 137.175.2.38 netmask ffffff00 
du4: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.2.7 --> 137.175.2.198 netmask ffffff00 
du5: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.8.7 --> 137.175.8.2 netmask ffffff00 
du6: flags=51<UP,POINTOPOINT,RUNNING>
	inet 137.175.2.7 --> 137.175.6.7 netmask ffffff00 
du7: flags=51<UP,POINTOPOINT,RUNNING>
	inet 42.43.44.45 --> 42.46.47.48 netmask ff000000 
du8: flags=10<POINTOPOINT>
	inet 137.175.42.42 --> 137.175.42.52 netmask ffff0000 
du9: flags=10<POINTOPOINT>
	inet 137.175.42.42 --> 137.175.42.51 netmask ffff0000 
du10: flags=10<POINTOPOINT>
	inet 137.175.42.42 --> 137.175.42.53 netmask ffff0000 
du11: flags=10<POINTOPOINT>
	inet 137.175.42.42 --> 137.175.42.50 netmask ffff0000 
du12: flags=10<POINTOPOINT>
	inet 140.76.27.185 --> 140.76.27.184 netmask ffff0000 
du13: flags=10<POINTOPOINT>
	inet 140.76.27.185 --> 140.76.27.185 netmask ffff0000 
du14: flags=51<UP,POINTOPOINT,RUNNING>
	inet 192.5.58.18 --> 192.9.200.1 netmask ffffff00 
du15: flags=51<UP,POINTOPOINT,RUNNING>
	inet 42.43.44.45 --> 46.47.48.49 netmask ff000000 
# netstat -ina
Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue 
le0   1500 137.175.2.0   137.175.2.7    3289130 7    3033571 105  63631  0     
lo0   1536 127.0.0.0     127.0.0.1      8257    0    8257    0    0      0     
du0   1500 137.175.6.13  137.175.2.7    54815   0    53048   50   0      0     
du1   1500 137.175.6.6   137.175.2.7    22163   0    49832   237  0      0     
du2   1500 137.175.2.6   137.175.2.7    0       0    5513    0    0      0     
du3   1500 137.175.2.38  137.175.2.7    7143    0    9264    2738 0      0     
du4   1500 137.175.2.198 137.175.2.7    0       0    1989    0    0      0     
du5   1500 137.175.8.2   137.175.8.7    0       0    1989    0    0      0     
du6   256  137.175.6.7   137.175.2.7    16160   0    50685   31   0      0     
du7   1500 42.46.47.48   42.43.44.45    7636    0    4177    0    0      0     
du8*  1500 137.175.42.52 137.175.42.42  1687    0    1653    0    0      0     
du9*  1500 137.175.42.51 137.175.42.42  297     0    197     0    0      0     
du:*  1500 137.175.42.53 137.175.42.42  186     0    171     0    0      0     
du;*  1500 137.175.42.50 137.175.42.42  111     0    19      0    0      0     
du<*  1500 140.76.27.184 140.76.27.185  0       0    36      0    0      0     
du=*  1500 140.76.27.185 140.76.27.185  0       0    2       0    0      0     
du>   1500 192.9.200.1   192.5.58.18    0       0    0       0    0      0     
du?   1500 46.47.48.49   42.43.44.45    0       0    0       0    0      0     
# netstat -rn
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
42.46.47.48          42.43.44.45          UH       0      0          du7
137.175.13.0         137.175.6.6          UGH      0      0          du1
46.47.48.49          42.43.44.45          UH       0      0          du15
192.9.200.1          192.5.58.18          UH       0      0          du14
127.0.0.1            127.0.0.1            UH       24     3550       lo0
137.175.8.2          137.175.8.7          UH       0      1989       du5
137.175.6.12         137.175.6.13         UGH      0      26196      du0
137.175.6.13         137.175.2.7          UH       0      121        du0
137.175.6.6          137.175.2.7          UH       1      20         du1
137.175.2.38         137.175.2.7          UH       0      7          du3
137.175.2.198        137.175.2.7          UH       0      1989       du4
137.175.2.6          137.175.2.7          UH       0      3567       du2
137.175.6.7          137.175.2.7          UH       0      34         du6
default              137.175.2.1          UG       0      469544     le0
137.175.2.0          137.175.2.7          U        34     2359770    le0
#
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 18:04:40 +0100
From:      pah@dfv.rwth-aachen.de (Patrick Heinzberger)
To:        comp.protocols.tcp-ip
Subject:   RFC 939  - full report


Hi everybody,
 
Since I'm working on an evaluation study of TCP in comparision with
TP, I read through RFC 939. Now, I am interested in the full report:
 
"Transport Protocols for Department of Defense Data Networks",
Report to the Department of Defense and the National Bureau of 
Standards  Committee on Computer-Computer Communication Protocols,
Board on Telecommunications and Computer Applications Comission on
Engineering and Technical Systems, National Research Council,
National Academy Press, Washington, D.C. February 1985
      
I tried to get it from the related address but I didn't receive an 
answer.
Who can give me information where and how to get it?
 
Thanks, 

Patrick

      

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 20:25:35 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Security Issues?

In article <2gi29q$1mo@stargate.promus.com> jlarocqu@promus.com (Joe La Rocque) writes:
>	My position on this is that a SLIP is no more secure or
>	insecure than a getty.  Both require you to login to the
>	system with a password (unless you are dumb enough to create
>	a user without a password), you can disallow rcp/ftp (something
>	you can't do with a normal serial connection: the user could
>	issue sz or rz to transfer files), so I don't grasp their
>	point of view.

SLIP makes the remote system a full-fledged network host, so it could run
servers for lots of different protocols.  While administrators may be able
to exercise some control over the servers run on machines at the office
(but even this is hard, which is why firewalls are commonly used), they
have virtually no control over what you run on your home machine.

A getty, on the other hand, only lets you login.  Unless you know the root
password, you there are many things you can't do from a getty, but you
could do them on your home machine.

Also, you said, "you can disallow rcp/ftp".  If you mean that you could
prevent the SLIP user from using these to transfer files to his home
machine, you're wrong.  FTP doesn't require any special privilege, so even
if the site deletes it from their system, the user could install his own.
Also, even if the user can't use ftp, he can transfer a file through the
telnet connection simply by catting it and telling the home system to
capture everything to a file.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 20:42:40 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   raw socket questions


   I have questions about raw sockets on Unix - Sun 4.1.x in
particular. The FM isn't particularly clear on how they are handled. 
I have the FS but I could still use some pointers.

  Suppose I open a raw socket in the inet address family, make it
SOCK_RAW but use my own protocol number  (thats what it is there for
isn't it). How is that processed in the kernel?

  I am working with a sort of encapulation protocol called SWIPE and I
have a pseudo device to support in on the output side but the device
wants to encrypt/authenticate everything that goes out and I want to
send some stuff out un{encryupted,authenticated}. My idea is to build
the packet I want right down to the checksum, like in "ping" and send
it outthe raw socket but I don't want the psuedo device to tamper with
it.

                                Jerry Freedman,Jr

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 20:48:04 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Can telnet report origin?

bill daniels (bill@banana.dis.fedex.com) wrote:
: Is it possible to find out where a telnet session originates?  I have an
: application that needs to report the IP address and TCP port number of
: the device that originated the telnet session.
 
: The scenario would be:
 
: 1) a user telnets to a host
: 2) the user runs a particular application
: 3) the application determines the originating IP address and TCP port.
: 4) the application logs the origin info
: 5) the user goes merrily about his way
 
: Any help would be greatly appreciated.

The easiest way to do this is to put a program in /etc/inetd.conf
which will hang off port 23 and report these details then run 
telnetd, otherwise only the telnetd process knows the port number.

There are other ways of finding out, but they are non-portable.

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 20:53:02 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Packet Fragmentation

In article <2gjb4e$5a9@news.csie.nctu.edu.tw> edward@comserv_fddi.itri.org.tw (Chao-Chi Yang 37h3100) writes:
>   When the packet size is large than 1500, the socket
>primitive 'sendto' will set 'errno' to 40 (message too
>long).  Does I must deal with the packet fragmentation
>myself ? 

Are you trying to send broadcasts?  Many IP implementations (including
Sun's) will not fragment broadcast packets.

If you're sending unicast packets, I think the default UDP size limit is
8K, but there's an ioctl to increase it on a per-socket basis.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 20:57:55 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

Paul Brooks (paul@atlas.abccomp.oz.au) wrote:

: You are assuming the link _HAS_ a FCS - ethernet has, but not all IP runs
: over ethernet. In fact, much of IP travels over standard phone lines
: using SLIP or PPP, and these usually have no error checking, so the receiver
: can't tell if it has a valid packet or a line hit. Remember, TCP/IP is

It is a pity that these protocols do not have any FCS, or even in the
case of SLIP much in the way of proper framing. There is a good reason
for having a packet header giving length, since it tells the reciever 
how much data to expect. Just relying on an end of packet code can be 
unreliable.

: designed for the global environment. If it was only to be used over a local
: ethernet, you might want to disable the "overhead" of other checksums -

The problem is that it might be as costly (or even more costly) in terms
of processing to verify if a packet really has come from the local network
as to do the checksuming. Anyway you still need the IP checksum to do this.

: thats what Novell do with IPX, I understand, because it is only designed
: for local operation, and they ran into larger data-corruption problems
: running over un-protected links.

As does NFS due to UDP checksumming being disabled by default.

: 	TCP/IP can't assume that every link a packet travels over between
: Vancouver and Mawson Base in Antarctica is protected by a link-level
: error check - and ship-board radio is not known for its error-free properties!

What protocols are used for radio links, and what FCS do they use?

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 21:00:49 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

Tony Li (tli@cisco.com) wrote:

: Quite true, except that in the normal course of events, routers do not
: recalculate the IP header checksum.  Instead, they just modify the existing
: one to compensate for the change in TTL.  Thus, even if corruption occurs

Works fine until someone starts sticking source route or record route options
in.

It's not impossible that someone might consider it to be a good idea to use source
routing for their TCP connection.....

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 21:02:49 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet option negotiation

In article <MMORSE.273.757891814@nsf.gov> MMORSE@nsf.gov (Michael Morse) writes:
>Here's what the terminal server does:
> 1. When the connection is made, starts the negotiation with:
>        WILL ECHO
> 2. If it receives a DO ECHO within 5 seconds, everything is cool (except 
>    that it doesn't really echo, but that's another story).
> 3. If, after 5 seconds, it doesn't receive the DO ECHO, it changes its
>    mind and sends a WONT ECHO.
>My question:  Is this behavior allowed?

No.  From RFC 854:

   3.  The symmetry of the negotiation syntax can potentially lead to
   nonterminating acknowledgment loops -- each party seeing the incoming
   commands not as acknowledgments but as new requests which must be
   acknowledged.  To prevent such loops, the following rules prevail:

      a. Parties may only request a change in option status; i.e., a
      party may not send out a "request" merely to announce what mode it
      is in.

      b. If a party receives what appears to be a request to enter some
      mode it is already in, the request should not be acknowledged.
      This non-response is essential to prevent endless loops in the
      negotiation.  It is required that a response be sent to requests
      for a change of mode -- even if the mode is not changed.

      c. Whenever one party sends an option command to a second party,
      whether as a request or an acknowledgment, and use of the option
      will have any effect on the processing of the data being sent from
      the first party to the second, then the command must be inserted
      in the data stream at the point where it is desired that it take
      effect.  (It should be noted that some time will elapse between
      the transmission of a request and the receipt of an
      acknowledgment, which may be negative.  Thus, a host may wish to
      buffer data, after requesting an option, until it learns whether
      the request is accepted or rejected, in order to hide the
      "uncertainty period" from the user.)

>  It seems to me that anything timing-
>based in a TCP connection is a real bad idea, since the network might be 
>real slow, but I don't see anything in the RFC that specifically prohibits 
>it.  For all I know, the developers stuck it in to solve some *other* 
>problem.  The problem as I see it is that once the 5 seconds pass, the 
>terminal server has, in effect, contradictory options out there waiting to 
>be processed, and that seems to prevent the normal loop-prevention 
>mechanisms from working.  But I'd like to hear from more experienced folks 
>before I complain too loudly to the vendor.

The terminal server is violating rule "a", which is why it's getting into a
loop.  Until the PC acknowledges the WILL echo with a DO ECHO, the server
is still in WONT ECHO state, so it shouldn't send out a redundant WONT ECHO.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 21:04:56 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers

Joe Doupnik (jrd@cc.usu.edu) wrote:

: 	The argument against is that of facing reality: not all TCP hosts
: can deal with IP frags. Yes, I know what Host Requirements says, but
: RFC-1122 does not create code for people.

Notably PC telnet applications. 
The user might not be in a position to simply 'get a system which isn't 
broken'

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 23:40:23 GMT
From:      stam@netcom.com (David Stam)
To:        comp.protocols.tcp-ip
Subject:   UNIX TCP/IP packet sniffer?

Does there exist a program which will display source and target IP 
address #s and port #s for packets travelling across a specified network
interface on a Unix machine (SunOs)?  Better yet, can the network drivers
be configured to display this as debugging info?

I am trying to determine what is using up bandwidth on a SLIP line when
there are no apparent network connections.  Any help would be appreciated.

Thanks,

David Stam 
stam@netcom.com


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Sat, 08 Jan 1994 00:01:32 GMT
From:      hwillett@dyna_soft.win.net (Herman Rouge Willett)
To:        comp.protocols.tcp-ip
Subject:   Re: Alternate IP & MAC Address (Perfectly OK)

 
In article <2966996418.2.p00231@psilink.com>, "Mark Lo Chiano" (p00231@psilink.com) writes:
>       We have a need to create an application that must broadcast certain
>UPD messages using an IP address & MAC of several other machines.
>In this application the broadcasting machine acts as a proxy for the alternate
>machines.
>
>       We are are QUITE aware that this is not a normal practice, but this
>is necessary.  So flame away....
>
>       We have identified two alternate methods for that appear 
>fruitful, and would like comments on OTHER possible approaches.
>
>       The first approach is to utilize two ethernet cards in the 
>broadcast machine.  The first ethernet card would operate normally and receive
>normal IP traffic.  The second card would only broadcast these special 
>messages, but would not receive any traffic.  Under this approach, we 
>would use fcntl() to reset the IP address of the second card prior to 
>the broadcast.  This is expected to cause significant overhead, 
>however, that is quite acceptable.  This approach would seem to have the
>potential to allow the IP address to be altered but not the MAC address.
>
>       The second approach is to replace the current IP layer for the machine.
>Under this approach, we would essentially 'break' IP to relax the 
>bind() commands built in checks.  These normal (and proper) checks prevent 
>UPD socket binds that specify a local IP address from specifying an address
>other that the correct local IP as configured by ifconfig.  This approach
>would seem to allow both the IP and MAC accresses to be altered.
>
>       All comments are welcome.....I realize that this is potentially a
>sensitive subject, so it may be appropriate to respond via Email.
>

I want say which NICs, but some can be programed on the fly with new
MAC addresses.  I would suggest that you check with you local network
dealership.



--
Herman R. Willett                       Internet hwillet@dyna_soft.win.com
Connectivity Specialist                 CIS ID: 75160,2005
Dynamic Software Solutions
5860 Picadilly Lane
Beaumont, Tx. 77708                     
(409) 899-2721 (Voice)
(409) 899-1709 (Data)
(409) 757-5276 (Pager)                  Use objects to manage network routes
****************************************************************************
*     DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER    *
*                                                                          *
*  The answers or advice given here in is for information purposes only.   *
* If you should choose, in your own mind, to use or impliment any of the   *
* suggestions contained herein, please do so at your own risk.             *
*==========================================================================*
*  This is a sad reflection on our society today, disclaimers and such, but*
* as I have been told, and so recently learned from a friends 

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 00:31:04 GMT
From:      John Matthews <matthews@mis.uswest.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Intelligent BOOTP servers?

Can someone out there tell if anyone's written an intelligent
BOOTP server for SunOS 4.1.2?  What I'm looking for is a BOOTP
server that can automatically assign IP addresses based upon
the source IP address in a BOOTP packet (which would be the
IP address of the router interface that forwarded the packet).
I'd also like it to be able to look in an ARP cache database
and reply with an IP address if one's already been in use by
that specific device.  Lan Workgroup from Novell does most of
this except being able to compare against a master arp cache
database.  I'd also like to have this running on UNIX instead
of a Novell Fileserver.  I've been considering re-writing one
of the existing BOOTP servers to do what I want, but I thought
I'd ask here first.
			Thanks in advance,
				John Matthews
				matthews@mis.uswest.com

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:15:34 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful

In article <757956263snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>  ....
 
>Unix routing is similarly confused about SLIP links.  You will hear
>people repeat, as if it were a mantra, that each SLIP link
>must have its own address.  This is only true for Unix because Unix
>wants to route to subnets.

No, that is false.  The people who use that mantra are invoking the devil
(at least the devils of extra hassles and effort, if nothing more satanic)

In the obvious way to implement SLIP on BSD style UNIX, you do not need
any additional IP addresses or IP network or subnetwork numbers.  It is
easiest to make SLIP (or PPP) work so that the IP addresses on the two
ends of the point-to-point link are same as the IP addresses of one of
the Ethernet (or whatever) interfaces of the two machines.

Even the standard 4.3BSD RIP daemon, `routed`, has no trouble (after you
fix a bug or three) with such a setup.

Yes, sometimes it the least work and hassle way is to have a special
network for each link, but not in general, whether connecting two networks
or an isolated computer to a network.

(I speak from experience having used such things for years, and as the
solitary PPP and SLIP implementor and maintainer for a major workstation
vendor.)


Vernon Schryver    vjs@rhyolite.com

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:20:38 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <CJ9xC3.1v4@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
> ...
>The IP header checksum does not, in practice, buy much for anyone and
>it can be fairly expensive. ....

I disagree with the first part of that sentence.

The IP header checksum is very cheap to compute for the common case,
consisting of between 5 and 11 add instructions, 0 or 1 shifts, the
instructions to fetch 20 bytes as 16 or 32 bit words, and one 16-bit store.

I don't know how much evil the IP checksum prevents, given the UDP and
TCP checksums, but the IP checksum is even cheaper and easier than their
psuedo-header checksums.


Vernon Schryver    vjs@rhyolite.com

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:24:29 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   IP address with mail?

Ok, what (if any) is the proper format for a mail address using an
IP address?  I am working on a server which defaults to IP address
if name resolution fails.  This address is not liked as a return
address by other mail programs.

	Steve_Lawson@xxxx.xxxx.com works fine on a reply, but
	Steve_Lawson@NNN.NNN.NNN.NNN bounces with 'name not found'


-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:48:55 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <CJA2DD.3GC@aston.ac.uk>,
Mark Evans <evansmp@mb48026.aston.ac.uk> wrote:
>Tony Li (tli@cisco.com) wrote:
>
>: Quite true, except that in the normal course of events, routers do not
>: recalculate the IP header checksum.  Instead, they just modify the existing
>: one to compensate for the change in TTL.  Thus, even if corruption occurs
>
>Works fine until someone starts sticking source route or record route options
>in.

This is true.  If an implementation takes the "optimize for the usual case"
approach, though, optioned packets take another (slower) path through the 
router.  As long as "usual" remains fairly constant, this is a good approach.

Include my vote for end-to-end checking even stronger than the IP checksum
(for those apps which really need it).  The internal BGP implementation used
to provide NSFnet service, for example, currently uses a digital signature.

Steve


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1994 04:24:43 GMT
From:      anchiu@unixg.ubc.ca (Alan Nga-Lun Chiu)
To:        comp.protocols.tcp-ip
Subject:   What's needed to use SLIP?


I have an IBM-PC at home and the unversity I go to offers SLIP but I don't
know if I need to have special software running on my machine to use it. 
Could any kind person out there help me?  Thanks!

AC


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1994 07:00:32 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address with mail?

In article <lawsonCJAEKw.Hx1@netcom.com> lawson@netcom.com (Steven Lawson) writes:
>Ok, what (if any) is the proper format for a mail address using an
>IP address?  

user@[NNN.NNN.NNN.NNN]
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1994 07:36:03 GMT
From:      gendreau@sc.hp.com (Jim Gendreau)
To:        comp.protocols.ibm,comp.protocols.iso.x400,comp.protocols.misc,comp.protocols.nfs,comp.protocols.pcnet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Help Us Design Your Server


Summary: 
Keywords: 


Help Us Design Your Next Server
===============================

We are in the process of setting our design objectives for our
next generation servers.  If you would take a few minutes to
answer the questions below and e-mail the result to me it would
be very helpful to us.  We need to make many design trade-offs as
we go through the system design process, so having your thoughts
will make it easier for us to do the best for you.

Please do not post your reply, as I am posting this request in
many discussion groups that I do not subscribe to.  If you don't
e-mail your comments to me, I may not get them.

My e-mail address is:    gendreau@ppg01.sc.hp.com

Thanks for your help,

Jim Gendreau
Hewlett-Packard

Questions:
==========

1)   What is the major problem you have when you are trying to
     bring a new server on-line?


2)   What could a system vendor design into their system to make
     it easier and faster to install and configure a server with
     your primary operating system (or networking operating
     system)?


3)   How many servers do you set up each year?

     Where are these servers?

     _____  Within walking distance
     _____  Within driving distance
     _____  Significant travel needed to reach it 

4)   What is your current primary operating system (network
     operating system)?


     What will it be in a year?


5)   What subsystems and accessories do you usually install and
     configure initially?


     What problems do you have when you do this?


6)   Could you tell us a little about yourself?

     Name      ____________________________________
     Address   ____________________________________
               ____________________________________
     Phone     ____________________________________
     email     ____________________________________

     Type business  _______________________________
     Job function   _______________________________

     In the performance of your job, do you do any of the
     following? (please check all that apply)

     ___  Authorize/approve purchase of servers
     ___  Recommend/specify purchases of servers
     ___  No purchasing authority
     ___  Install and configure servers

7)   Can we contact you, if we would like to get more
     information?


Thank you for your help.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 94 09:56:54 +0000
From:      bogwey@ccvax.sinica.edu.tw (KEVIN. GWEY)
To:        comp.protocols.tcp-ip
Subject:   find X emulater in Pub-Domain



Could anyone tell me 
 Where to get the X emulater in public_domain ?

 * X emulater means that it can emulate a X-term from PC !

Thanks !

                           Kevin. Gwey   01/08/1994

 

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 12:55:46 +0000
From:      vadim@cix.compulink.co.uk (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Subject:   Re: Alternate IP & MAC Address


In-Reply-To: <2966996418.2.p00231@psilink.com> "Mark Lo Chiano" <p00231@psilink.com>

In article   : <2966996418.2.p00231@psilink.com>
"Mark Lo Chiano" <p00231@psilink.com>  writes:
> 
>         We have a need to create an application that must broadcast certain
> UPD messages using an IP address & MAC of several other machines.
> In this application the broadcasting machine acts as a proxy for the alternate
> machines.
> 
>         We are are QUITE aware that this is not a normal practice, but this
> is necessary.  So flame away....
> 
>         We have identified two alternate methods for that appear 
> fruitful, and would like comments on OTHER possible approaches.
> 
>         The first approach is to utilize two ethernet cards in the 
> broadcast machine.  The first ethernet card would operate normally and receive
> normal IP traffic.  The second card would only broadcast these special 
> messages, but would not receive any traffic.  Under this approach, we 
> would use fcntl() to reset the IP address of the second card prior to 
> the broadcast.  This is expected to cause significant overhead, 
> however, that is quite acceptable.  This approach would seem to have the
> potential to allow the IP address to be altered but not the MAC address.
> 
>         The second approach is to replace the current IP layer for the machine.
> Under this approach, we would essentially 'break' IP to relax the 
> bind() commands built in checks.  These normal (and proper) checks prevent 
> UPD socket binds that specify a local IP address from specifying an address
> other that the correct local IP as configured by ifconfig.  This approach
> would seem to allow both the IP and MAC accresses to be altered.
> 
>         All comments are welcome.....I realize that this is potentially a
> sensitive subject, so it may be appropriate to respond via Email.
> 
> 

Mark, isn't it possible to do a RAW open on the NIC device and send
it fully formed packets that will be put 'as is' to the LAN?

  Vadim.
-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
vadim@bix.com                      |   93126 La Courneuve - CEDEX, France



-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 16:46:41 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: UNIX TCP/IP packet sniffer?

In article <stamCJA9rC.A7I@netcom.com> stam@netcom.com (David Stam) writes:
>Does there exist a program which will display source and target IP 
>address #s and port #s for packets travelling across a specified network
>interface on a Unix machine (SunOs)?  Better yet, can the network drivers
>be configured to display this as debugging info?

tcpdump(8) available from ftp.ee.lbl.gov for BSD systems

Various vendors have vendor-specific mechanisms that could also be used,
consult your manual set.



-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 17:12:37 GMT
From:      Florian.Gutzwiller@open.ch (Florian Gutzwiller)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   SMTP <-> DISSOS/Memo

Can anybody comment on solutions that would make SMTP talk to IBM Dissos Mail  
and vice versa. I know high price solutions like HP OpenMail or EMX SoftSwitch  
can do that, but I'm rather looking for something really open and simple.

Thanks

-Florian

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Sat, 08 Jan 1994 17:43:05 GMT
From:      hwillett@dyna_soft.win.net (Herman Rouge Willett)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

 
In article <2ghllq$c59@golden.kaleida.com>, Sayeed Ahmed (sayeed@kaleida.com) writes:
>What does it take to implement voice over TCP/IP. How about the sampling
>rates that can be
>afforded in this scenario. What will be the least in no of bits that can
>be used, and what will
>be the speed (minimum) of an octet.
>Are there any problems associated with echo and do you require echo
>cancellation.
>Lastly what are the inherent problems associated with voice over
>TCP/IP?????
>
>any response enlightening us all on the net will be a great asset.
>
>sayeed.
>

================
Reply:

It is verry simple.  I emplimented something simular to what you are
talking about in '86 using a Kaypro2 as my sampling machine feeding into
a SLIP connection at 19.2 Kbaud.  I was able to to Telnet, FTP, and two
channels of voice sampled at 8Ksps over this link.  The users did not
know they were using digital voice sent over the SLIP link.

I used a technique known as Delta Modulation, with buffering.  I did the
DM digitally instead of using integration and differ... methods as described
in the tech litterature available on the subject.

No, this was only on 19.2, I don't have any experience over ethernet or such
using TCP/IP, but with NetBios, and IPX, it works great.

I have several other projects simular to this in the works right now, so can
not say to much without getting into trouble (you know what I mean), but just
to say that it works quiet well on well designed networks, or internetworks.

Good luck...



--
Herman R. Willett                       Internet hwillet@dyna_soft.win.com
Connectivity Specialist                 CIS ID: 75160,2005
Dynamic Software Solutions
5860 Picadilly Lane
Beaumont, Tx. 77708                     
(409) 899-2721 (Voice)
(409) 899-1709 (Data)
(409) 757-5276 (Pager)                  Use objects to manage network routes
****************************************************************************
*     DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER    *
*                                                                          *
*  The answers or advice given here in is for information purposes only.   *
* If you should choose, in your own mind, to use or impliment any of the   *
* suggestions contained herein, please do so at your own risk.             *
*==========================================================================*
*  This is a sad reflection on our society today, disclaimers and such, but*
* as I have been told, and so recently learned from a friends 

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 19:51:26 GMT
From:      fred@maccs.mcmaster.ca (Fred Whiteside)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or

In <1994Jan7.141112.4053@rhrk.uni-kl.de>, weber@rhrk.uni-kl.de writes:
>fred@maccs.mcmaster.ca (Fred Whiteside) writes:
>>	To the best of my knowlege, Novell's LWP does not support
>>packet drivers natively.  It is possible that some combination of the
>>various shims would get you there, although I can't think of one that
>>presents an ODI interface while talking to packet drivers.  
>
>Well, there is pdether, doing just that for ethernet. If my assumption, that
>the slip packet driver in question pretends to be ethernet towards the
>application, is correct, then this one should run.

	You are correct.  I always forget what PDETHER does, what
with it not saying ODI anywhere in the name :-)  Old age creeps up on
each of us differently ...

-fred
Fred Whiteside   Beame & Whiteside Software - PC Networking Software
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 94 20:19:37 GMT
From:      cml0464@ultb.isc.rit.edu (C.M. Leung)
To:        comp.protocols.tcp-ip
Subject:   Voice mail...

Hi to all network experts out there:

	Just want an update.  Is voice mail fully implemeted yet, WAN-wise?
What utilities are available on unix and pc platform if so?

Regards

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Sun, 09 Jan 1994 01:30:26 GMT
From:      hwillett@dyna_soft.win.net (Herman Rouge Willett)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice mail...  ( RE::Voice mail on network has been working for me for 8 years)

 
In article <1994Jan8.201937.302@ultb.isc.rit.edu>, C.M. Leung (cml0464@ultb.isc.rit.edu) writes:
>Hi to all network experts out there:
>
>       Just want an update.  Is voice mail fully implemeted yet, WAN-wise?
>What utilities are available on unix and pc platform if so?
>
>Regards
>

I have been using voice mail on networks for about 8 years, started with
a kaypro2.

So what is the hold up out there?

--
Herman R. Willett                       Internet hwillet@dyna_soft.win.com
Connectivity Specialist                 CIS ID: 75160,2005
Dynamic Software Solutions
5860 Picadilly Lane
Beaumont, Tx. 77708                     
(409) 899-2721 (Voice)
(409) 899-1709 (Data)
(409) 757-5276 (Pager)                  Use objects to manage network routes
****************************************************************************
*     DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER    *
*                                                                          *
*  The answers or advice given here in is for information purposes only.   *
* If you should choose, in your own mind, to use or impliment any of the   *
* suggestions contained herein, please do so at your own risk.             *
*==========================================================================*
*  This is a sad reflection on our society today, disclaimers and such, but*
* as I have been told, and so recently learned from a friends 

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 94 10:39:59
From:      drw@runge.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP market share

I was just reading in Network World's 1994 forecast issue (page 8, by
Maureen Molloy) the average protocol mix of their readers (large
corporations with enterprise-wide networks):

	Percentage of company data traffic by protocol type.

	Protocol	1993	1994

	TCP/IP		35%	38%
	Novell IPX	36	34
	SNA		16	14
	IBM APPN	 3	 4
	Other		10	10
	  (including OSI)

However, the article notes that "Novell currently commands six times
the commercial market as [sic] TCP/IP does".  What this means is that
in terms of packets-per-dollar, TCP/IP is six times more economical
than IPX!

This concept should be kept in mind when comparing the "market share"
of OSI vs. TCP/IP.  What is the market share in terms of packets, not
dollars?

In addition, the article notes that TCP/IP is rapidly becoming the
standard of choice for enterprise network integration, while OSI is
doing poorly in that role: "Forty-eight percent of users are moving to
TCP/IP as the standard protocol to support multivendor networks, while
just 6% have tapped the OSI prococol for that task."

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
When we eventually can build intelligent machines, what if the first
100 built are insane?

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 94 16:22:15
From:      sbchanin@ai.mit.edu (Steve Chanin)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Net Bandwith: X-Server vs PC Client/Server


I am trying to choose between two architectures for a project:

1) "Standard Client/Server"

  PC ----------------------- LAN or WAN ---------------- Relational DB
  (Powerbuilder)					(Sybase/Oracle)

2) "Application Server"

  PC ---- LAN or WAN ------ UNIX application server --- LAN --- Relational DB
  (running an X server)     (running the App in Motif)          (Sybase/Oracle)

THE QUESTION IS WHICH ARCHITECTURE HAS LOWER BANDWIDTH REQUIREMENTS TO THE
PC'S?

In the first architecture, the application is written on the PC.  All data
has to move from the DB across the LAN/WAN to the PC.  All display is handled
on the PC (TRAFFICE = DATA).  In the second architecture, the data stops
at the application server, only display information for X (Motif) needs to
move across to the PC (TRAFFIC = DISPLAY).

Does anyone have information on how these two architectures will compare with
respect to bandwidth requirements?

Please mail responses to sbchanin@ai.mit.edu.  I will summarize for anyone
who is interested in the results.

Thanks,
Steve

--
===============================================================================
DOMAIN: sbchanin@ai.mit.edu                                       Steven Chanin

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 1994 21:20:41 -0500
From:      birzniek@nova.umd.edu (Gunther Birznieks)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

I think your bigger issue other than network traffic is whether your XClient
can run multiple MOTIF applications (On the other of 20 or 50 or 100 at a
time) without a severe degredation in performance... THat is, XWIndows takes a
lot of processing power not only at the PC (XServer) But at the hardware
running the application (XClient).  So even if the bandwidths were similar,
you are probably going to spend a lot more money on making your XClient
hardware superfast and responsive.  

Also, it depends on your organization.  If everyone is PC Based with WIndows
capabable PCs with 8 megs of RAM itself, then it doesnt make much sense (If
the bandwidths are equal) to go with an XCLient way of doing things because
thats what PCs are for! ..One of the MAIN ideas of Client Server is that you
offload processing where it should be... IMHO, GUI Interfaces should be local
(Client Side) if you already have the hardware capable of doing it.

Anyway, I do not know how much network bandwidth XWindows really takes up
(You may want to post on the XWindows newsgroup also) but I am pretty sure
that it varies depending on the type and complexity of data sent.  Obviously
if your appllication is multimedia, you are going to have a lot of processing
time spent on the XCLient and XServer side taking care of the display of
animaition or rapid succession of pictures..Where if you had just
PowerBuilder, you would only have to waste processing power for that on the PC
side.

As a sidenote, also any decent XWIndows emulator for Windows costs a pretty
penny as well and take up plenty of resources and are not all that fast
relatively speaking.

Later,
  Gunther


-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Jan 1994 15:07:12 GMT
From:      eddieb@knoware.nl (Eddie Bindt)
To:        comp.protocols.tcp-ip
Subject:   NAMESERVER on MAC ???

Is there any NAMESERVER software capable to run on a not UNIX-Mac ??
For example, can MACTCP be used and how ?? 

-- 
Eddie Bindt
eddieb@knoware.nl

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Jan 1994 15:29:32 GMT
From:      niklas@LINK.Physchem.KTH.SE (Niklas Aagren Royal Inst. of Technology)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Mosaic: Unable to save or print

I run NCSA Mosaic 1.0 on Trumpet Winsock 1.0 alpha #17.

There's an annoying thing in my installation of Mosaic.
I can't print or save a file. The buttons and menu items for
these things are dimmed. Most other things work just fine, including
printer_setup.

/Niklas
___________________________________________________________________
Niklas Agren                       | Fourth law of thermodynamics: |
Dept. of Chemical Engineering      | If the probability of success |
Laboratory of energy technology    | is not very close to one,     |
Royal Institute of Technology      | it is damned near zero.       |
Stockholm -- Sweden                |                               |
niklas@heat.kth.se                 |                               |
___________________________________________________________________

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 1994 21:40:45 GMT
From:      whalenm@tis.telos.com (Matthew V. J. Whalen)
To:        comp.protocols.tcp-ip
Subject:   ftp mirror suggestions

I am looking for suggestions for software to mirror an ftp server.  I
suppose that I could always just tar the directory up and ftp that, etc.
but it would likely involve some human intervention and be a waste of
bandwidth.  Anybody have a suggestion on software to do this?  Thanks

--
-matthew                 ____         "Thanks mom...
whalenm@tis.telos.com    \  /         love the genes."
Voice:(703)802-1730       \/		
----------------------------------------------------------------
(My actions/words in no way reflect those of my employer.)

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 11:21:20 -0800
From:      rysavy@halcyon.com (Peter Rysavy)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP applications over CDPD


I am trying to figure out how well TCP/IP applications will 
function over wireless networks.

The Cellular Digital Packet Data (CDPD) network being deployed 
this year by the cellular carriers uses TCP/IP protocols.  The 
raw throughput over the RF channel is 19.2 kbps but you only 
get about 10 kpbs of real throughput due to forward error 
correction and other overhead.  Furthermore, this channel is 
shared by multiple users.  I guess you can think of it as a 10 
kbps network within a cell.  Finally, the connection is quite 
unreliable (despite forward error correction), though I don't 
know what kind of error rates can be expected.  It probably 
depends heavily on whether you are moving or not.

Latencies are supposed to be high.  I've heard that a second or 
two response time will be typical (e.g. time for a keyboard 
entry to be echoed on the screen.)

Connections to a host computer (on the back end) will usually 
be by a leased line running TCP/IP over something like frame 
relay.

Given such characteristics, I'm wondering what common TCP/IP 
applications will function well, and which will function 
poorly.

My guess is that applications that use transaction oriented 
protocols such as FTP, POP3 and SMTP will function reasonably 
well, but that interactive, session oriented applications like 
telnet will be painful.

Any thoughts or insights (or suggestions about other newgroups) 
would be appreciated.

Regards,

Peter Rysavy
rysavy@halcyon.com 
206-632-8093, 206-727-5020 fax


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 94 22:17:54 GMT
From:      kraehe@bakunin.north.de (Michael Kraehe)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Wanted: RFC931 Source

Moin folks,

	I'm searching for a C-Source for the Authentication-Server described
	in RFC931, it should run under any BSD compatible Unix without
	the need of kernel patches.

	Unfortunately there was no EMail-Adress of the author, so if
	anybody knows how to Mail to <St. Johns> it will be nice if
	Y mail his Email adress to me.

By Michael.
--
      ___________________
      | Michael Kraehe   |_________________________
      | 27321 Finkenburg | kraehe@bakunin.north.de |__________________
      | +49 4204 1497    | V32bis : +49 421 870532 | ceterum censeo  /
      |__________________| Voice  : +49 421 875500 |      MSDOS     /
                       (___________________________|  delendam esse \
                                                 (___________________\

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 1994 22:40:23 GMT
From:      rickert@cco.caltech.edu (Keith Warren Rickert)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

In <SBCHANIN.94Jan9162215@raisin-nut.ai.mit.edu> sbchanin@ai.mit.edu (Steve Chanin) writes:


>I am trying to choose between two architectures for a project:
>1) "Standard Client/Server"
>  PC ----------------------- LAN or WAN ---------------- Relational DB
>  (Powerbuilder)					(Sybase/Oracle)
 
>2) "Application Server"
>  PC ---- LAN or WAN ------ UNIX application server --- LAN --- Relational DB
>  (running an X server)     (running the App in Motif)          (Sybase/Oracle)
 
>THE QUESTION IS WHICH ARCHITECTURE HAS LOWER BANDWIDTH REQUIREMENTS TO THE
>PC'S?
 
>In the first architecture, the application is written on the PC.  All data
>has to move from the DB across the LAN/WAN to the PC.  All display is handled
>on the PC (TRAFFICE = DATA).  In the second architecture, the data stops
>at the application server, only display information for X (Motif) needs to
>move across to the PC (TRAFFIC = DISPLAY).
 
>Does anyone have information on how these two architectures will compare with
>respect to bandwidth requirements?

Unless your client does a _lot_ of its own processing, and thus needs
to move a lot of data with little change in the display,
the X client will almost certainly have higher bandwidth usage.
There are good reasons for using X11 (such as, in this case,
being able to use your application on a wider variety of platforms),
but lowering bandwidth isnt really one of them.

just MHO

Keith
-- 
Keith Rickert            | "That was only one of the many occasions on which
rickert@cco.caltech.edu  | I met my death - an experience I don't hesitate
keith@imppig.caltech.edu | strongly to recommend" - Baron von Munchchausen

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 13:48:21 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?

In article <1994Jan5.231908.4522@berlioz.nsc.com> my@laverde.nsc.com writes:
>
>Thanks for the answer.  But are we really doing too much checking?
>

   Just as a thought experiment, imagine that it is YOUR bank or tax
   account that is being sent over  the connection and see if you stil
   think there is "too much checking" going on in the protocol stack.



-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 08:55:18 -0500
From:      levtech@access2.digex.net (Leverage Technologists)
To:        comp.protocols.tcp-ip
Subject:   SLIP install problems

I am attempting to install slip 2.7 on a SPARC 10 running 4.1.3.

I am haveing some problems. Specifically, I followed the install
instructions and everything appeared to go smoothly. However, if if
use D38400 in my gettytab and ttytab, I get 
   /dev/cua0 : device busy

Additionally, if i turn off the /dev/ttyd0 getty, I still get modem 
problems. I think the problem lies in my /etc/gettytab entries and possibly
my /etc/remote.

I am including both and would REALLY appreciate any suggestions!

Thanks,
   Chuck Stump


#
# @(#)gettytab 1.11 92/06/23 SMI; from UCB 5.7 2/16/86
#
# Copyright (c) 1980 Regents of the University of California.
# All rights reserved.  The Berkeley software License Agreement
# specifies the terms and conditions for redistribution.
#
# Most of the table entries here are just copies of the
# old getty table, it is by no means certain, or even likely,
# then any of them are optimal for any purpose whatever.
# Nor is it likely that more than a couple are even correct
#

#
# The default gettytab entry, used to set defaults for all other
# entries, and in cases where getty is called with no table name
#
default:\
	:ap:lm=\r\n%h login\72 :sp#9600:

# This is a new entry to internationalize the console.  It needs to be
# 8 bit clean so that ISO 8859 characters can be displayed without
# the window system.
#
cons8:\
	:p8:lm=\r\n%h login\72 :sp#9600:


#
# Fixed speed entries
#
#	The "std.NNN" names are known to the special case
#	portselector code in getty, however they can
#	be assigned to any table desired.
#	The "NNN-baud" names are known to the special case
#	autobaud code in getty, and likewise can
#	be assigned to any table desired (hopefully the same speed).
#
a|std.110|110-baud:\
	:nd#1:cd#1:uc:sp#110:
 b|std.134|134.5-baud:\
	:ep:nd#1:cd#2:fd#1:td#1:sp#134:ht:nl:
 1|std.150|150-baud:\
	:ep:nd#1:cd#2:td#1:fd#1:sp#150:ht:nl:lm=\E\72\6\6\17login\72 :
 c|std.300|300-baud:\
	:nd#1:cd#1:sp#300:
 d|std.600|600-baud:\
	:nd#1:cd#1:sp#600:
 f|std.1200|1200-baud:\
	:fd#1:sp#1200:
 6|std.2400|2400-baud:\
	:sp#2400:ht:
 7|std.4800|4800-baud:\
	:sp#4800:ht:
 2|std.9600|9600-baud:\
	:sp#9600:
 g|std.19200|19200-baud:\
	:sp#19200:
 h|std.38400|38400-baud:\
	:sp#38400:p8:

#
# Dial in rotary tables, speed selection via 'break'
#
0|d300|Dial-300:\
	:nx=d1200:cd#2:sp#300:
 d1200|Dial-1200:\
	:nx=d150:fd#1:sp#1200:
 d150|Dial-150:\
	:nx=d110:lm@:tc=150-baud:
 d110|Dial-110:\
	:nx=d300:tc=300-baud:

#
# Odd special case terminals
#
-|tty33|asr33|Pity the poor user of this beast:\
	:tc=110-baud:

4|Console|Console Decwriter II:\
	:co:nd@:cd@:rw:tc=300-baud:

e|Console-1200|Console Decwriter III:\
	:fd@:nd@:cd@:rw:tc=1200-baud:

i|Interdata console:\
	:uc:sp#0:

l|lsi chess terminal:\
	:sp#300:

X|Xwindow|X window system:\
	:fd@:nd@:cd@:rw:sp#9600:

#
# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
#

# Added this entry as per the SLIP 2.7 install instructions
D38400|Fast-Dial-38400:\
	:nx=D38400:fc:fd@:tc=38400-baud:
 D2400|Fast-Dial-2400:\
	:nx=D1200:tc=2400-baud:
 3|D1200|Fast-Dial-1200:\
	:nx=D300:fd@:tc=1200-baud:
 5|D300|Fast-Dial-300:\
	:nx=D2400:tc=300-baud:

#
# Wierdo special case for fast crt's with hardcopy devices
#
8|T9600|CRT with hardcopy:\
	:nx=T300:tc=9600-baud:
 9|T300|CRT with hardcopy (300):\
	:nx=T9600:tc=300-baud:

#
# Plugboard, and misc other terminals
#
p|P9600|Plugboard-9600:\
	:nx=P300:tc=9600-baud:
 q|P300|Plugboard-300:\
	:nx=P1200:tc=300-baud:
 r|P1200|Plugboard-1200:\
	:nx=P9600:tc=1200-baud:

#
# XXXX Port selector
#
s|DSW|Port Selector:\
	:ps:sp#2400:

#
# Auto-baud speed detect entry for Micom 600.
# Special code in getty will switch this out
# to one of the NNN-baud entries.
#
A|Auto-baud:\
	:ab:sp#2400:f0#040:


/etc/remote entries

tip38400:\
	:el=^D^U^C^S^Q^O@:du:at=hayes:ie=#$%:oe=^D:br#38400:tc=dialers:
 dial-lager:\
	:pn=2129593:tc=tip38400:

lager|slip-lager:\
	:st=slip:ls=/etc/login.script.unix S%h :\
	:cc=/etc/sliplogin Slager:tc=dial-lager:

dialers:\
	:dv=/dev/cua0:

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 05:03:13 GMT
From:      eel@auspost.com.au (Elena Leong)
To:        comp.protocols.tcp-ip
Subject:   Buying a router

Hi 

We are about to buy a number of routers to set up a network, and getting 
horribly confused with the issues involved.

Does anyone have a good list of questions that we can present to ask the
3rd party vendor?

Can anyone illuminate on the good and bad bits of Welfleet, Cisco and Retix
routers - ie too difficult/easy to configure, flexible/inflexible, 
compatibility, etc.

We are running Sparc10s, SunOS4.1.3, TCP/IP, PPP, FTP, UUCP, RCMD, RLOGIN, etc

Please reply by mail if possible

Thanks in advance
Elena.
==========
Elena Leong
System Administrator
EDIPost Australia Post

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 09:27:59 GMT
From:      samkho@netcom.com (Samuel P Kho)
To:        comp.protocols.tcp-ip
Subject:   (C) status of RFC's

what is the copyright status of RFC's?  does ARPA own the rfc docs (if so, then
gov't. owns it and therefore PD?)?

thanx!

  - sam -



-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 23:26:17 -0800
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ethernet modem?

In article <2gse4s$p1m@gap.cco.caltech.edu>, dbikle@cco.caltech.edu
 (Daniel B. Bikle) wrote:
>Is there a product on the market which is a modem with an ethernet
>interface?
>
>Here's how I'd want it to work:
>
>I give the etherModem an IP address via a simple builtin keypad.
>
>I attach the etherModem to my ethernet.
>
>Then, I attach the etherModem to a phone jack via a phone cord.
>
>Then, I fly to Telluride and dial in to the etherModem which would
>allow me to telnet into any machine on the ethernet.

What you just described is common done with a terminal/SLIP/PPP server.

A couple of vendors which sells low port-density versions of such
servers are Telebit (800-TELEBIT) and Rockwell CMC (800-CMC-8023).

If you only want to service one phone line, the Telebit product
of interest is the Personal NetBlazer (PN1) and the Rockwell
product is NetHopper (NH-1).

The PN1 is a terminal/SLIP/PPP server which can deal with both
remote dumb terminals and IP-over-SLIP/PPP peers.  The NH-1 is
a PPP server and can only talk to remote IP-over-PPP peers.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"Packet Driver, WinSock & TCP/IP CD-ROM" product information:

{ftp,gopher,www}.CDPublishing.com or <info@CDPublishing.com>


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:17:02 -0500
From:      psicop@pipeline.com (Riley G)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

lmd@avila (Luis M. Delgado) wrote:

>: You may telnet to compuserve via hermes.merit.edu by 
>typing compuserve at the prompt.

I just tried it out and it worked for me. I'm 8,n,1 on the net 
and had no problems telnetin' to CIS!

The Thin Blue Line,
Riley G
Blue Knights NY VII LE MC    Harley Owner Group MC
Internet: Psicop@Pipeline.Com
TCP/IP:   psicop.pipeline.com         198.80.32.101














-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 12:04:27 +0000
From:      geoff@satro.demon.co.uk (Geoff Cox)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print

I have always had the same problem re greyed out buttons...

Anyone know why?


Geoff


-- 
Geoff Cox
London Docklands' SATRO
South London Science & Technology Centre
Wilson Road
London SE5 8PD

Tel +44 81 644 8046

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 12:06:42 GMT
From:      lmd@avila (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

mmoore@hpcc01.corp.hp.com (Mike Moore) writes:
: > Sorry if this is FAQ or in wrong group (which probably is the 
: > case :). Is it possible access CompuServe-network from Internet. 
: > And I don't mean mail, I want files. Can we use FTP (on what 
: > IP-address) ? What kind of uid's we'd use in this case (we have 
: > already some uid's to CompuServe, used with phone access) ?
: 
: You may telnet to compuserve via hermes.merit.edu by typing
: compuserve at the prompt.
: 
: I haven't heard of any FTP access yet... 
: 
: Mike
: 

Hello:

Did anybody succeded using The Compuserve Information Manager over Telnet to
CIS ?


I'm having many troubles. I believe, althought I'm not sure that hermes
limits communications to 7 bits, because I usied an Telnet 8-bit connection
to hermes, and I still can't get CIM to work with it.

Best Regards
--
Luis Delgado
e-mail: lmd@inesc.pt
----------------

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 12:16:46 GMT
From:      huth@stack.zfe.siemens.de (Hans-Peter Huth)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

Sayeed Ahmed (sayeed@kaleida.com) wrote:
> What does it take to implement voice over TCP/IP. How about the sampling
> rates that can be
> afforded in this scenario. What will be the least in no of bits that can
> be used, and what will
> be the speed (minimum) of an octet.
> Are there any problems associated with echo and do you require echo
> cancellation.
> Lastly what are the inherent problems associated with voice over
> TCP/IP?????
 
> any response enlightening us all on the net will be a great asset.
 
> sayeed.

one problem that may arise with tcp/ip is the end-to-end delay. In large
networks (i.e. global, met), using udp/ip is much faster because no 
acknowledges are necessary.
Good lock

|---------------------------------------------------------------|
|Hans-Peter Huth						|
|Siemens AG							|
|Corporate Research and Development, Dept. ZFE ST SN 25		|
|Otto-Hahn-Ring 6						|
|D-81730 Muenchen						|
|Tel: (089) 636 43 071		FAX: (089) 636 48 000		|
|E-mail: Hans-Peter.Huth@zfe.siemens.de				|
|---------------------------------------------------------------|

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 13:40:31 GMT
From:      mark@taylor.wyvern.com (Mark A. Davis)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

sbchanin@ai.mit.edu (Steve Chanin) writes:

>Does anyone have information on how these two architectures will compare with
>respect to bandwidth requirements?

Keep in mind that there is more to the system design than JUST the bandwidth...
The more you rely on the distributed systems, the more you will need to
spend on keeping them up and reliable too (IE backups, maintenance, 
installation, amount of resources, training, security issues).  This is
often very difficult with MS-"DOS"/MS-"Windows".

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 13:41:35 GMT
From:      griesser@zeus.uni-duisburg.de (Michael Griesser)
To:        comp.protocols.tcp-ip
Subject:   TCP fault handling

Hi all !

I am just inquiring the TCP/IP mechanisms for fault recognition.
TCP sockets do provide such mechanisms by itself, but the time until 
errors (e.g. connection break) are recognized is to long for my needs.

Is there any way to modify the used timeout values ? Is it possible
to access the acknowledging mechanisms if one is using stream sockets ?
If not, where can I find informations how to use raw sockets ?
I am using SunOS 4.1.3 resp. 5.2.

Any hints are welcome as well as literature recommendations. I already
had a closer look to the Stevens book (UNIX network programming) as well
as the Comer, but I couldn't find what I'm searching for.
 
Thanks in advance for your help. 


Ciao   Michael

--------------------------------------------------------------------
Michael Griesser, FB7 Fachgebiet Technische Informatik  Uni Duisburg
griesser@zeus.uni-duisburg.de   IRC: mowgli    M.GRIESSER@IUS.gun.de



-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 13:42:13 GMT
From:      mark@taylor.wyvern.com (Mark A. Davis)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

rickert@cco.caltech.edu (Keith Warren Rickert) writes:

>In <SBCHANIN.94Jan9162215@raisin-nut.ai.mit.edu> sbchanin@ai.mit.edu (Steve Chanin) writes:
 
>>Does anyone have information on how these two architectures will compare with
>>respect to bandwidth requirements?
 
>Unless your client does a _lot_ of its own processing, and thus needs
>to move a lot of data with little change in the display,
>the X client will almost certainly have higher bandwidth usage.
>There are good reasons for using X11 (such as, in this case,
>being able to use your application on a wider variety of platforms),
>but lowering bandwidth isnt really one of them.

It really depends on exactly what type of applications are being run and how
they are used.  The description is not that detailed.
-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 14:40:56 GMT
From:      adamson@itd.nrl.navy.mil (Brian Adamson)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Local Full Hostname?


> Use Arnt's code -- it's the best effort, and should work in all cases, ie.
> DNS-only, YP/DNS, YP-only, svc.conf-based, or /etc/hosts based
> configurations.
> --

  Arnt's code works fine ...except in the following case (which of
course applies to 
one of our local hosts (the host can be fixed though)).  It has an
entry in the etc/hosts
 file with it's short name but does not contain an alias with the full
name
(including domain) .... However I would probably judge this a poorly
configured machine ...
Unfortunately, people will sometimes try to run software on poorly
configured machines.
Looks like some calls to DNS are necessary sometimes.


> This space not left unintentionally unblank.          deraadt@fsa.ca


Thanks to everyone for their responses and to Arnt for his code
snippet,



Brian Adamson
Information Technology Division
Naval Research Laboratory

<adamson@itd.nrl.navy.mil>

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 94 14:50:24 GMT
From:      green@umdnj.edu (Cliff Green)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print

geoff@satro.demon.co.uk (Geoff Cox) writes:

>I have always had the same problem re greyed out buttons...
(re: not being able to save or print from WinMosaic)

>Anyone know why?
Because it's not in there yet.  I've been told it's not as easy as it seems
(though I'm not clear on the details).  Send mail to the Mosaic team at ncsa
for more info.

c
--
-- 
Clifford Green               Internet -  green@umdnj.edu
Academic Computing Services     voice -  908-235-5250
UMDNJ-RWJMS                       fax -  908-235-5252
If your wife wants to learn how to drive, don't stand in her way.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 15:11:22 GMT
From:      vwelch@ncsa.uiuc.edu (Von Welch)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print

In article <1994Jan9.152932.14110@kth.se>, niklas@LINK.Physchem.KTH.SE (Niklas Aagren Royal Inst. of Technology) writes:
|> I run NCSA Mosaic 1.0 on Trumpet Winsock 1.0 alpha #17.
|> 
|> There's an annoying thing in my installation of Mosaic.
|> I can't print or save a file. The buttons and menu items for
|> these things are dimmed. Most other things work just fine, including
|> printer_setup.

Since this has little to do with tcp/ip I would recommend mailing the mosaic
developers: mosaic@ncsa.uiuc.edu

-- 
Von Welch (vwelch@ncsa.uiuc.edu)	NCSA Networking Development Group

                "I'll be back in a minute." - Godot

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 15:19:41 GMT
From:      fracasso@julian.uwo.ca (John Fracasso)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print

In article <1994Jan9.152932.14110@kth.se> niklas@LINK.Physchem.KTH.SE (Niklas Aagren Royal Inst. of Technology) writes:

If you read through the documentation it will tell you that printing is not 
yet implemented on the this version.  If need to print using the Windows 
clipboard.

>I run NCSA Mosaic 1.0 on Trumpet Winsock 1.0 alpha #17.
 
>There's an annoying thing in my installation of Mosaic.
>I can't print or save a file. The buttons and menu items for
>these things are dimmed. Most other things work just fine, including
>printer_setup.



-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 15:50:34 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print

In article <758203467snz@satro.demon.co.uk> geoff@satro.demon.co.uk writes:
>I have always had the same problem re greyed out buttons...
>
>Anyone know why?
>

It's because NCSA Mosaic is a work in progress, and hasn't quite all been
written yet.  If you read the Windows Mosaic Home Page, it will tell you
that another release is slated to make its way out in mid January this year,
so if you're patient, maybe you'll find those features turning up soon!

Alun.
~~~~
-- 
The above is a personal opinion, and may not necessarily represent the
opinions of Welcom Software Technology, its management, its staff, or
its Margarita machine.
======================================================================

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 16:04:54 GMT
From:      bernhard@trick.ani.univie.ac.at (Bernhard Strassl)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

In article <SBCHANIN.94Jan9162215@raisin-nut.ai.mit.edu>, sbchanin@ai.mit.edu (Steve Chanin) writes:
|> 
|> I am trying to choose between two architectures for a project:
|> 
|> 1) "Standard Client/Server"
|> 
|>   PC ----------------------- LAN or WAN ---------------- Relational DB
|>   (Powerbuilder)					(Sybase/Oracle)
|> 
|> 2) "Application Server"
|> 
|>   PC ---- LAN or WAN ------ UNIX application server --- LAN --- Relational DB
|>   (running an X server)     (running the App in Motif)          (Sybase/Oracle)
|> 
[...]

I would suggest the following:

3) "UNIX Solution"

  PC ---------------------- LAN or WAN ---------------- Relational DB
  (running UNIX)                                       (Sybase/Oracle)

Then you are able to have the clients running on both sides with
less troubles. If you still need DOS - nearly ervery PC UNIX provides
a stable DOS emulatior. Most MS-Windows stuff should run pretty good
under SUN's WABI (I couldn't test this myself up to now, but I hope to
get it soon).

My expierience is that client/server solutions make less problems over
the time (because of changing OS, DB and GUI product releases) if both
parts run under UNIX.

-bernhard

---------------------------------------------------------------
The Xm++ / CommonInteract Project
Vienna User Interface Group
Bernhard Strassl              University of Vienna
xmplus@ani.univie.ac.at       Dpt. for Applied Computer Science
                              and Information Systems
---------------------------------------------------------------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 18:28:29 GMT
From:      wellseh@agedwards.com (Edward Wells)
To:        comp.protocols.tcp-ip
Subject:   UDP File Transfer

We have a requirement to send files of approximatly 100Kbytes - 13Mbytes to
multiple locations.  The number of locations is estimated between 500-600.
We beleive a UDP file transfer program would be what we need.  Does anyone
know if such a beast exists?  Or, is there an alternate method to send these
files to these locations?

Thanks in advance,


Ed.


-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 19:41:31 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   TCP Backoff/Retransmit limits

I have two questions regarding TCP backoff and retransmit limits.  In
TCP/IP Illustrated [Stevens] the example shows a total of 12 retransmit
attempts backing off to a limit of 64 seconds.

I am working with some code which appears to do 14 attempts and backs
off to a limit set by the exponent (as opposed to absolute time).

Is the example in the book fairly standard, or do these values/methods
vary widely?  Should the upper retransmit be limited by a fixed time
period? (I see the RFC had 1 minute listed, however it appeared to be
only a 'for example' value (that's how I read it at least)).

- Steve
- lawson@netcom.com



-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:51:46 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJEy3y.2Ln@ztivax.zfe.siemens.de> huth@stack.zfe.siemens.de (Hans-Peter Huth) writes:
>one problem that may arise with tcp/ip is the end-to-end delay. In large
>networks (i.e. global, met), using udp/ip is much faster because no 
>acknowledges are necessary.

Acknowledgements don't affect end-to-end delay.  The receiving system can
use the data as soon as it's received, so the acknowledgement time doesn't
slow things down.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:55:58 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer

>We have a requirement to send files of approximatly 100Kbytes - 13Mbytes to
>multiple locations.  The number of locations is estimated between 500-600.
>We beleive a UDP file transfer program would be what we need.

	Is it possible to have them pull, instead of you pushing?
I.e.: have 500-600 locations pulling files from one server? That's
a lot easier to implement, be it using FSP, FTP, or whatever.

	That, or use NNTP and INN.   [no smiley]

mjr.

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:58:51 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling

In article <2grluf$o5p@unidui.uni-duisburg.de> griesser@zeus.uni-duisburg.de writes:
>I am just inquiring the TCP/IP mechanisms for fault recognition.
>TCP sockets do provide such mechanisms by itself, but the time until 
>errors (e.g. connection break) are recognized is to long for my needs.

The long timeouts in TCP/IP's fault recognition mechanisms are there for a
reason: they should not be tripped by temporary network problems (such as a
dial-on-demand SLIP line hanging up, a network administrator unplugging
devices in order to isolate a fault, or route flapping when a router has
gone down and the alternate route hasn't propagated thoroughly).  They are
eventually reflected to applications so that resources aren't reserved
indefinitely, but they should not be relied upon if you need real-time
checks.

If you need to check on the health of a peer in real time, put this in the
application protocol.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 20:19:04 GMT
From:      billp@ncd.com (Bill Prescott)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

In article <SBCHANIN.94Jan9162215@raisin-nut.ai.mit.edu>, sbchanin@ai.mit.edu (Steve Chanin) writes:

|> 1) "Standard Client/Server"
|> 
|>   PC ----------------------- LAN or WAN ---------------- Relational DB
|>   (Powerbuilder)					(Sybase/Oracle)
|> 
|> 2) "Application Server"
|> 
|>   PC ---- LAN or WAN ------ UNIX application server --- LAN --- Relational DB
|>   (running an X server)     (running the App in Motif)          (Sybase/Oracle)
|> 
|> THE QUESTION IS WHICH ARCHITECTURE HAS LOWER BANDWIDTH REQUIREMENTS TO THE
|> PC'S?


THE ANSWER IS: IT DEPENDS.

BUT EITHER WAY, THE SECOND ARCHITECTURE IS BETTER.

The second architecture will probably have "lower bandwidth requirements to the PC's."  X traffic is
generally smaller than data traffic.  But anyone giving a concrete answer to this question is on shaky
ground, for two reasons.

	1. You didn't specify enough details
	   (what app? # users? size/type of data? volume of graphics? are you backing up the PCs? ...)

	2. It's dynamic; a right answer today may be wrong tomorrow.

That's one reason the second architecture is better.  It is modular.  It allows you to optimize the
network and the application on one side INDEPENDENT of the network and the application on the other,
instead of optimizing for both at the same time.

Here are 10 reasons why the second architecture is better:

I.	The open systems design of the second approach gives you a choice of application servers.
		If your client application only runs on PC's, you become captive to Microsoft.
		The application server model lets you use UNIX, NT, VMS, and so on, or any combination.
		They can all send X display info to the desktop.

II.	The application server model gives you a choice of desktops, rather than forcing you to use PCs.
		PC's can be too expensive to own and administer in large organizations.
		X allows you to use whatever's best for you: PC's, workstations,
		or an optimized, low-cost solution: X terminals.

III.	Clean-layering with a modular design is easier to implement.
		Developing a client/server app is hard enough without bundling the UI requirements
		with it.

IV.	Clean-layering with a modular design positions you well for the future.
		WHOOPS! You need to add another application.  Do the PC's have the horsepower for both?
		With the application server model, ADD another server rather than replace every desktop.

V.	Putting applications on the desktop limits performance.
		No matter how fast a device you put on the desktop, you're limited to that much speed.
		As applications and OS's grow, your device slows down, eventually forcing you
		to replace it.  But with an app. server model, you can configure MUCH faster
		CPU's centrally, and add servers when you need them. It is more scalable.

VI.	Applications on the desktop waste CPU cycles and memory.
		Desktop computers are not shared resources.  They must include enough power
		and memory to run the application--on every desktop.  Not all of the computers
		are in use by all of the users all of the time.  There's a lot of waste.
		In order to beat the performance limits (V.), people sometimes over-configure the
		desktop device, trying to extend its life, wasting even more resources.

VII.	Putting applications on the desktop causes frequent desktop hardware upgrades.
		Anyone running a SPARCstation 1?  A 286 PC?  Running applications demands
		ever increasing horsepower.  The user interface is stable, and does NOT demand
		increasing horsepower.  Therefore, running only the user interface on the desktop--
		with apps on a centralized server--greatly prolongs the life of the desktop device.

VIII.	Putting data on the desktop has more security risks.
		Any desktop computer that allows local I/O puts you at risk of unauthorized removal
		of sensitive data, or of unwitting introduction of viruses.  X terminals eliminate
		this risk altogether, but even PC's running X allow you to develop apps such that
		the sensitive data is controlled and more secure.

IX.	Data on the desktop doesn't get backed up.
		If backing up desktop computers isn't a problem for you, congratulations. It is
		for most everyone else who uses them.

X.	Putting applications on the desktop costs more to administer.
		Running applications on the desktop means running desktop computers. In and of itself,
		that makes the architecture more expensive.  But the administrative costs of putting
		applications, with incumbent upgrades, troubleshooting, etc. on every desk is very
		high as several prominent studies attest.


-- Bill

__________________________________________________________________

Bill Prescott			Market Development Program Manager
bp@ncd.com, 415/691-7401	NCD, #1 in X terminals and PC-X software

	If you write software based on the X Window System, 
		please tell me about your product!

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:22:54 GMT
From:      mark@taylor.wyvern.com (Mark A. Davis)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

bernhard@trick.ani.univie.ac.at (Bernhard Strassl) writes:

>In article <SBCHANIN.94Jan9162215@raisin-nut.ai.mit.edu>, sbchanin@ai.mit.edu (Steve Chanin) writes:
>|> 
>|> I am trying to choose between two architectures for a project:
>|> 
>|> 1) "Standard Client/Server"
>|> 
>|>   PC ----------------------- LAN or WAN ---------------- Relational DB
>|>   (Powerbuilder)					(Sybase/Oracle)
>|> 
>|> 2) "Application Server"
>|> 
>|>   PC ---- LAN or WAN ------ UNIX application server --- LAN --- Relational DB
>|>   (running an X server)     (running the App in Motif)          (Sybase/Oracle)
>|> 
>[...]
 
>I would suggest the following:
 
>3) "UNIX Solution"
 
>  PC ---------------------- LAN or WAN ---------------- Relational DB
>  (running UNIX)                                       (Sybase/Oracle)
 
>Then you are able to have the clients running on both sides with
>less troubles. If you still need DOS - nearly ervery PC UNIX provides
>a stable DOS emulatior. Most MS-Windows stuff should run pretty good
>under SUN's WABI (I couldn't test this myself up to now, but I hope to
>get it soon).
 
>My expierience is that client/server solutions make less problems over
>the time (because of changing OS, DB and GUI product releases) if both
>parts run under UNIX.

I will second that...., out of the three options now given.  Even Linux is
an option now.
-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:25:37 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router

In article <1994Jan10.050313.391@auspost.com.au> eel@auspost.com.au (Elena Leong) writes:
>Hi 
>
>We are about to buy a number of routers to set up a network, and getting 
>horribly confused with the issues involved.
>
>Does anyone have a good list of questions that we can present to ask the
>3rd party vendor?

I'm not sure how "good" these are, but here are some basic questions
that I ask myself first:

Which interior routing protocol will one be using ?  (OSPF is a good answer)
Which exterior routing protocol will one be using ?  (BGPv3 is a good answer)
Will one be using IP Multicast now or in the near future ? (answers will vary)
Will one be using SNMP/SNMPv2 for network management ? (probably yes, to both)
Which subnet technologies (e.g. Ethernet, FDDI, Token-Ring, DS1, DS3, ATM)
	will one be using ?
What kind of access controls/filtering does one need (e.g. filter out 
	traffic to/from certain TCP ports or UDP ports, filter out certain 
	addresses, only allow certain addresses) ?

Once you answer these questions for yourself, then ask vendors if they
support the answers you have chosen for your installation.

>Can anyone illuminate on the good and bad bits of Wellfleet, Cisco and Retix
>routers - ie too difficult/easy to configure, flexible/inflexible, 
>compatibility, etc.

  Cisco, Proteon, and Wellfleet are the big 3 vendors.  Retix is
probably in 4th place.  WellFleet reportedly has a fairly hostile
console interface (the router operator must really have SNMP commands
memorised).  I wouldn't let Cisco talk me into using IGRP (their
proprietary routing protocol) because it limits my future hardware
choices.  Choosing BGP3 and OSPF as one's routing protocols is a safe
choice for now and shouldn't limit one's ability to pick different
router vendors in the future.

>We are running Sparc10s, SunOS4.1.3, TCP/IP, PPP, FTP, UUCP, RCMD, RLOGIN, etc

  If using PPP, then you definitely want to make sure that your
routers will support PPP.  Otherwise you look like a "normal" user.

DISCLAIMER: I'm speaking only for myself here, not for other folks.
I don't have any financial interest in any router vendor, though I
do know several of the implementers at various firms from IETF meetings.

Ran
atkinson@itd.nrl.navy.mil

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:27:14 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: (C) status of RFC's

In article <samkhoCJEqAn.Fou@netcom.com> samkho@netcom.com (Samuel P Kho) writes:
>what is the copyright status of RFC's?  
>does ARPA own the rfc docs (if so, then gov't. owns it and therefore PD?)?
>
>thanx!
>
>  - sam -

A better question might be whether RFCs are freely distributable.
The answer to that question is YES they are freely distributable.

Ran
atkinson@itd.nrl.navy.mil



-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:33:35 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJEy3y.2Ln@ztivax.zfe.siemens.de> huth@stack.zfe.siemens.de (Hans-Peter Huth) writes:
>Sayeed Ahmed (sayeed@kaleida.com) wrote:
>> What does it take to implement voice over TCP/IP ?? 

Not a lot.  A good low data rate voice algorithm helps (see the public
literature for one).  Using UDP/IP instead of TCP/IP helps.  It isn't
really hard to build the tools once one figures out the algorithms
to use and such like.
 
>> How about the sampling rates that can be afforded in this scenario.  
>> What will be the least in no of bits that can be used, 
>> and what will be the speed (minimum) of an octet ??

Depends on your voice algorithm, not the network itself so much.

>> Are there any problems associated with echo and do you require echo
>> cancellation ??

Not really.
At least not if one uses UDP/IP as is conventionally done right now.

>> Lastly what are the inherent problems associated with voice over
>> TCP/IP?????

On loaded networks, one wants to have resource reservation (perhaps
something like RSVP) so that voice,video,white board traffic gets
the bandwidth it needs.

>> any response enlightening us all on the net will be a great asset.

Voice, video, and whiteboard tools are currently in use worldwide over
the Multicast Backbone (aka MBONE).  Some tools that are freely
distributable include nevot and vat for voice, ivs and nv for video,
and wb for whiteboard.  There are several commercial software packages
that do this from vendors such as InSoft and SunSoft.

Ran
atkinson@itd.nrl.navy.mil

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 20:34:36 GMT
From:      dbikle@cco.caltech.edu (Daniel B. Bikle)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   ethernet modem?

Hi There,

Is there a product on the market which is a modem with an ethernet
interface?

Here's how I'd want it to work:

I give the etherModem an IP address via a simple builtin keypad.

I attach the etherModem to my ethernet.

Then, I attach the etherModem to a phone jack via a phone cord.

Then, I fly to Telluride and dial in to the etherModem which would
allow me to telnet into any machine on the ethernet.

Please let me know if you are aware of such a product.

-Dan
-----------------------------
Daniel B. Bikle
Independent Oracle Consultant
dbikle@alumni.caltech.edu
415/854-9542
P.O. BOX 'D'
MENLO PARK CA 94026
-----------------------------

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 22:00:40 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits

In article <lawsonCJFIp9.C77@netcom.com>,
Steven Lawson <lawson@netcom.com> wrote:
>I am working with some code which appears to do 14 attempts and backs
>off to a limit set by the exponent (as opposed to absolute time).

It's implementation-dependent.  The number of backoffs depends on the
implementation and on the initial retransmission timeout.

As I implemented backoff in my TCP, it starts at the computed
(Jacobson-style) retransmission timeout, then backs off exponentially
until it hits 240 seconds, which is what I interpreted RFC 1122 as
recommending for the limit.  The number of transmissions before it hits
the 240 s limit depends on the initial timeout length.

Although the recommended algorithms are now fairly clear, most of the
TCPs out there predate them.  Few implement exactly what is now
recommended.  My guess is that there are three causes: (1) the author
are/were unaware of the recommended algorithms, (2) one author
interpreted the algorithm desription in a way different from other
authors, or (3) the author had a "better" algorithm.

>Should the upper retransmit be limited by a fixed time period? (I see
>the RFC had 1 minute listed, however it appeared to be
>only a 'for example' value (that's how I read it at least)).

Which RFC?  (Just wondering... It gets hard to keep track of which one
says which.)

It makes sense to limit it to a fixed period.  Think about it in the
worst case -- the IP header has a field that limits the lifetime of a
packet in real time.  That means that if one sends a packet and gets no
response within two of those maximum lifetimes, it's safe to assume the
packet did not arrive.  There is no point in waiting longer, since no
possible packet could take longer than that without being discarded.

       Stephen

-- 
Stephen Trier  KB8PWA       "Is this what Andy Warhol meant by '15 minutes
Other: trier@ins.cwru.edu    of fame?'"  - lisbon@vpnet.chi.il.us
Home: sct@po.cwru.edu       "As this is alt, that should probably be '15 Mb
                             of flame.'"  - arthur@Smallworld.co.uk

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 22:31:04 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer

In article <2gsbse$8mn@sol.tis.com> mjr@tis.com (Marcus J. Ranum) writes:
>>We have a requirement to send files of approximatly 100Kbytes - 13Mbytes to
>>multiple locations.  The number of locations is estimated between 500-600.
>>We beleive a UDP file transfer program would be what we need.
>
>	Is it possible to have them pull, instead of you pushing?
>I.e.: have 500-600 locations pulling files from one server? That's
>a lot easier to implement, be it using FSP, FTP, or whatever.
>
>	That, or use NNTP and INN.   [no smiley]

Using the netnews flooding algorithm seems like a very neat kludge for
what otherwise sounds like a classic reliable-multicast application.  600
copies of a 13MB file is about 8GB.  If the files must be copied frequently
enough, it might be kind of hard to implement with a single source.  On
the other hand, a 13MB file or two would hardly be noticed by netnews
systems today.  (Of course, with only a little hacking, you wouldn't need
to worry about whether files are binary.)

Just now there is a lot of research work into reliable reliable
multicasting ("anycasting," whatever).  It seems most issues of the
journals have an article or two, which might be a start to get some
pointers to the overall literature, if the original questioner wants to
do research instead get something running immediately.


Vernon Schryver    vjs@rhyolite.com

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 94 22:40:28 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <2gsbkiINNhm0@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> In article <CJEy3y.2Ln@ztivax.zfe.siemens.de> huth@stack.zfe.siemens.de (Hans-Peter Huth) writes:
|> >one problem that may arise with tcp/ip is the end-to-end delay. In large
|> >networks (i.e. global, met), using udp/ip is much faster because no 
|> >acknowledges are necessary.
|> 
|> Acknowledgements don't affect end-to-end delay.  The receiving system can
|> use the data as soon as it's received, so the acknowledgement time doesn't
|> slow things down.
|> -- 
|> Barry Margolin
|> System Manager, Thinking Machines Corp.
|> 
|> barmar@think.com          {uunet,harvard}!think!barmar

As far as I know, the only issue with any isochronous application over TCP/IP is
whether you can guarantee delivery time and bandwidth:  neither of those two
functions are part of IP or TCP.  They are a function of the media.  If the media
does provide an isochronous service, current versions of IP and TCP are unable to
access it.  So, you've probably seen people do video over TCP/IP and if you have
a dedicated media, no problem.  If you have a shared media, it can still be no
problem for the most part:  just as long as no one on the wire is faster and
greedier than you.

If TCP/IP is reworked so that it can do inter-layer communication like the OSI
stack is supposed to be able to do, TCP or UDP could request a certain class of
service from the media which, if capable, could supply a guaranteed bandwidth
path between the end points.  I agree that the acknowledgments are a non-issue: 
I just make my buffers big enough to ensure that I don't stop sending due to
window closure on either side.  One might still, however, go to UDP anyway cuz in
a realtime application like this, if I missed the data the first time, I might
not care about it by the time it is retransmitted.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 94 09:32:00 -0640
From:      john.will@satalink.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over

B >Acknowledgements don't affect end-to-end delay.  The receiving system can
B >use the data as soon as it's received, so the acknowledgement time doesn't
B >slow things down.

That would certainly depend on the window size wouldn't it?  If the 
acknowledgment takes too long to return, the data flow will cease 
at the source.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 22:52:03 GMT
From:      rturner@aqm.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over 802.3/802.2


Does anyone on the group know where I might find the "standard" way to encode
and decode link-layer 802.3 information for IP packets?

I'm aware that the majority of the world uses Enet V2 formatted packets, but I
have recently been asked to provide TCP/IP support over 802.3 (with 802.2
SNAP IDs as well).  Is/Are there RFC information relating to this?

Thanks!

Randy


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 23:01:35 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router

Ran Atkinson (atkinson@itd.nrl.navy.mil) wrote:
: I'm not sure how "good" these are, but here are some basic questions
: that I ask myself first:

[An excellent list of functional questions deleted]

To that list I would add performance questions - how fast does Box X
forward/filter packets - across a range of sizes - *including* sizes
that would require IP fragmentation (FDDI to Ethernet, TokenRing to
Ethernet, One MTU to another). A good place to start might be the
"Bradner Tests." I can never remember the nodename -
hsdndev.harvard.edu? 

but then again, I'm a performance person,

rick jones

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 23:31:58 GMT
From:      heathh@cco.caltech.edu (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

barmar@think.com (Barry Margolin) writes:

>huth@stack.zfe.siemens.de (Hans-Peter Huth) writes:
>>one problem that may arise with tcp/ip is the end-to-end delay. In large
>>networks (i.e. global, met), using udp/ip is much faster because no 
>>acknowledges are necessary.
 
>Acknowledgements don't affect end-to-end delay.  The receiving system can
>use the data as soon as it's received, so the acknowledgement time doesn't
>slow things down.

Actually, waiting for ACKs slows the sender down.  So, there would be 
interruptions in our hypothetical sound stream being sent.

FWIW, I have heard that using UDP packets of 3 ms intervals of samples
works best.  The 3ms figure comes from something the phone company did
to research peoples' abilities to notice misordered or dropped snippets
of conversation.

Good luck,
Heath

-- 
--
From the Home for Amnesiac Computer Scientists....
  heathh@cco.caltech.edu


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 23:53:46 GMT
From:      droelke@aud.alcatel.com (Daniel R. Oelke)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer

>We have a requirement to send files of approximatly 100Kbytes - 13Mbytes to
>multiple locations.  The number of locations is estimated between 500-600.
>We beleive a UDP file transfer program would be what we need.

Are all the nodes - well, I hope not 500-600, but maybe a great number
of them, all connected on a single broadcast medium such as ethernet?
If so, then a broadcast method would be ideal.  If not I would suggest
tftp, or FSP.  Both can be used in a server or client initiated method.
You just have to make sure that if the 600 clients are 
dumb and waiting for a download, that they have the "FSP server" or
"T-FTP server" software running.

With more detail to your situation, people can help you better.

Dan

---
------------------------------------------------------------------------------
Dan Oelke                                              Alcatel Network Systems
droelke@aud.alcatel.com                                         Richardson, TX
Phone: (214) 996-5013                                #include <std-disclaim.h>
  Fax: (214) 996-7119
------------------------------------------------------------------------------



-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 03:25:37 GMT
From:      mspace@netcom.com (Brian Hall)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ethernet modem?

dbikle@cco.caltech.edu (Daniel B. Bikle) writes:

>Hi There,
 
>Is there a product on the market which is a modem with an ethernet
>interface?

I'm not sure if it works the way you want, but the Shiva NetModem/E has
an Ethernet connection, and is made to be shared by Macs/PCs on a LAN.

-- 
__________________________________________________________________________
Brian Hall                                     Internet: mspace@netcom.com
Mark/Space Softworks                             AppleLink, AOL: MARKSPACE
Macintosh connectivity software.   info via anon ftp netcom.com:pub/mspace

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 03:39:18 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router

In article <CJFryn.Fo2@cup.hp.com>, Rick Jones <raj@cup.hp.com> wrote:
>Ran Atkinson (atkinson@itd.nrl.navy.mil) wrote:
>: I'm not sure how "good" these are, but here are some basic questions
>: that I ask myself first:
>
>[An excellent list of functional questions deleted]
>
>To that list I would add performance questions - how fast does Box X
>forward/filter packets - across a range of sizes - *including* sizes
>that would require IP fragmentation (FDDI to Ethernet, TokenRing to
>Ethernet, One MTU to another). [...]

...and I'd add the following, which is important to me (but not 
necessarily to anyone else :-) ):

What happens to forwarding loss/delay characteristics when the router
a) sends/receives a routing protocol update?
b) updates its forwarding table?

I've seen periodic delay/loss in a couple different networks which 
coincides beautifully with routing protocol update frequency.

Steve


-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 04:10:19 GMT
From:      mark@taylor.wyvern.com (Mark A. Davis)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

billp@ncd.com (Bill Prescott) writes:

>The second architecture will probably have "lower bandwidth requirements to the PC's."  X traffic is
>generally smaller than data traffic.  But anyone giving a concrete answer to this question is on shaky
>ground, for two reasons.
 
>	1. You didn't specify enough details
>	   (what app? # users? size/type of data? volume of graphics? are you backing up the PCs? ...)
 
>	2. It's dynamic; a right answer today may be wrong tomorrow.
 
>That's one reason the second architecture is better.  It is modular.  It allows you to optimize the
>network and the application on one side INDEPENDENT of the network and the application on the other,
>instead of optimizing for both at the same time.
 
>Here are 10 reasons why the second architecture is better:

[whole lot deleted]

****EXTREMELY**** Well said.  I am saving that posting for future reference.
But, please post in 80 columns! It is a whole lot easier to read :)

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 04:24:02 GMT
From:      rer3@quads.uchicago.edu (Rich Robbins)
To:        comp.os.os2.networking,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   TCP/IP for OS/2 2.0 Bug in FTPd?

While using Fetch on my macintosh to access files on a PC Clone
running OS/2 2.1 and the FTP server included in IBM's TCP/IP 2.0 for
OS/2, I noticed that subdirectories are not displayed in the Fetch
window with other files.  I can however access all of the files and
directories on the OS/2 machine.  In addition, the Fetch view file
list command does list all subdirectories of the current directory.
After noticing these things I switched to NCSA Telnet and started an
FTP session.  It seems that the OS/2 TCP/IP implementation of "ls"
results in a file list without subdirectories and the implementation
of "dir" results in a file list including subdirectories.  What is the
"correct" behavior for an implementation of an FTP server?  Can I
alter the behavior of the IBM program?  Is this an ambiguity in a
specification, a bug in the IBM software or a shortcoming of Fetch?

Thanks in advance for your assistance.

-- Rich Robbins



-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 15:40:18 -0500
From:      miranf@bu.edu (Miran Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Request for SLIP info or FAQ.

Hi there!

I am just starting to learn about SLIP.  Are there any FAQs out there on 
SLIP?How about any additional info (already have the RFC)?  Does anyone know 
if there might be a SLIP NLM for NetWare?  What do I need to set up a SLIP 
server?  How about on the client end?

Thanks in advance!



  _,_/|
  \o.O;   Miran Fernandez
 =(___)=  Networking Consultant
    U     Boston University
          miranf@socrates.bu.edu

"It takes less time to do a thing right than to explain why you
did it wrong." - Henry Wadsworth Longfellow


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 09:04:43 GMT
From:      schwartz@cs.colorado.edu (Michael Schwartz)
To:        comp.protocols.tcp-ip,comp.infosystems.announce
Subject:   Netfind now interoperates with X.500, WHOIS, and PH

There is a new version (4.0) of Netfind available by anonymous FTP from
ftp.cs.colorado.edu, in pub/cs/distribs/netfind.  This version lets
remote sites customize how Netfind searches for users there, by
registering a set of white pages service Uniform Resource Locators in
their DNS servers.  Based on this mechanism, Netfind can now
interoperate with X.500, WHOIS, and PH, and can also allow sites to tune
which hosts Netfind uses for SMTP or Finger, or restrict Netfind from
searching their site entirely.  For more information on how to set up
these URLs in your DNS server, retrieve the file
pub/cs/distribs/netfind/Netfind.WP.URLs from ftp.cs.colorado.edu.

There is a new paper that describes the above mechanism, focusing
particularly on Netfind's data gathering framework and algorithms.  It
is available by anonymous FTP from ftp.cs.colorado.edu, in
pub/cs/techreports/schwartz/PostScript/Netfind.Gathering.ps.Z or
pub/cs/techreports/schwartz/ASCII/Netfind.Gathering.txt.Z.
 - Mike

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 09:56:39 GMT
From:      lmd@avila (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

psicop@pipeline.com (Riley G) writes:
: lmd@avila (Luis M. Delgado) wrote:
: 
: >: You may telnet to compuserve via hermes.merit.edu by 
: >typing compuserve at the prompt.
: 

Well, I didn't wrote that, but I asked if someone had succeded using CIM
over telnet to hermes.merit.edu...

: I just tried it out and it worked for me. I'm 8,n,1 on the net 
: and had no problems telnetin' to CIS!

Could you be more specific ? What is your configuration, to access CompuServe
using CIM over telnet ?

I'm using Windows CIM 1.0.6 version. I dial via the serial port to our local
netblazer, and then establish a telnet 8-bit connection to hermes.merit.edu,
then when I get the login prompt from CIS, I switch WinCIM from terminal
emulator to the GUI interface, and press GO ! Everithing goes ok, until it
hangs when trying to establish a protocol.

Can't use Xmodem either for other file transfers. Too many retries !

: 
: The Thin Blue Line,
: Riley G
: Blue Knights NY VII LE MC    Harley Owner Group MC
: Internet: Psicop@Pipeline.Com
: TCP/IP:   psicop.pipeline.com         198.80.32.101
: 


Best Regards
-
Luis Delgado
INESC-CCAE, Lisbon
e-mail: lmd@inesc.pt
----------------

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 16:12:29
From:      john_bourke@inmarsat.org (John Bourke)
To:        comp.protocols.tcp-ip
Subject:   Looking for secure FTP servers

Howdy,

Are there any secure FTP servers available that will only allow users's to see 
their home directories, and leave good audit trails.

Are there any security enhanced versions of standard IP application protocols.

I'm looking for these for SCO, or source code.

thanks


john


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 94 12:17:12 GMT
From:      lars@Eskimo.CPH.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about the costs of using TCP

In article <1994Jan6.061620.24519@cm.cf.ac.uk>
   Mick.K.McPadden@cm.cf.ac.uk (mick) writes:
Mick> 1. I've read somewhere that setting up a TCP connection requires three
Mick> messages' to be passed between two communicating partners, with a
Mick> further three being required to tear down the connection, is this true,
Mick> is it more, or less ?

Minimum to get set up:
	SYN->
	<-SYN, ACK
	ACK->
If you don't worry too much, you can piggyback data on the SYN's,
so you might say there's NO setup overhead.

Minimum to tear down: one RST !!
Minimum for graceful shutdown:
	FIN->
	<-ACK, FIN
	ACK->

Mick> 2. If a connection has been set up, but no data has been sent through
Mick> it for say 20 minutes, has there been been any TCP activity on the LAN
Mick> in the meantime in order to keep that connection alive, or will network
Mick> activity commence only when data are explicitly passed through the
Mick> connection. In otherwords is there a hidden  overhead associated with
Mick> idle connections.

It depends. TCP does not require overhead traffic on an idle link.
Many applications LIKE to probe an idle link, so they can clean up if it
goes away. Most TCP implementations allow for such "keep-alive"s to be
automatically generated at a user-settable interval. Some people have
that interval defaulted to a rather low value like two minutes.

Mick> 3. Do TCP implementations tend to have an upper limit on the number of
Mick> connections that they might have open at any one time, or is this
Mick> vendor dependant ?

Some do, some don't. SOme people compile in static arrays of connection
control blocks, some use dynamically linked chains. Most have no fixed
limit.

Mick> 4. In relation to the above what would be the things that would affect
Mick> performance the more connections that any particular system entered
Mick> into ?, would they for example be concerned with keeping each
Mick> connection alive, managing tables of connections, or something else.

If you don't do keepalives, the only concern is memory for tables, and
maybe swapspace for those programs that may be attached to some
connections that have been idle for a while.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 13:19:41 GMT
From:      marant@univ-lille1.fr (Dominique Marant)
To:        comp.protocols.tcp-ip
Subject:   SMTP - local node is not recognized

Hello,

I have a problem with UCX-SMTP.
I send successfully mail to a other ip host but I can't receive.

When a user try to send me a mail, my node (lip5nx) refuse it. 

The transcript of session is :
----------------------------

While talking to lip5nx.univ-lille1.fr:
>>> RCPT To:<system@lip5nx.univ-lille1.fr>
<<< 551 <<system@lip5nx.univ-lille1.fr>> ... User not local, Relay disabled.
550 system@lip5nx.univ-lille1.fr... User unknown

My ucx config is :
----------------

UCX> sh config smtp
 
SMTP Configuration
                                                                   Options
Initial interval:   0 00:30:00.00       Address_max:    16       NOEIGHT_BIT
Retry interval:     0 01:00:00.00       Hop_count_max:  16       NORELAY
Maximum interval:   3 00:00:00.00
 
Timeout             Initial       Mail    Receipt       Data  Terminate
  Send:                   5          5          5          3         10
  Receive:                5
 
Alternate gateway:  LILSERV
General gateway:    LILSERV
 
Substitute domain:  not defined
Zone:               UNIV-LILLE1.FR
 
Postmaster:         UCX_SMTP
Log file:           SYS$SPECIFIC:[UCX_SMTP]UCX$SMTP_LOGFILE.LOG
 
Generic queue       Queues   Participating nodes
                     
UCX$SMTP_LIP5NX_00     1     LIP5NX
UCX> 


Anyone could help me ?
Thanks in advance.


--
Dominique Marant   -   marant@univ-lille1.fr 

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 13:23:47 GMT
From:      king@CS1sequoia.com (King)
To:        comp.protocols.tcp-ip
Subject:   Sniffers

Can anyone recommend a reasonably priced Sniffer that will break
down TCP/IP packets and give error stats like runts and crc errors.

Jack



-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 19:09:29 EST
From:      Andrew T. Robinson <ANDY@MAINE.MAINE.EDU>
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

From: mk@tfs.com (Mike King)
>Don't forget the link from hermes.merit.edu to CI$ is through SprintNet.
>Another 7-bit connection....
>

What are the access charges for telnetting to CIS via hermes?

Andy

PS -- please reply directly to ANDY@MAINE.MAINE.EDU

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 19:11:57 EST
From:      Andrew T. Robinson <ANDY@MAINE.MAINE.EDU>
To:        comp.protocols.tcp-ip
Subject:   Bridge/brouter recommendations?

I need to spec out a remote brouter for the following scenario:

Two 10base2 networks (mix of DECNET and TCP/IP) connected by leased
T1 or equivalent.

Requirements:

* Management (SNMP-n)
* Capable of reliably driving T1 link to capacity
* Route TCP/IP and DECNET (?)

I don't have any particular experience with bridging devices (or much
with routers, for that matter--just Cisco AGS+), so if these specifications
are out of line, that would be good to know.

Suggestions for vendors (please include at least vendor name and phone
number :-) and/or other features to look for would be appreciated.

Please respond directly to ANDY@MAINE.MAINE.EDU

Andy

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 19:19:33
From:      mukesh@lucknow.lucknow (Mukesh Kacker)
To:        comp.protocols.tcp-ip
Subject:   BSD socket option SO_LINGER interpretation for TCP



Here is what I deciphered from the BSD implementation
about the approximate semantics of SO_LINGER option
as implemented in BSD code over TCP (AF/PF_INET/SOCK_STREAM).
It is not quite what one might expect.

-------
The effect on the behavior of close() will be as follows:

(1) For a SS_CONNECTED socket,
   if SO_LINGER is set to 0 value
        the socket will send any immediate outstanding data and then close
        the TCP connection  (direct transition to CLOSED state) This
        may result in lost data.
   otherwise (=> SO_LINGER not set or set to value other than 0)
	go through TCP orderly shutdown states (FIN_WAIT_*/CLOSING/TIME_WAIT etc).

(2) If SO_LINGER is set (regardless of value of linger time period)
        The call to PRU_DETACH (that detaches the TCP control
        block from socket control block) after step (1) will be
        delayed indefinitely until the socket SS_CONNECTED state of
        socket is cleared.

(3) The linger time value (other than it being 0 or not) is ignored. This
   seems to be a deficiency in implementation.


Comment anyone ? Any insight into why the time in the linger
has been ignored in the BSD implementations ?

-Mukesh Kacker



-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 14:46:56 GMT
From:      tad@cerc.wvu.edu (Tad Alan Davis)
To:        comp.protocols.tcp-ip
Subject:   EZRPC


Post for a friend:

Does anyone know of a product called EZRPC?  If so, please answer the
following.

- Who is the vendor and phone number or address?
- What platforms does it run on?
- What is your opinion of the product?

Thanks

-- 
Tad Davis
Concurrent Engineering Research Center

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 23:51:09 -0500
From:      "Jeremy G. Mereness" <zonker+@CMU.EDU>
To:        comp.protocols.tcp-ip
Subject:   Building a Firewall


Greetings. I'm new to this group, so I hope this question is appropriate.

I have a small TCP network of 50 or so Unix platforms that I would like to
bridge to my campus WAN, which is on the internet. The catch is that I must
keep my small lan tightly secure. I would like to be able to ftp out, for
instance, but not allow outside sources to see in. 

I understand that this would be called a "firewall" and that many companies
use such a set up to isolate their networks from intrusion. I am looking for
references detailing how something like this is put together. 

At the least, I would like to enable the one machine with the two interfaces
to act on both of my networks. But I am uncertain how to direct the machine
to treat one interface differently from the other. All of my references on
networking seem to assume a single network interface. 

Are there references or an FAQ that address this issue? 

Thanks in Advance.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|Jeremy Mereness zonker+@cmu.edu    | Support      \ Ye Olde Disclaimer:   |
|Programmer/Analyst, FAST Laboratory|    Free       \ The above represents |
|GSIA - Carnegie Mellon University  |     Software   \  my opinions, alone.|
|B.S.Mechanical Engineering, CMU'92 | NeXTMail Welcome\   Ya Gotta Love It.|
|                   Every Silver Lining's Got a Touch of Grey              |
----------------------------------------------------------------------------

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 15:54:57 GMT
From:      mikeh@hds.com (Mike Hartman)
To:        comp.protocols.tcp-ip
Subject:   Question about Bootp broadcast addresses

RFC 951 states when constructing the IP header of the bootrequest:

" When the server address is unknown, the IP destination address will be the
'broadcast address' 255.255.255.255.  This address means 'broadcast on the
local cable, (I don't know my net number)'. "

Is it permissible for Bootp clients to use broadcast addresses other than
255.255.255.255 to broadcast on the local net??  Would it be uncommon?


-- 
Michael Hartman			  | e-mail: mikeh@hds.com
Software Engineer		  | phone:  (215) 277-8300
Human Designed Systems, Inc.	  | FAX:    (215) 275-5739
421 Feheley Drive		  |
King of Prussia, PA 19406  (USA)  |
----------------------------------------------------------------

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 17:36:35 GMT
From:      mk@tfs.com (Mike King)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

In article <CJExn6.8o0@inesc.pt>, Luis M. Delgado <lmd@avila> wrote:
>
>Did anybody succeded using The Compuserve Information Manager over Telnet to
>CIS ?
>
>
>I'm having many troubles. I believe, althought I'm not sure that hermes
>limits communications to 7 bits, because I usied an Telnet 8-bit connection
>to hermes, and I still can't get CIM to work with it.

Don't forget the link from hermes.merit.edu to CI$ is through SprintNet.
Another 7-bit connection....

Mike

mk@tfs.com                Speaking for me only...


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 17:49:55 GMT
From:      cah@tactix.rain.com (Chris Huey)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer

Edward Wells (wellseh@agedwards.com) wrote:
: We have a requirement to send files of approximatly 100Kbytes - 13Mbytes to
: multiple locations.  The number of locations is estimated between 500-600.
: We beleive a UDP file transfer program would be what we need.  Does anyone
: know if such a beast exists?  Or, is there an alternate method to send these
: files to these locations?
:
: Thanks in advance,
:
: Ed.

The following is an unpaid commercial announcement:

	If your TCP/IP network allows broadcast packets to reach your 
	remote sites, you can reduce file upload times from hours to 
	minutes with the Tactix broadcast file transfer. This is a way 
	to reliably broadcast a file to hundreds of ethernet connected 
	systems and reduce 8 hours of rcp copy time down to 15 minutes.

	For more details, Email to:  sales@tactix.rain.com

We now return you to your regularly scheduled Usenet.

Chris
-- 
Chris Huey                                           Tactix ReEngineering, Inc.
cah@tactix.rain.com                                       Voice: (503) 684-4099
           "CodeCrafters: Custom crafted software in about an hour"

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 19:03:19 GMT
From:      bsmith@rahul.net (Bob Smith)
To:        comp.protocols.tcp-ip
Subject:   help: STREAMS & multi-addresses

I have an application in which I would like to have multiple IP stacks.
The application is a network 'load box'.  The load box should look like
a router with 4 hosts behind it. Sometimes the application acts as a SLIP
interface and sometimes it does its own packet assembly.  I would like to
solve this problem without writing kernel resident code.  Arranging the 
stack vertically, one configuration might be:

   MyApp1          MyApp2           MyApp3            MyApp4   \
  sockmod         sockmod          sockmod              |      |
   tcp1            tcp2             udp3                |      | pseudo-
    ip1             ip2              ip3                |      |  hosts
   slip1           slip2            slip3             slip4    |
   pts1            pts2             pts3              pts4     /
     |               |                |                 |
     |               |                |                 |
   ptm1            ptm2             ptm3              ptm4
   slip5           slip6            slip7             slip8
     |               |                |                 |
     ----------------------------------------------------
                             |
                            ip
                            le0
                             |
                             |
                             |
                         (Ethernet)

I have SLIP attached to the pseudo ttys properly and can ifconfig the
slip interfaces OK.  The problem is this:

    How can I create *COMPLETELY* independent copies of /dev/ip,
    /dev/tcp, /dev/udp, and /dev/icmp?


Any advice would be greatly appreciated.

Bob Smith
-- 
Bob Smith <bsmith@rahul.net>

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 20:20:05 GMT
From:      evansmp@mb4803.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Packet Fragmentation

Barry Margolin (barmar@think.com) wrote:
: In article <2gjb4e$5a9@news.csie.nctu.edu.tw> edward@comserv_fddi.itri.org.tw (Chao-Chi Yang 37h3100) writes:
: >   When the packet size is large than 1500, the socket
: >primitive 'sendto' will set 'errno' to 40 (message too
: >long).  Does I must deal with the packet fragmentation
: >myself ? 
 
: Are you trying to send broadcasts?  Many IP implementations (including
: Sun's) will not fragment broadcast packets.
 
: If you're sending unicast packets, I think the default UDP size limit is
: 8K, but there's an ioctl to increase it on a per-socket basis.

That happens to be the packet size for NFS block read/write.
Possibly something to do with it being the page size on a sun.


-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 20:27:35 GMT
From:      evansmp@mb4803.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Intelligent BOOTP servers?

John Matthews (matthews@mis.uswest.com) wrote:
: Can someone out there tell if anyone's written an intelligent
: BOOTP server for SunOS 4.1.2?  What I'm looking for is a BOOTP
: server that can automatically assign IP addresses based upon
: the source IP address in a BOOTP packet (which would be the
: IP address of the router interface that forwarded the packet).

The source for bootp servers is fairly common, it should be
quite trivial to patch this to look at the gateway field.

: I'd also like it to be able to look in an ARP cache database
: and reply with an IP address if one's already been in use by
: that specific device.  Lan Workgroup from Novell does most of

There is no way you can do this except if your gateway is using
proxy arp for it's subnet(s). Or you have some way to manipulate 
your router's arp cache.

Notabley you need to invalidate any existing entry then send
an arp request (to the right subnet)

: this except being able to compare against a master arp cache
: database.  I'd also like to have this running on UNIX instead
: of a Novell Fileserver.  I've been considering re-writing one
: of the existing BOOTP servers to do what I want, but I thought
: I'd ask here first.
: 			Thanks in advance,
: 				John Matthews
: 				matthews@mis.uswest.com

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 20:40:11 GMT
From:      dchirico@usr.com (David Chirico)
To:        comp.protocols.tcp-ip
Subject:   Subnetting

I understand that if I use a subnet address of 255.255.192.0 that I would have 
2 subnets allowed and about 16,000 host available. When I assign an IP address 
(using the subnet 255.255.192.0), what is the numerical range definition 
allowed in the 3rd octet? EXAMPLE: If I use a subnet 255.255.255.0,  any 
number(a range of 0-255) I use in the IP's 3rd octet would be a subnetwork.

DChirico@usr.com , 708-933-5743

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 20:54:29 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Bootp broadcast addresses

In article <2gui4h$bhg@netnews.upenn.edu> mikeh@hds.com (Mike Hartman) writes:
>RFC 951 states when constructing the IP header of the bootrequest:
>
>" When the server address is unknown, the IP destination address will be the
>'broadcast address' 255.255.255.255.  This address means 'broadcast on the
>local cable, (I don't know my net number)'. "
>
>Is it permissible for Bootp clients to use broadcast addresses other than
>255.255.255.255 to broadcast on the local net??  Would it be uncommon?

I think the RFC assumed that either a BOOTP client knows a specific server
address (e.g. it's configured in NVRAM) or it knows nothing about its
environment and must use a hard-coded destination.  In the latter case,
255.255.255.255 is the only reasonable hard-coded destination.

I think you could use other broadcast addresses; I would interpret this as
a case of "when the server address is known", even though this address
doesn't identify a specific machine.  However, it's not clear how useful
this would be.  If you configure <local-subnet>.255, the device won't
realize that it should be sent as a local broadcast, because it doesn't
know that <local-subnet> identifies the local subnet until it knows its
address and subnet mask.  And <remote-subnet>.255 won't work unless you
have proxy ARP enabled on your router, since the device probably doesn't
have any routing information configured yet.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 21:19:47 GMT
From:      ajay@ctron.com (Ajay Kumar Aggarwal)
To:        comp.protocols.tcp-ip
Subject:   a question about ipRouteType (mib-II)

What do the following values for ipRouteType in MIB-II signify :

   direct (3)
   indirect (4)

Thanks.

-ajay

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 21:32:15 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <1994Jan10.224028.13620@mmm.mmm.com>, ccg@tcdsp1.mmm.com
("Charles Ganzhorn") writes:
->
->As far as I know, the only issue with any isochronous application over
TCP/IP is
->whether you can guarantee delivery time and bandwidth:  neither of those two

   I think you really hit it on the head here.  TCP/IP was never really meant
   to carry isochronous traffic, hence any implementation of a isochronous
   application (e.g. voice, video..) will be a 'workaround' that involves
   a bit of buffering, and praying!  It is unfortunate that TCP/IP cannot
   easily facilitate these apps, because I really like the protocol suite,
   it is simple and easy to understand.  I do not know how many of you have
   had the opportunity to work with/learn about ATM, but this protocol suite
   is perfectly situated to handle isochronous traffic.  I certainly do not
   intend to start a flame war of TCP/IP vs. ATM!  The original question that
   started this thread was basically 'How do you carry voice over TCP/IP', and
   my simple answer is, 'In real time, without buffering and incurring some
   nasty overhead, you dont'...


Take it easy-

Sean Allen                                               Programmer/Analyst
(919)543-6021 Fax 7996                         Planning Acquisition Systems
Internal Zip: D533/B205                       IBM Personal Computer Company
VNET: RTP(SALLEN)                                Research Triangle Park, NC
#include<std_disclaimer.h>                   Internet: allensd@vnet.ibm.com

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:12:19 GMT
From:      aki <aki@akidamme-233324.worldbank.org>
To:        comp.protocols.tcp-ip
Subject:   What?  What do you mean you can't find yourself????



Boy, I'm stumped...

I friend of mine is running CMUTEK's flavor of TCP/IP on his 3400 microvax.

He is running DECNET also.  The ethernet cable is connected to a DELNI, which
in turn is connected to a (brand unknown) Unix box also running TCP/IP.

The  VAX gets an error (when attempting to TELNETing out to the UNIX box),
it comes back with the error:

TELNET-W-nopen, Can't open connection to <nodename>.


....followed by...

SYS-F-MEDOFL, Medium is offline.


He asked me to see if any of you CMUTEK gurus might know what all that
means....

I don't read this group as frequently as I should, so e-mail responses would
be GREATLY appreciated.

cheers,

-aki

email - aki@akidamme-233324.worldbank.org

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:34:48 GMT
From:      speierrm@agedwards.com (Roy M Speier)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer


Dan writes:
> Are all the nodes - well, I hope not 500-600, but maybe a great number
> of them, all connected on a single broadcast medium such as ethernet?
> If so, then a broadcast method would be ideal.  If not I would suggest
> tftp, or FSP.  Both can be used in a server or client initiated method.
> You just have to make sure that if the 600 clients are
> dumb and waiting for a download, that they have the "FSP server" or
> "T-FTP server" software running.

Anybody know what FSP is?  We are familiar with TFTP. Additionally, one of 
our main requirements is to minimize the network bandwidth utilized in 
sending these files, so a broadcast is definitely what we had in mind.  
We were hoping we wouldn't have to reinvent the wheel, so we were hoping 
to find a public-domain or freeware application-level interface sitting on 
top of the UDP broadcast to provide reliable transfers.

We run TCP/IP over a satellite.  The hosts at both ends of the satellite
run on Ethernet LANs, and the satellite in between acts like a MAC-layer
bridge.

Dan writes:
> With more detail to your situation, people can help you better.

Hope this provides a deeper understanding of our situation.

==============================================================================
Roy M Speier   	       	       	|  Internet:   speierrm@agedwards.com
BOS Dev. Team                   |  USnail:     780 Madison Ln  Florissant 63031
                                |  BellNet:    (314) 289-5791

-- 
==============================================================================
Roy M Speier   	       	       	|  Internet:   speierrm@agedwards.com
BOS Dev. Team                   |  USnail:     780 Madison Ln  Florissant 63031
                                |  BellNet:    (314) 289-5791

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:44:00 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Bootp broadcast addresses

Mike Hartman (mikeh@hds.com) writes:
> Is it permissible for Bootp clients to use broadcast addresses other than
> 255.255.255.255 to broadcast on the local net??  Would it be uncommon?

  It should be permissible, but I know of one 3rd-party bootpd
  implementation that rejected requests if the source IP address were not
  255...255 (!).
  
  On the other hand, it should be very uncommon.  It is true that bootp can
  be used just for its tftp capability.  But if the requesting system does
  not know its IP address, it probably does not know its network or subnet
  number either.  Therefore, anything other than 255...255 would be 
  presumptuous and prone to failure.

-- Ken Mintz

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:44:37 GMT
From:      shotokan@diku.dk (Kim H|glund)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Wanted: RFC931 Source

kraehe@bakunin.north.de (Michael Kraehe) writes:
>	I'm searching for a C-Source for the Authentication-Server described
>	in RFC931, it should run under any BSD compatible Unix without
>	the need of kernel patches.

Several such servers are available but the most commonly used is probably 
the one written by Peter Eriksson.  It's available via anonymous ftp from
ftp.lysator.liu.se as /pub/ident/servers/pidentd-2.2.tar.gz.

Enjoy,
--Kim

_____
Kim H|glund,  shotokan@diku.dk,    CS Dept. at U of Copenhagen,  Denmark
"I've got plenty of common sense. I just choose to ignore it." -- Calvin

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:56:47 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits

Steven Lawson (lawson@netcom.com) writes:
> I have two questions regarding TCP backoff and retransmit limits.  In
> TCP/IP Illustrated [Stevens] the example shows a total of 12 retransmit
> attempts backing off to a limit of 64 seconds.

  These limits are based on the BSD implementation.

  However, consider the real-world implications of going much beyond these
  limits.  The BSD implementation also has a resolution of 0.5 seconds for
  time-outs.  Thus, in the worst case, it might take as long as 6 minutes to
  transmit one packet; and one user transaction might require multiple
  packets.  I doubt that any user will wait that long for one transaction.

  On the other hand, if the "user" is a computer transmitting to another
  computer (on its way to Pluto), it might very well be prudent -- even
  necessary -- to allow for more and longer back-offs.

  There are no protocol-imposed limitations that I know of.

-- Ken Mintz

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:58:10 GMT
From:      eel@dross (Elena Leong)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router


Wow! The magic of the Internet!
To the ones who sent me advice, thanks for your time, and to the ones
who offered their consultancy services, thanks also, and we'll keep you 
in mind should we need your help.

Elena

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 23:01:03 GMT
From:      john@jwlab.FEITH.COM (John Wehle)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   tli rpc, tcp keepalive, and port monitor problem

We are porting an rpc application from AT&T UNIX SVR4 to
Solaris 2.x.  On the the first things that the application
does upon being invoke by the tcp listener is to turn
on TCP KEEPALIVE.  The code is as follows:

  {
  struct {
    struct opthdr header;
    long value;
    } socket_option;
  struct t_optmgmt tp_optmgmt;

  socket_option.header.level = SOL_SOCKET;
  socket_option.header.name = SO_KEEPALIVE;
  socket_option.header.len = OPTLEN(sizeof(socket_option.value));
  socket_option.value = 1;

  tp_optmgmt.opt.buf = (char *)&socket_option;
  tp_optmgmt.opt.len = sizeof(socket_option);
  tp_optmgmt.opt.maxlen = sizeof(socket_option);
  tp_optmgmt.flags = T_NEGOTIATE;

  (void)t_optmgmt(0, &tp_optmgmt, &tp_optmgmt);
  }
  if ((transp = svc_tli_create(0, nconf, NULL, 0, 0)) == NULL) {
    _msgout("cannot create server handle");
    exit(1);
    }

This approach works fine on AT&T.  On Solaris 2.2 (with patch 101018-7
(the keep alive patch) installed) svc_tli_create fails with the following
message:

  Jan 11 12:46:18 stsun sql_prot[686]: svc_tli_create: connection in a wierd state (127)
  Jan 11 12:46:18 stsun sql_prot[686]: cannot create server handle

Anyone have any ideas on how to activate TCP KEEPALIVE from a RPC program
started by the port monitor on Solarix 2.x?

John W.
-- 
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 23:32:32 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits

Stephen C. Trier (trier@odin.ins.cwru.edu) writes:
> It makes sense to limit it to a fixed period.  Think about it in the
> worst case -- the IP header has a field that limits the lifetime of a
> packet in real time.

  In practical (terrestial) terms, I agree.  But ....

  Normally, I believe that "ttl" is decremented for each intermediate (IP)
  system; and "ttl" is decremented for each second that the fragment is
  retained in a (IP) router's memory.

  So, if we assume that the intersystem transit time is no more than one
  second, I would agree with you that the fragment network life-time is
  limited to 255 seconds.

  However, what if the hop-to-hop time is longer than one second?  I don't
  believe there is any requirement to decrement "ttl" by more than one.
  (In fact, I think the RFCs require just the opposite.)

  I believe this situation could arise in space relay transmissions.

-- Ken Mintz

PS:  In more practical terms, these limits may be pushed when IP fragments
are encapsulated into other protocols, e.g. X25.  Although we should hope for
less than 1-second transit times even in those cases, there is no guarantee.

Note that the worst-case BSD total transmission time is 832 seconds, a little
under 14 minutes (!).  I believe I've seen time-outs occurring after 11
minutes for X25-encapsulated IP packets.  Needless to say, it was a really
bad and unusual (test) situation.


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 23:39:38 GMT
From:      esb+@cs.cmu.edu (Edoardo Biagioni)
To:        comp.protocols.tcp-ip
Subject:   TCP protocol bug?

I have been implementing TCP, and I have been puzzled by a bug
that seems permitted by the standards (RFC 793 and RFC 1122).

Consider the following situation: hosts A and B each send two segments
to each other, and all four segments are dropped. A and B eventually
time out, and retransmit their first segment.

In some implementations, the exact same segment as originally sent may
be retransmitted [RFC 1122, p. 90: "If a retransmitted packet is
identical to the original packet (which implies not only that the data
boundaries have not changed, but also that the window and
acknowledgement fields of the header have not changed) ..."]. Assume
that both A and B have such implementations, so that the segments from
each side are retransmitted with the original ack field.

The retransmissions actually go through, and A issues an ack for B's
packet. A must use snd.nxt as its sequence number [RFC 793, p. 74].
When B gets the ack, it queues the packet [RFC 793, p. 70: "In the
following it is assumed that the segment is the idealized segment that
begins at rcv.nxt... Segments with higher beginning sequence numbers
may [*should* as per RFC 1122] be held for later processing"]. Because
the ack is queued, it is not processed, and B's first segment remains
unacked no matter how many times A tries to ack it; and correspondingly
for A. This causes the connection to effectively hang, as no progress
can be made.

I have (of course) modified my implementation so retransmits now carry
the latest ack, but I was just wondering if this was a well-known bug
in the TCP standard. If not, and if it is indeed a bug, who should it
be reported to?

thanks

	edo

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 23:56:03 GMT
From:      heinau@chemie.fu-berlin.de (Vera Heinau)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Wanted: RFC931 Source

kraehe@bakunin.north.de (Michael Kraehe) writes:

>Moin folks,
>
>	I'm searching for a C-Source for the Authentication-Server described
>	in RFC931, it should run under any BSD compatible Unix without
>	the need of kernel patches.
>
>	Unfortunately there was no EMail-Adress of the author, so if
>	anybody knows how to Mail to <St. Johns> it will be nice if
>	Y mail his Email adress to me.

Take this:

#NAME		ftp.FU-Berlin.DE
#ADDRESS	130.133.4.50
#ORGANIZATION	Freie Universitaet Berlin
#LOCATION	Berlin, Germany; 52 31 N / 13 24 E
#ACCESS		no restrictions

FR--      52096 20-Dec-1993 14:56 /pub/unix/security/ident/servers/pidentd-2.2.tar.gz

(mirrored from ftp.lysator.liu.se)

Vera

--
 |~|    Vera Heinau                      |    Freie Universitaet Berlin 
 / \    heinau@Chemie.FU-Berlin.DE       |    Institut fuer Kristallographie
/FUB\                                    |    Takustrasse 6
`---'                                    |    D-14195 Berlin Germany

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 00:30:05 GMT
From:      dennisf@freeman.Eng.Sun.COM (Dennis Freeman)
To:        comp.protocols.tcp-ip
Subject:   Re: EZRPC

In article HnC@cerc.wvu.edu, tad@cerc.wvu.edu (Tad Alan Davis) writes:
> 
> Post for a friend:
> 
> Does anyone know of a product called EZRPC?  If so, please answer the
> following.
> 
> - Who is the vendor and phone number or address?
> - What platforms does it run on?
> - What is your opinion of the product?
> 
> Thanks
> 
> -- 
> Tad Davis
> Concurrent Engineering Research Center


NobleNet, Natick, MA -- 508-655-2438.  EZ-RPC runs on most things,
including Solaris x86.

---
Dennis Freeman
SunSoft (a Sun Microsystems Business)
2550 Garcia Ave., MTV08-111
Mountain View, CA 94043
United States of America
Voice (415) 336-0955; Fax (415) 336-5620
Email: dennis.freeman@Eng.Sun.Com



-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 23:07:25 +0100
From:      arg@regent.e-technik.tu-muenchen.de (Armin Gruner)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Wanted: RFC931 Source

kraehe@bakunin.north.de (Michael Kraehe) writes:

>Moin folks,
 
>	I'm searching for a C-Source for the Authentication-Server described
>	in RFC931, it should run under any BSD compatible Unix without
>	the need of kernel patches.
 
>	Unfortunately there was no EMail-Adress of the author, so if
>	anybody knows how to Mail to <St. Johns> it will be nice if
>	Y mail his Email adress to me.

ftp.informatik.tu-muenchen.de:
pub/comp/usenet/alt.sources/pidentd/pidentd-2.2.tar.gz

Regards
	Armin

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 00:48:11 GMT
From:      aki <aki@akidamme-233324.worldbank.org>
To:        comp.protocols.tcp-ip
Subject:   Re: What?  What do you mean you can't find yourself????

In article <1994Jan11.221219.17918@worldbank.org> aki,
aki@akidamme-233324.worldbank.org writes:
>I don't read this group as frequently as I should, so e-mail responses would
>be GREATLY appreciated.
>


I forgot to mention that he cannot ping the Vax either from the Vax or
from the Unix machine.  Telneting from the Vax back to itself doesn't
work either.

cheers,

-aki

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 00:49:29 GMT
From:      sylvia@forge.Tandem.COM (Sylvia Tom)
To:        comp.protocols.tcp-ip
Subject:   BSD Socket Test Suite

Keywords: Sockets

Does anyone know of existing socket library test suites which test 
the AF_UNIX and or AF_INET domains?

Thanks,
Sylvia
sylvia@forge.tandem.com



-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 05:01:24 GMT
From:      Dave.Mischler@Cubic.COM
To:        comp.protocols.tcp-ip
Subject:   CIDR & variable netmask implications on subnet addressing


I get the feeling that the restriction on all zeroes and all ones
subnets stated in RFC 950 should be eliminated with Classless
Inter-Domain Routing addressing rules, because it seems that it is at
best meaningless and probably harmful.  I have not seen this
explicitly stated, though.

For example, I wish to subnet part of network 198.65.56.0/255.255.248.0
with a mask of 255.255.255.192.  Under the RFC 950 rules
198.65.57.0/255.255.255.192 looks like a subnet of a class C network with
all zeroes in the 2-bit subnet field, and it is therefore unusable.  In
fact, half the address space in the network block would become unusable
if this netmask was used.

Can anyone provide an authoritative answer, and/or a pointer to a
reference that discusses this matter?

Can anyone discuss real-world experience using cisco routers in the kind
of addressing scheme described above [I have 9.1(4), 9.1(5), and 9.1(6)]?

Dave.Mischler@Cubic.COM

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 05:04:28 GMT
From:      jpb49312@uxa.cso.uiuc.edu (John Brzezniak )
To:        comp.protocols.tcp-ip
Subject:   How does bootp communicate without routing?

I'm wondering how bootp is supposed to send and receive packets when 
routing information is not present. Assuming one is running bootp on a machine
without an IP address and the only routes the machine has are local loopback.
IP and UDP, which bootp uses to send packets, both require routing tables
to send these packets. But since these routing entries except for loopback do 
not exist, the bootp request should be discarded. 

One way of getting around this would be to not use ip and udp and manually build
the whole packet (bootp encapsulated with udp enacapsulated with ip) in the
bootp process/function and send it directly to the network interface but then
why use udp and ip for bootp?

Another way would be for bootp to add broadcast send and receive routes to the
routing table and then send the bootp packet. Is this the standard way of
sending and receving a bootp packet using udp and ip? (rfc951 doesn't mention
anything about routing with clients).

Are there any other ways of getting around this that I'm not seeing? Thanks
for any help...

			John


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 06:02:38 GMT
From:      paul@alantec.com (G. Paul Ziemba)
To:        comp.protocols.tcp-ip
Subject:   Re: How does bootp communicate without routing?

jpb49312@uxa.cso.uiuc.edu (John Brzezniak ) writes:

>[how can bootp work if the client has no routes]
 
>Are there any other ways of getting around this that I'm not seeing? Thanks
>for any help...

It's not clear to me from your post what sort of machine you
are working on, and to what extent you can change the code
that runs on it. This makes it hard to be specific. Since you
posted in comp.protocols.tcp-ip, I'll assume we're in the IP
world :-)

A box that needs to elicit a bootp reply from some
server can, a priori, know the following:

	The broadcast IP address is 255.255.255.255

	The broadcast hardware address (for ethernet) is ff-ff-ff-ff-ff-ff

This knowledge may be embedded in the routing code, the arp code,
or both. Alternatively, depending on how the networking code is
constructed, the bootp client might have to stuff entries into the
arp table or the routing table to Do The Right Thing.

Presumably, the server can be reached by broadcast. If not, the
client needs help, either in the form of a helper server on its
local subnet, or in the form of additional knowledge programmed
into the client (e.g., non-volatile memory containing a route
to use).

cheers,

 ~!paul

How's that for a vague answer to a broad question?
-- 
Paul Ziemba, software archaeologist: paul@alantec.com	alantec!paul
    "The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man." - George Bernard Shaw

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 15:15:09
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling

In general (and as required by rfc1122) TCP timeout and retransmission
algorithms are designed for networks where the primary reason that a timeout
would occur is due to packet drops or delays due to a congested network.  In
this case, retransmitting more quickly is unlikey yo help at all, and in
fact will probably hurt the network as a whole.

It would be extremely unfriendly to adjust your TCP to use faster timeouts.

The traditional solution for subnet technologies that have a high packet
loss rate due to actual transmission errors (eg, amateur packet radio) is to
use a link-level transmission protocol with its own error correction
capabilty (eg LAPB.)  Since the protocol would be local to the subnet, it
can have intimate knowledge of the transmission characteristics of that
subnet.  It would be a bad idea to adjust TCP level timers in an attempt
to correct for bad behavior in a single link.

BillW
cisco


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 11:13:58 GMT
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: EZRPC


we wrote a really really trivial RPC system to go with Tcl (but so you didn't have to use intermachine send...) based on SMC RPC - can ftp it from
cs.ucl.ac.uk
in
darpa/rpctxt.tar.Z
for anon ftp

all the usal dis and dat claimers apply...

-- 
jon crowcroft (hmmm...)

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 12:16:16 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a Firewall

Look in the pub/fwtk directory on ftp.tis.com for a pretty neat publically-available
firewall toolkit and some good docs on the subject.  You'll find some other general
network and system security stuff in pub/security on ftp.delmarva.com.

	- John

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
|  Time is Nature's way of preventing everything from happening at    |
|  once.                                                              |
+---------------------------------------------------------------------+



-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 12:33:05 GMT
From:      griesser@zeus.uni-duisburg.de (Michael Griesser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling

In article 2gsc1rINNi11@early-bird.think.com, barmar@think.com (Barry Margolin) writes:

>The long timeouts in TCP/IP's fault recognition mechanisms are there for a
>reason: they should not be tripped by temporary network problems (such as a
>dial-on-demand SLIP line hanging up, a network administrator unplugging

That's all pretty useful in a large LAN or a WAN, but one could imagine 
applications for what setting timeout values to a few seconds is a need.
Stevens mentions two socket options SO_RCVTIMEO and SO_SNDTIMEO in his 
book, but as he said these are not used so far. But the fact, that they
do exist shows, that someone saw a use for them before.

>If you need to check on the health of a peer in real time, put this in the
>application protocol.

Well, that would be the consequence, if there's no other way. I was just
wondering, why to invent the wheel a second time ...

Is there really no access to the lower layers while using TCP ?

>-- 
>Barry Margolin
>System Manager, Thinking Machines Corp.

Ciao   Michael

--------------------------------------------------------------------
Michael Griesser, FB7 Fachgebiet Technische Informatik  Uni Duisburg
griesser@zeus.uni-duisburg.de   IRC: mowgli    M.GRIESSER@IUS.gun.de


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 12:34:36 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD socket option SO_LINGER interpretation for TCP

>Here is what I deciphered from the BSD implementation
>about the approximate semantics of SO_LINGER option
>as implemented in BSD code over TCP (AF/PF_INET/SOCK_STREAM).
>It is not quite what one might expect.
>
>The effect on the behavior of close() will be as follows:
>
>(1) For a SS_CONNECTED socket,
>   if SO_LINGER is set to 0 value
>        the socket will send any immediate outstanding data and then close
>        the TCP connection  (direct transition to CLOSED state) This
>        may result in lost data.
>   otherwise (=> SO_LINGER not set or set to value other than 0)
>	go through TCP orderly shutdown states (FIN_WAIT_*/CLOSING/TIME_WAIT etc).
>
>(2) If SO_LINGER is set (regardless of value of linger time period)
>        The call to PRU_DETACH (that detaches the TCP control
>        block from socket control block) after step (1) will be
>        delayed indefinitely until the socket SS_CONNECTED state of
>        socket is cleared.
>
>(3) The linger time value (other than it being 0 or not) is ignored. This
>   seems to be a deficiency in implementation.
>
>Comment anyone ? Any insight into why the time in the linger
>has been ignored in the BSD implementations ?

Current BSD sources (Net/2 and later) do indeed use the linger time.
Unfortunately then interpret it as the number of clock ticks to wait
for all the data to be ACKed by the other end before close returns an
error, but I think POSIX.12 is changing that to be #seconds.

From my notes in going through the linger option a while back,
I broke the close into three states.

(1) l_onoff = 0 means normal close.  close() returns immediately but the
    kernel tries "its best" to get any outstanding data to the other end.
    If the data never gets to the other end, or never gets acked, you'll
    never know about it.

(2) l_onoff nonzero and l_linger = 0 means abort.  close() causes a TCP
    RST to be sent and any queued data is thrown away.

(3) l_onoff nonzero and l_linger nonzero means orderly release with a fixed
    time limit for close() to block, waiting for all outstanding data to be
    sent and acked by the other end.  This is where the interpretation of
    units for l_linger changed from pre-Net/2 to Net/2.  I think earlier
    systems could block forever here?

I think many vendor systems support (1) and (2) but block forever in
case (3).

	Rich Stevens  (rstevens@noao.edu)

p.s. -- Mukesh: check out the -L option for my sock program, pp. 505-506
	of "TCP/IP Illustrated".  That's how Net/2 does it.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 12:44:14 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a Firewall

> I understand that this would be called a "firewall" and that many companies
> use such a set up to isolate their networks from intrusion. I am looking for
> references detailing how something like this is put together. 
>
> At the least, I would like to enable the one machine with the two interfaces
> to act on both of my networks. But I am uncertain how to direct the machine
> to treat one interface differently from the other. All of my references on
> networking seem to assume a single network interface. 
>
> Are there references or an FAQ that address this issue? 

Bill Cheswick and Steve Bellovin (AT&T Bell Labs) have written a book
on this that's due to be released in a few months (April?).  The full
reference is:

%T Firewalls and Internet Security: Repelling the Wily Hacker
%A W. R. Cheswick
%A S. M. Bellovin
%I Addison-Wesley
%C Reading, Mass.
%D 1994
%X ISBN 0-201-63357-4

An earlier paper that may be of interest is Cheswick's "The Design
of a Secure Internet Gateway" from the USENIX Proceedings, Summer
1990 Conference, Anaheim, CA.  I think office@usenix.org can Xerox
a copy of individual papers for a minimal fee.

	Rich Stevens  (rstevens@noao.edu)

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 13:02:19 GMT
From:      lmd@avila (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

mk@tfs.com (Mike King) writes:
: In article <CJExn6.8o0@inesc.pt>, Luis M. Delgado <lmd@avila> wrote:
: >
: >Did anybody succeded using The Compuserve Information Manager over Telnet to
: >CIS ?
: >
: >
: >I'm having many troubles. I believe, althought I'm not sure that hermes
: >limits communications to 7 bits, because I usied an Telnet 8-bit connection
: >to hermes, and I still can't get CIM to work with it.
: 
: Don't forget the link from hermes.merit.edu to CI$ is through SprintNet.
: Another 7-bit connection....
: 
: Mike
: 
: mk@tfs.com                Speaking for me only...
: 

Then the conclusion should be: "There is no turnaround." ? 
and "No way for CIM over hermes.merit.edu" ?

Or is there some other way ?


Best Regards.
--
Luis Delgado
INESC-CCAE
e-mail: lmd@inesc.pt

----------------

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 13:06:16 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a Firewall

In article 10749@noao.edu, rstevens@noao.edu (W. Richard Stevens) writes:

>snip>
 
> %T Firewalls and Internet Security: Repelling the Wily Hacker
> %A W. R. Cheswick
> %A S. M. Bellovin
> %I Addison-Wesley
> %C Reading, Mass.
> %D 1994
> %X ISBN 0-201-63357-4
> 
> An earlier paper that may be of interest is Cheswick's "The Design
> of a Secure Internet Gateway" from the USENIX Proceedings, Summer
> 1990 Conference, Anaheim, CA.  I think office@usenix.org can Xerox
> a copy of individual papers for a minimal fee.
> 
> 	Rich Stevens  (rstevens@noao.edu)


This paper is in directory pub/security as file gateway.ps.Z on ftp.delmarva.com.

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
|  Time is Nature's way of preventing everything from happening at    |
|  once.                                                              |
+---------------------------------------------------------------------+



-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 13:34:21 GMT
From:      cake@cs.tu-berlin.de (Carsten Krebs)
To:        comp.protocols.tcp-ip
Subject:   IP Multi Cast


Hi,

I have to report about IP Multi Cast and I'm searching for examples 
or references to books explaining IP Multi Cast.
Does anybody know something about it ?

	Bye,
-- 
Carsten Krebs, Pfalzburger Str. 49, 10717 Berlin (Germany), Tel: 861 86 52
cake@cs.tu-berlin.de or vision@zelator.in-berlin.de

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 13:41:31 GMT
From:      gadi@fibronics.co.il (Gadi Kizner)
To:        comp.protocols.tcp-ip,comp.sys.m68k
Subject:   TCP for m68k embedded system

Hi.

I am curious to know if anyone has recommendations for off-the-shelf
( or public domain ) package of TCP and TELNET implementation for
embedded m68K system.

We are using MC68302 integrated multi-protocol processor in
EDX task switcher environment.

Please reply by mail, if possible.
Thanks in advance.


-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 14:20:04 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a Firewall

"Jeremy G. Mereness" <zonker+@CMU.EDU> writes:
>I understand that this would be called a "firewall" and that many companies
>use such a set up to isolate their networks from intrusion. I am looking for
>references detailing how something like this is put together. 

	The firewalls mailing list and archives are a good place to
start. The archives are FTPable from ftp.greatcircle.com, and the
mailing list can be joined by sending mail to majordomo@greatcircle.com
with "subscribe firewalls" in the message body.  Other good places to
look for information are on research.att.com, in dist/internet_security,
and ftp.tis.com, in pub/firewalls.

>Are there references or an FAQ that address this issue? 

	There's supposedly a FAQ that I am working on, but it's not quite
ready to release yet. :(

	TIS provides the internet firewall toolkit, which is a set of
components for building internet firewalls. It's FTPable from ftp.tis.com
in pub/firewalls/toolkit.

mjr.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 14:46:39 GMT
From:      kent@exodus.reuters.com.sg (kent)
To:        comp.protocols.tcp-ip
Subject:   Wollongong TCP/IP information

I am looking for any sites or books that has write-ups on
Wollongong TCP/IP. Is there any way to contact Wollongong Sales
representatives in the net? 
Any Reply will be greatly appreciated.
Kent

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 14:49:25 GMT
From:      dewaynea@netcom.com (Dewayne Adams)
To:        comp.protocols.tcp-ip
Subject:   Large IP Site Management Tool Wanted

We are in the process of moving/adding TCP/IP to our network with 
involves 85 subnets (sites) and almost 3500 hosts and users. 

Does anyone know of a management tool that assists in the administration 
of the IP addresses and the users? I guess that it should talk and update 
the Sun NIS+ files (DNS).

Thanks in advance.

--Dewayne 


-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 20:44:33
From:      drw@euler.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJHIHr.GsI@sernews.raleigh.ibm.com> sallen@herbie.raleigh.ibm.com (Sean Allen) writes:

      It is unfortunate that TCP/IP cannot
      easily facilitate these apps, because I really like the protocol
      suite, it is simple and easy to understand.  I do not know how
      many of you have had the opportunity to work with/learn about
      ATM, but this protocol suite is perfectly situated to handle
      isochronous traffic.

There are a number of intrinsic difficulties here:

1) One reason TCP/IP is so simple is that it does not deal with
resource allocation.

2) ATM delivers reasonably good isochronous performance because the
path that the data takes is fixed at circuit-setup time.  (Although
ATM avoids the mistake of reserving the full-time, like OSI horrors.)
Unfortunately, this makes it impossible to re-route around network
failure or congestion in a way that is transparent to the application,
which is one of the design criteria of TCP/IP.  (Literally, resistance
to nuclear attack.)

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
The universe owes you nothing; not even survival.  *Especially* not survival.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 94 15:47:34 GMT
From:      NSC066@TWNMOE10.Edu.TW
To:        comp.protocols.tcp-ip
Subject:   Introductory articles

Hi,
    I wonder if anyone can point me to some introductory articles
about the concept in networking. I would like to know what all those
means: IP address, domain server, netmask, ....
    Please e-mail me at nsc066@twnmoe10.edu.tw
    Thanks in advance
 
Alex

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 15:56:09 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for OS/2 2.0 Bug in FTPd?

In article <2gvkgi$3f9@ncrpda.curtin.edu.au> peter@ncrpda.curtin.edu.au (Peter N Lewis) writes:
>rer3@quads.uchicago.edu (Rich Robbins) writes:
>
>Ahh, now there is a deep question!  The commands are actually NLST 
>and LIST.  And the "correct" behaviour is dubious.  According to the
>proper FTP specs, the NLST (name list) command should not return
>the names of directories.  It would seem that IBM's OS/2 server does this.
>Unfortunately, that makes it the *only* server on the planet that does this.
>So as you see, "correct' becomes a relative term.  However, I would 
>have thought that Fetch would only use the LIST command, and interpret
>that, so I assume that its probably just a slight variation of the LIST
>output (which is unspecified by the FTP protocol, which has proved to
>be an extreemly stupid decision).

I must have missed this when writing my Windows FTPd - I wrote it from
rfc765, which just seems to state that NLST should list the file names
only (is a subdirectory a file or no?) - what other RFC's did I miss
here?

Thanks,
Alun.
~~~~
-- 
The above is a personal opinion, and may not necessarily represent the
opinions of Welcom Software Technology, its management, its staff, or
its Margarita machine.
======================================================================

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 16:24:05 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJHIHr.GsI@sernews.raleigh.ibm.com> allensd@vnet.ibm.com writes:

>   I think you really hit it on the head here.  TCP/IP was never really meant
>   to carry isochronous traffic, hence any implementation of a isochronous
>   application (e.g. voice, video..) will be a 'workaround' that involves
>   a bit of buffering, and praying!  

I gather that you haven't been tracking the IETF/IRTF work on resource
reservation mechanisms.  I'd suggest you look at the Internet Draft on
RSVP (draft-braden-rsvp-* I think) as a starting point.

>   I do not know how many of you have had the opportunity to work 
>   with/learn about ATM, but this protocol suite is perfectly situated 
>   to handle isochronous traffic.  

Not really.  ATM as currently specified and built can't handle multicast
efficiently.  Moreover, ATM is primarily being deployed in two ways:

	1) by phone companies to carry voice phone calls using AAL 1
	2) by the Internet to carry IP over ATM AAL 5

ATM is a subnetwork technology not an internetwork technology, so the
two just aren't directly comparable.  Also, voice works just fine over
UDP/IP in the current Internet provided one has the bandwidth that
one's voice encoding requires (NB the bandwidth requirement is NOT
special to any networking protocol, it is dependent on the voice
encoding algorithm one is using).  Ah yes, and I spend most of
1991-1993 working with ATM so I have some small experience with the
technology.  ATM has its uses, but it isn't the panacea that it is
hyped to be.

Ran


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 17:04:49 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits

In article <CJHo28.DrG@cup.hp.com> mintz@cup.hp.com (Ken Mintz) writes:
>Stephen C. Trier (trier@odin.ins.cwru.edu) writes:
>> It makes sense to limit it to a fixed period.  Think about it in the
>> worst case -- the IP header has a field that limits the lifetime of a
>> packet in real time.
>
>  In practical (terrestial) terms, I agree.  But ....
>
>  Normally, I believe that "ttl" is decremented for each intermediate (IP)
>  system; and "ttl" is decremented for each second that the fragment is
>  retained in a (IP) router's memory.
>
>  So, if we assume that the intersystem transit time is no more than one
>  second, I would agree with you that the fragment network life-time is
>  limited to 255 seconds.
>
>  However, what if the hop-to-hop time is longer than one second?  I don't
>  believe there is any requirement to decrement "ttl" by more than one.
>  (In fact, I think the RFCs require just the opposite.)
>
>  I believe this situation could arise in space relay transmissions.

Actually the original IP RFC (RFC791) states the following:

  Time to Live:  8 bits

    This field indicates the maximum time the datagram is allowed to
    remain in the internet system.  If this field contains the value
    zero, then the datagram must be destroyed.  This field is modified
    in internet header processing.  The time is measured in units of
    seconds, but since every module that processes a datagram must
    decrease the TTL by at least one even if it process the datagram in
    less than a second, the TTL must be thought of only as an upper
    bound on the time a datagram may exist.  The intention is to cause
    undeliverable datagrams to be discarded, and to bound the maximum
    datagram lifetime.

But in practice virtually all IP implementations treat TTL as a hop count.
This works out ok in most high speed networking environments, where the
packet delay is rarely over one second.  But in low speed or high delay
environments, the delay can certainly be greater than one second.  The
1/4 sec. one hop satellite delay can easily be exceeded by queueing delays
onto a low speed link.  I believe that the Router Requirements draft discusses
this.

Art


-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 17:17:12 GMT
From:      jmbr@sxb.bsf.alcatel.fr ( Jean_Marc BRETTNACHER #Jean-Marc BRETTNACHER)
To:        comp.protocols.tcp-ip
Subject:   CISCO Protocol Translator MIB

Hello everybody,

I would likre to know if sombody is using the Protocol TRanslator option on
CISCO router, and if yes on which ftp server i can get i ....

Thanks a lot.
po@dit.sxb.bsf.alcatel.fr

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 17:19:53 GMT
From:      jmbr@sxb.bsf.alcatel.fr ( Jean_Marc BRETTNACHER #Jean-Marc BRETTNACHER)
To:        comp.protocols.tcp-ip
Subject:   Looking for tcp-ip Gatekeeper TIS

Hello !

I am looking for a ftp server where i can find a Gatekeeper fot tcp-ip networks
called TIS ( like HSC ).

Can you help me ????
po@dit.sxb.bsf.alcatel.fr

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 94 17:52:14 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJHIHr.GsI@sernews.raleigh.ibm.com>, sallen@herbie.raleigh.ibm.com (Sean Allen) writes:
|> In article <1994Jan10.224028.13620@mmm.mmm.com>, ccg@tcdsp1.mmm.com
|> ("Charles Ganzhorn") writes:
|> ->
|> ->As far as I know, the only issue with any isochronous application over
|> TCP/IP is
|> ->whether you can guarantee delivery time and bandwidth:  neither of those two
|> 
|>    I think you really hit it on the head here.  TCP/IP was never really meant
|>    to carry isochronous traffic, hence any implementation of a isochronous
|>    application (e.g. voice, video..) will be a 'workaround' that involves
|>    a bit of buffering, and praying!  It is unfortunate that TCP/IP cannot
|>    easily facilitate these apps, because I really like the protocol suite,
|>    it is simple and easy to understand.  I do not know how many of you have
|>    had the opportunity to work with/learn about ATM, but this protocol suite
|>    is perfectly situated to handle isochronous traffic.  I certainly do not
|>    intend to start a flame war of TCP/IP vs. ATM!  The original question that
|>    started this thread was basically 'How do you carry voice over TCP/IP', and
|>    my simple answer is, 'In real time, without buffering and incurring some
|>    nasty overhead, you dont'...
|> 
|> 
|> Take it easy-
|> 

To a certain extent you kind of missed my point:  guaranteeing delay and
bandwidth are not network layer (IP) or transport layer (TCP or UDP) concerns
since neither of these two layers could do anything about it even if they were
designed to be specifically conscious of the issue.  You can only guarantee
bandwidth and transit delay at the datalink layer (e.g.,ethernet, token ring,
FDDI, ATM) and below.  Because guaranteeing bandwidth and delay are constraints 
related to media access:  I need guaranteed access to the media on such and such 
intervals and I'm going to need such and such bandwidth when I access.

Comparing ATM and TCP/IP directly is comparing apples and oranges.  ATM is still
going to need some kind of network and transport layer.  That is unless the flat
earth society (a la NetBIOS and token ring) has its way.  If designs come out for
ATM that don't have a network layer, we will find ourselves in the same mess as
we do with token ring and ethernet integration.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 18:09:20 GMT
From:      msbat@u.washington.edu (Autumn Blanchard)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Need help w/ Versaterm SLIP, MacTCP, etc.


I need some help getting MacTCP and Versaterm Adminslip, and my 
SLIP account working.  I just bought The Internet Start Kit for 
Mac (TISK) and I'm having problems with my new SLIP account at NW 
Nexus.

Here's the problem.  I dial-up and login to my SLIP account using 
Versaterm AdminSLIP.  Everything appears to work just fine.  The 
"Terminal Window" of VT AdminSLIP displays what appears to be a 
normal interaction between the VT AdminSLIP script and the NWNexus 
login shell.  But I cannot get a response from their name server 
or any other computer.

The IP address I get from the server appears correctly in the IP 
address box of MacTCP (and changes with each new login).  The only 
hint I get of a problem at this point is in the MacTCP 
Administrator dialog box.  I have noticed that in TISK's 
illustrations the Class is A, but I cannot get this to change.  I 
have tried all sorts of changes to both used and fresh copies of 
MacTCP 2.0.4, but whenever I select the Obtain Address from Server 
button, the class changes to Class C.

Anyway, after canceling the MacTCP dialog box, I assume that my 
SLIP connection is working, so I try to make an FTP connection
with Fetch, but the domain name server does not respond.  I also
tried connecting to other machines by IP number with Fetch, and
these connections do not work.  I called NW Nexus to get help and
they suggested various changes in the DNS entries of MacTCP, which I
tried without any success.

At this point I wondered if any communication was going out of
my modem to NW Nexus' system.
So next, I tested the SLIP connection with MacTCP Watcher 1.1.0 
and these are the overall results:

          IP ADDRESS TESTED (entered in MacTCP Watcher's Dialog Box)	
TEST      198.137.231.151 (their computer)    198.137.231.???* (mine)
----      --------------------------------    -----------------------
ICMP PING    successful test                    no response
UDP ECHO     no response                        successful test
TCP ECHO     no response                        successful test
DNS          no response                        no response
                                         *??? means I entered the IP
                                         address assigned by the server

I have no idea why the ECHO tests would only work with the IP 
address assigned to my computer by the server.  And actually I 
have only a vague notion of what these tests do.  But I think 
these results mean that my system is connected to the system at NW 
Nexus and that SLIP is functioning (at least partly).  After 
running a couple of tests, the MacTCP Watcher Info box reflects 
some of the traffic going back and forth.  I checked the TCP 
Statistics in Versaterm AdminSLIP too, and those numbers also 
indicated that connections, data, and packets were going back and 
forth across the SLIP line.


So, do you have any ideas, suggestions, solutions, etc.  I have 
tried all the suggestions I could find in the TISK FAQ (available 
at ftp.tidbits.com), especially removing the Fax inits the work 
with my modem.  I've even tried completely rebuilding my system.  
Because the PING test works, I'm beginning to wonder if the 
problem is at NW Nexus and not with my system.  Lastly, Here's a 
description of my system:

Mac IIci
System 7.0.1 with tune-up

SupraFAXmodem v.32 bis (with Supra's cable, which is supposed to be 
hardware handshaking.  This modem & cable are supposed to work just fine
according to the TISK FAQ.)

MacTCP 2.0.4   (updated from 2.0.2)
VersaTerm AdminSLIP 1.0.7
VersaTerm ControlSLIP 1.0.5
VersaTerm SLIP Extension 1.0.8
	(all these came in the Versaterm 5.0.1 update)

Thanks in advance for any help,
Autumn Blanchard (and Walter Clinton)
msbat@u.washington.edu

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 18:56:03 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing

In article <MISCHLER.94Jan12000224@norman.li.Cubic.COM>
Dave.Mischler@Cubic.COM writes: 
    
Dave,

    I get the feeling that the restriction on all zeroes and all ones
    subnets stated in RFC 950 should be eliminated with Classless
    Inter-Domain Routing addressing rules, because it seems that it is at
    best meaningless and probably harmful.  I have not seen this
    explicitly stated, though.
    
Would you settle for relaxing it and not eliminating it?

    Can anyone provide an authoritative answer, and/or a pointer to a
    reference that discusses this matter?
    
Yes, you are correct.  If the router is trying to be classless, it must NOT
enforce the all zeroes or all ones subnets rules.  However, it's not clear
that the rule should be eliminated.  If the router is used in a classful
environment, the all zeroes subnet can present serious confusion.  So....
you need to configure the router with "ip subnet-zero" if you're in a
classless environment.

    Can anyone discuss real-world experience using cisco routers in the kind
    of addressing scheme described above [I have 9.1(4), 9.1(5), and 9.1(6)]?
    
Try 9.1(7) or later, where we allow the all ones subnet.

Tony

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 19:19:42 GMT
From:      "Dave Langlais" <ddl@twg.com>
To:        comp.protocols.tcp-ip
Subject:   Re:  Contacting Wollongong on the Internet

In article comp.protocols.tcp-ip:19515, Kent@exodis.reuters.com.sq(kent) writes:

        "I am looking for any sites or books that has write-ups on
        Wollongong TCP/IP. Is there any way to contact Wollongong Sales
        representatives in the net? 
        Any Reply will be greatly appreciated.
        Kent"

Kent,

The Wollongong Group, Inc. can be contacted on the Internet in a couple of ways.

Sales at Wollongong's e-mail address:   sales@twg.com
Support at Wollongong's e-mail address: support@twg.com
Telephone:    US  (415) 962-7200 (sales number)

European Office in Netherlands

WOLLONGONG B.V.
WEGALAAN 46
2132 JC  HOOFDDORP     
THE NETHERLANDS

P.O. BOX  3107
2130 KC HOOFDDORP

TEL       +31-(0)2503 - 24142
FAX      +31-(0)2503 - 52099

If you have any problem getting responses from the above.  My email is ddl@twg.com.

Thanks for your interest.

Dave Langlais
VP, Marketing
The Wollongong Group, Inc.


-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 19:33:43 GMT
From:      bmah@propaganda.cs.berkeley.edu (Bruce A. Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multi Cast

Carsten Krebs writes:
> Hi,
> 
> I have to report about IP Multi Cast and I'm searching for examples 
> or references to books explaining IP Multi Cast.
> Does anybody know something about it ?
> 
> 	Bye,
> -- 
> Carsten Krebs, Pfalzburger Str. 49, 10717 Berlin (Germany), Tel: 861 86 52
> cake@cs.tu-berlin.de or vision@zelator.in-berlin.de

For starters, you could try the MBONE FAQ, available by anonymous FTP as
venera.isi.edu:mbone/faq.txt.  Besides information on the MBONE,
there's also pointers to various other documents.

Also take a look at RFC 1112.

Bruce.
--
------------------------------------------------------------------------------
Bruce A. Mah		   Graduate Student	       bmah@tenet.Berkeley.EDU
		      Computer Science Division
		  University of California, Berkeley

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 19:33:55 GMT
From:      sextant@netcom.com (Sextant Group)
To:        comp.protocols.tcp-ip
Subject:   Subnetting

 Dc> I understand that if I use a subnet address of 255.255.192.0 that I
 Dc> would have  2 subnets allowed and about 16,000 host available. When I
 Dc> assign an IP address  (using the subnet 255.255.192.0), what is the
 Dc> numerical range definition  allowed in the 3rd octet? EXAMPLE: If I use
 Dc> a subnet 255.255.255.0,  any  number(a range of 0-255) I use in the
 Dc> IP's 3rd octet would be a subnetwork. 

It's pretty easy to figure out. I'll detail it, so that you can apply
the same to other subnets later.

255.255.192.0 is in fact 11111111.11111111.11000000.00000000

The first two bits in the third octet signify the network portion -
therefore if you had a class B address of 140.140 then you could assign
two networks below it, as you noted. The two bits allow four (4)
different configurations ...  00   01   10   11

00 and 11 are reserved for use as network and broadcast addresses, as
you know as well.

This leaves six bits available for host portions (within the third
octect). Binary conversion thus renders us that six bits provide us with
numbers between 0 and 63. Thus rendered

Network 00: 0-63          <-reserved
Network 01: 64-127
Network 10: 128-191
Network 11: 192-255       <-reserved

Thus a network mask of 255.255.255.192 allows for two networks,
140.140.140.64 and 140.140.140.128, with host addresses
65-126 and 129-190.

Of course, any dependant octects are wide open. In your case, network
mask 255.255.192.0 allows 140.140.[ 65-126 ] || [ 129-190 ].[ 0-255 ]

Sorry if this just made things more confusing.
--- Blue Wave/QWK v2.10
                                                                                           

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 19:34:10 GMT
From:      sextant@netcom.com (Sextant Group)
To:        comp.protocols.tcp-ip
Subject:   Building a firewall

 Zo> I have a small TCP network of 50 or so Unix platforms that I would
 Zo> like to bridge to my campus WAN, which is on the internet. The catch is
                    ..           ..            ..
 Zo> I understand that this would be called a "firewall" and that many
 Zo> companies use such a set up to isolate their networks from intrusion. I
 Zo> am looking for references detailing how something like this is put
 Zo> together.  
 Zo> At the least, I would like to enable the one machine with the two
 Zo> interfaces to act on both of my networks. But I am uncertain how to
 Zo> direct the machine to treat one interface differently from the other.
 Zo> All of my references on networking seem to assume a single network
 Zo> interface.  
 Zo> Are there references or an FAQ that address this issue? 


First of all, you can't create a firewall with a bridge. You have to
route. A bridge passes everything regardless - it doesn't examine or
verify packets. A router can make intelligent choices and disallow
transactions.

The easiest method is to put two cards into a unix box and kill routed.
Since this box doesn't route packets, they will have to telnet to this
box and do their operations from there. By making access extremely
limited on that system, it'll stop most things.

That's really just the tip of the iceberg for security, but it is the
first necessary measure.

--- Blue Wave/QWK v2.10
                                                                                                                                

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 19:34:23 GMT
From:      sextant@netcom.com (Sextant Group)
To:        comp.protocols.tcp-ip
Subject:   Cidr & variable netmask i

 Da> For example, I wish to subnet part of network
 Da> 198.65.56.0/255.255.248.0 with a mask of 255.255.255.192.  Under the
 Da> RFC 950 rules 198.65.57.0/255.255.255.192 looks like a subnet of a
 Da> class C network with all zeroes in the 2-bit subnet field, and it is
 Da> therefore unusable.  In fact, half the address space in the network
 Da> block would become unusable if this netmask was used.

Not sure what you're trying to do. First of all, 248 isn't a valid
subnet mask. I'll assume you mean 240.

Second of all, yes, subnetting by 255.255.255.192 gives you two unusable
subnets (00 and 11) which occupy addresses 0-63 and 192-255. So you do
lose half your address space - subnetting does that to you, and there's
no way around it. Subnetting is useful for creating lots of small
networks, and useless for allowing most hosts access.

--- Blue Wave/QWK v2.10
                        

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 20:06:04 GMT
From:      ssinlk@solsys.com (Neil L. Kleeman)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Need help w/ Versaterm SLIP, MacTCP, etc.

In Article <2h1ecg$de6@news.u.washington.edu>, msbat@u.washington.edu
(Autumn Blanchard) wrote:
>
>I need some help getting MacTCP and Versaterm Adminslip, and my 
>SLIP account working.  I just bought The Internet Start Kit for 
>Mac (TISK) and I'm having problems with my new SLIP account at NW 
>Nexus.
>.....

Well maybe two suggestions:

1) You might need a gateway defined in AdminSLIP.

2) Make sure that you have a h/w modem cable.

If all that doesn't work - try contacting the VersaTerm folks. They have
been real helpful with several different configurations.
-----------------------------------------------------------------------------
Neil L. Kleeman, President                        Internet: ssinlk@solsys.com   
Solution Systems Incorporated                        Voice:    (610) 668-4620
114 Forrest Avenue                                     Fax:    (610) 668-2157
Narberth, PA 19072

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 20:32:17 GMT
From:      gthaker@atl.ge.com (Gautam H. Thaker)
To:        comp.protocols.tcp-ip
Subject:   UDP on *strictly* unidirectional data link layer??


A while ago I asked about sending UDP/IP on strictly unidirectional
link. Two readers responded with positive news that this can work as far as
IP is concerned.  However, after further investigations I am not sure what
datalink layer will work for us. HDLC (and its variants PPP, SLIP) etc. all
seem to bidirectional Data Link Layer protocols. THey at least do some
handshake to get established. This seems rather bad. Can any provide hints
as to what might be a good data link layer protocol for strictly one
directional channel? The actual channel is a oneway satellite link.

Thanks in advance.

Gautam
--
Gautam H. Thaker (gthaker@atl.ge.com) 609-866-6412 (fax x6397. Dialcom 8-777)
Martin Adv. Tech. Lab., MS 145-2; Route 38; Moorestown, NJ 08057. 767-4396 (H)

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 20:52:36 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing


In article <MISCHLER.94Jan12000224@norman.li.Cubic.COM>, 
Dave.Mischler@Cubic.COM writes:

|I get the feeling that the restriction on all zeroes and all ones
|subnets stated in RFC 950 should be eliminated with Classless
|Inter-Domain Routing addressing rules, because it seems that it is at
|best meaningless and probably harmful.  I have not seen this
|explicitly stated, though.
|
|For example, I wish to subnet part of network 198.65.56.0/255.255.248.0
|with a mask of 255.255.255.192.  Under the RFC 950 rules
|198.65.57.0/255.255.255.192 looks like a subnet of a class C network with
|all zeroes in the 2-bit subnet field, and it is therefore unusable.  In
|fact, half the address space in the network block would become unusable
|if this netmask was used.

Boy, I couldn't agree more.  It really is high time that the RFC 950
restriction on all-zeroes/all-ones subnets be lifted.

Back in the good ol' days, when class B networks were freely available
for the asking, giving up two subnets per network was an insignificant
matter.  If you have 256 subnets available (via "standard" 255.255.255.0 
subnetting), giving up two subnets represents a loss of less than 1% of
your addressing space. 

Nowadays, however, you can't hardly get anything but class C networks.
If you subnet a class C network with a 255.255.255.128, you lose 100%
of your address space.  With 255.255.255.192, you lose 50%.  With
255.255.255.224 you lose 25% - and at that point, you're getting a 
pathetic 29 hosts per subnet (32 less all-0's, all-1's, and default
route.)

The alleged problem with using the all-0's and all-1's subnets is 
the difficulty in distinguishing between the "network itself" 
designation for the subnet vs. the whole network, and between the
broadcast address for the subnet vs. for the whole network.

For example, if network 128.196.0.0 is subnetted with a 255.255.255.0
mask, then if we have a subnet 128.196.0, then it will be designated
in routing tables as 128.196.0.0.  But how is this to be distinguished
from the designation for the whole network itself, 128.196.0.0?

I would say: 

If a given host/router is capable of understanding a single subnet mask
per network, then:
If it has a subnet mask of 255.255.255.0 in effect for network 
128.196.0.0, then routing info for "128.196.0.0" refers to the subnet
128.196.0.
If it has NO subnet mask (i.e. a mask of 255.255.0.0) in effect,
then routing info for "128.196.0.0" refers to the whole network
128.196.0.0

If the host/route is capable of understanding variable-length masks
per network, then:
If the routing info is advertised as "128.196.0.0 255.255.255.0",
then it is treated as being for the subnet 128.196.0.
If the routing info is for "128.196.0.0 255.255.0.0", then it is 
treated as being for the whole network 128.196.0.0.
If the routing info lacks a mask, then deal with it as the 
fixed-length mask host did.

Therefore, I don't think there's any ambiguity in routing info for
subnet 0.

On the broadcast side, it is asserted that we have a problem 
distinguishing between a broadcast sent to "128.196.255.255", an 
"all-subnets directed broadcast" tonetwork 128.196.0.0, and one 
sent to "128.196.255.255", a "subnet directed broadcast" to 
subnet 128.196.0.  (Broadcast taxonomy courtesy RFC 1122, 3.3.6.)

In fact, this *IS*, as far as I can figure, an insoluble ambiguity.
But is this a problem in practice?  I don't think so.

In reality, hosts are not configured to send out broadcasts to 
various and sundry different possible broadcast addresses, but to
a single broadcast address.  And that broadcast SHOULD BE the
limited broadcast 255.255.255.255.  (RFC 1122.)

In practice, I am not aware of ANY production use of directed
broadcasts.  Hosts, esp. BSD based ones, typically use the subnet
directed broadcast to signify a broadcast to their local subnet,
but they could accomplish the same effect with greater ease and
less likelihood of error by using the preferred limited broadcast.
Given the fact that it is permissible (and, indeed, common) for IP 
routers to block the delivery of directed broadcasts (RFC 1009, 4.4;
RFC 1122, 3.2.1.3), and that many hosts IP's refuse to emit off-net 
directed broadcasts, I sincerely doubt that there is significant 
value to worrying about continuing to support the various flavors 
of directed broadcasts.

Therefore, I'd say that hosts should deal with the potentially
ambiguous broadcasts thus:

Given network 128.196.0.0, and mask 255.255.255.0, then:
If a host is on subnet 128.196.255, and it sees a broadcast 
directed for 128.196.255.255, it should respond.
If the host is on some other subnet of 128.196.0.0, and it
sees a broadcast directed for 128.196.255.255, it should 
respond (required by RFC 1122, 3.3.6.)  

This means that the gateway connecting subnet 128.196.255
SHOULD be configured so as not to forward the (apparent) all-subnets
directed broadcast.

But the general solution to this broadcast ambiguity problem is for
everyone just to use the limited (all 1's) broadcast, and be done
with it.

So, in any case, I must say that I DON'T see any solid reason for 
perpetuating the restriction on all-0's and all-1's subnets.  I'd
like to hear others' arguments if any.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 21:12:54 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing

In article <2h1nuk$b40@organpipe.uug.arizona.edu> Leonard@Arizona.EDU writes:
    
    For example, if network 128.196.0.0 is subnetted with a 255.255.255.0
    mask, then if we have a subnet 128.196.0, then it will be designated
    in routing tables as 128.196.0.0.  But how is this to be distinguished
    from the designation for the whole network itself, 128.196.0.0?
    
	[lotsa stuff...]

    Therefore, I don't think there's any ambiguity in routing info for
    subnet 0.

As I mentioned in my previous post, it's not hte hardware, it's the
protocols in use.  The ambiguity exists for classful routing protocols.
    
    On the broadcast side, it is asserted that we have a problem 
    distinguishing between a broadcast sent to "128.196.255.255", an 
    "all-subnets directed broadcast" tonetwork 128.196.0.0, and one 
    sent to "128.196.255.255", a "subnet directed broadcast" to 
    subnet 128.196.0.  (Broadcast taxonomy courtesy RFC 1122, 3.3.6.)
    
    In fact, this *IS*, as far as I can figure, an insoluble ambiguity.
    But is this a problem in practice?  I don't think so.
    
We could indeed relax the restriction to avoid just the particular host
address 128.196.255.255.

    In practice, I am not aware of ANY production use of directed
    broadcasts.  

Ah...  there are _many_.  There are fewer uses of the all-subnets
broadcast.

    So, in any case, I must say that I DON'T see any solid reason for 
    perpetuating the restriction on all-0's and all-1's subnets.  I'd
    like to hear others' arguments if any.
    
What should a router running RIP(v1) hearing an announcement of 128.196.0.0
over a 128.196.0.0 subnet do?  What about over an unnumbered point to point
link?  This is still ambiguous....  Is the sender telling you about the all
zero's subnet?  Or is it a network summary route?

Result: it's gotta be a knob.  Tell the router if you want CIDR mode or
not...

Tony

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 21:23:08 GMT
From:      rwpratt@novell.com (Robert Pratt)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers

In article <2050@seqp4.sequoia.com> king@CS1sequoia.com (King) writes:
>Can anyone recommend a reasonably priced Sniffer that will break
>down TCP/IP packets and give error stats like runts and crc errors.
>Jack

   Well, I would never use the term Sniffer generically to refer to network
analyzers.  Not because its a TM of Network General, but more because I
just don't like them :-)
   Depending on what you think a reasonable price is, below are a variety
of alternatives, with the one I work on listed first.  Of course, its
the best :-)

   LANalyzer for Windows, from Novell.  software only, supports Ethernet
and Token Ring using ODI drivers, Windows based, so very easy to use,
especially for packet capture and decoding compared to DOS programs.  Decodes
Appletalk, TCP/IP, and all NetWare protocols.  Costs $1495 list, available
from your favourite Novell reseller

   Ethload.  public domain (or shareware, anyway its FTPable) analyzer.
Software only, DOS based.  Runs on top of ODI or packet drivers (and maybe
NDIS, I can't remember).  Don't know how good it is, but since its FTPable
probably worth trying if you want to cut costs.  Try archie for the FTP site,
'cause I can't remember.

   LANWatch, from FTP Software.  DOS based, TCP/IP oriented, also
in the ~$1000 range.

   LAN Decoder, from Triticom.  DOS based, wide range of protocol decodes,
also around $1000.  Triticom's decodes are also available as an
add-on pack of decodes for LANalyzer for Windows.

   LANSight (or NetSight, the name seems to change regularly) from Intel.
Also in the 1 to 2K price range, also DOS based.  don't know much about it.

  Basically, you have a wide range of choices, or at least a few :-), for
DOS-based software only analyzers, including at least one freely available
one, and LANalyzer for Windows is currently the only choice if you need
a Windows interface.  I'd suggest finding a reseller who can demo at least
a couple of the products to you and pick the one best suited to your
particular needs, although of course if you are going to buy one sight unseen
you should buy LANalyzer for Windows :-)

Bob





Bob Pratt                               | voice     : (408) 473-8274
Novell, Inc.                            | Fax       : (408) 435-1706
2180 Fortune Drive, San Jose, Ca. 95131 | Internet  : rpratt@Novell.com
Disclaimer:  I do not speak for Novell in any way, shape, or form.
"Mustrum Ridcully did a lot for rare species. For one thing, he kept them
rare." -- Terry Pratchett, _Lords and Ladies_

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 21:37:13 GMT
From:      andy@barley.dun.nielsen.com (Andrew Wilcox)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router


   atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

   eel@auspost.com.au (Elena Leong) writes:
   >Can anyone illuminate the good and bad bits of Wellfleet, Cisco and Retix
   >routers - ie too difficult/easy to configure, flexible/inflexible, 
   >compatibility, etc.

   WellFleet reportedly has a fairly hostile
   console interface (the router operator must really have SNMP commands
   memorised).  

This is only for the technician line interface, or TLI.  After just a
few commands, you can jump to the glitzy motif or MS-windows
interface.  So you don't have to mess with TLI very much.  However, I
find the glitzy interface a _royal_ pain to use.  You can't look at a
group of interfaces at once, and it takes serveral mouse operation to
get to commonly wanted information.  And it hangs my window system
pretty consistently.  In this department, the Cisco is the clear
winner with the plain-old text command-line interface.  Wellfleet will
talk this tool up to pretty lofty heights, so caveat emptor.

   I wouldn't let Cisco talk me into using IGRP (their
   proprietary routing protocol) because it limits my future hardware
   choices.  Choosing BGP3 and OSPF as one's routing protocols is a safe
   choice for now and shouldn't limit one's ability to pick different
   router vendors in the future.

Excellent advice.

   >We are running Sparc10s, SunOS4.1.3, TCP/IP, PPP, FTP, UUCP, RCMD, RLOGIN, etc

     If using PPP, then you definitely want to make sure that your
   routers will support PPP.  Otherwise you look like a "normal" user.

The current Wellfleet software for their upper end boxes (B[LC]N series) 
does NOT support PPP.  Their older software did - go figure.


Andy


-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 09:41:38 +0800
From:      peter@ncrpda.curtin.edu.au (Peter N Lewis)
To:        comp.os.os2.networking,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: TCP/IP for OS/2 2.0 Bug in FTPd?

rer3@quads.uchicago.edu (Rich Robbins) writes:

>While using Fetch on my macintosh to access files on a PC Clone
>running OS/2 2.1 and the FTP server included in IBM's TCP/IP 2.0 for
>OS/2, I noticed that subdirectories are not displayed in the Fetch
 
>FTP session.  It seems that the OS/2 TCP/IP implementation of "ls"
>results in a file list without subdirectories and the implementation
>of "dir" results in a file list including subdirectories.  What is the
>"correct" behavior for an implementation of an FTP server?  Can I

Ahh, now there is a deep question!  The commands are actually NLST 
and LIST.  And the "correct" behaviour is dubious.  According to the
proper FTP specs, the NLST (name list) command should not return
the names of directories.  It would seem that IBM's OS/2 server does this.
Unfortunately, that makes it the *only* server on the planet that does this.
So as you see, "correct' becomes a relative term.  However, I would 
have thought that Fetch would only use the LIST command, and interpret
that, so I assume that its probably just a slight variation of the LIST
output (which is unspecified by the FTP protocol, which has proved to
be an extreemly stupid decision).

>alter the behavior of the IBM program?  Is this an ambiguity in a
>specification, a bug in the IBM software or a shortcoming of Fetch?

If you send me the IP of an IBM OS/2 server on the net, I'll check it 
out.
   Peter.
-- 
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 23:11:58 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting

In article <dchirico.2.000EABEB@usr.com> dchirico@usr.com (David Chirico) writes:
>I understand that if I use a subnet address of 255.255.192.0 that I would have 
      ^^^^^^^ I assume mask was meant.
>2 subnets allowed and about 16,000 host available. When I assign an IP address 
     ^^^^^^ If the primary net is Class B
>(using the subnet 255.255.192.0), what is the numerical range definition 
>allowed in the 3rd octet? EXAMPLE: If I use a subnet 255.255.255.0,  any 
>number(a range of 0-255) I use in the IP's 3rd octet would be a subnetwork.
>
>DChirico@usr.com , 708-933-5743

Remember that the "dotted decimal" format is really just representation of
a 32 bit binary number.  This number is composed of 3 groups of bit fields,
net-part (8, 16 or 24 bits ignoring Classes D, E), subnet-part (0 or more
bits), and host-part (whatever is left over, min of 2 bits).  Also, the
bits in the host-part and the subnet-part should never be all 0s or all 1s.

Convert your dotted decimal network number and netmask to binary fields,
then assign subnet and host parts.  Finally convert back to dotted decimal.

Dotted decimal works fine when all fields end on 8 bit boundaries, but
make thing confusing for different subnet alignments.

Once you get familiar with this you can probably deal in just the dotted
decimal format.

Art


-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 23:35:05 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??

In article <GTHAKER.94Jan12153217@trantor.atl.ge.com> gthaker@atl.ge.com
(Gautam H. Thaker) writes: 
    
    A while ago I asked about sending UDP/IP on strictly unidirectional
    link. Two readers responded with positive news that this can work as far as
    IP is concerned.  However, after further investigations I am not sure what
    datalink layer will work for us. HDLC (and its variants PPP, SLIP) etc. all
    seem to bidirectional Data Link Layer protocols. THey at least do some
    handshake to get established. This seems rather bad. Can any provide hints
    as to what might be a good data link layer protocol for strictly one
    directional channel? The actual channel is a oneway satellite link.
    
HDLC (at least as used by cisco) is a unidirectional protocol.  It's the
keepalive protocol on top of HDLC that is bidirectional.  You would want to
disable the keepalive protocol and it should work fine on a satellite link.

Tony

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 23:44:33 GMT
From:      mk@tfs.com (Mike King)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

In article <CJIpJv.Cz8@inesc.pt>, Luis M. Delgado <lmd@avila> wrote:

>mk@tfs.com (Mike King) writes:
>: In article <CJExn6.8o0@inesc.pt>, Luis M. Delgado <lmd@avila> wrote:
>: >
>: >Did anybody succeded using The Compuserve Information Manager over Telnet to
>: >CIS ?
>: >
>: >
>: >I'm having many troubles. I believe, althought I'm not sure that hermes
>: >limits communications to 7 bits, because I usied an Telnet 8-bit connection
>: >to hermes, and I still can't get CIM to work with it.
>: 
>: Don't forget the link from hermes.merit.edu to CI$ is through SprintNet.
>: Another 7-bit connection....
>: 
>
>Then the conclusion should be: "There is no turnaround." ? 
>and "No way for CIM over hermes.merit.edu" ?
>
>Or is there some other way ?

Well, I won't be so presumptuous as to say, "There is none," but I'm not
aware of any.  Since [Win|Dos]Cim uses the CI$ B+ protocol for all data
transfers once the session is established, it needs an 8-bit path.  To
the best of my knowledge, SprintNet is a 7-bit pathway (although that
may have changed since I used their network).

However, remember that *Cim was developed by CI$ as a means to access their
network over direct-dial lines, and also remember that the hermes.merit.edu
connection is officially not supported by CI$.

Finally, realize that the path you're taking
(telnet[over various networks]<->merit<->SprintNet<->CI$) is a very
tortuous path to leave your machine and arrive at the CI$ hosts.  Lots of
individual packet networks along the way.  Since the B+ protocol is a
full-duplex protocol, timing of ACK/NAK packets is significant.

Have you tried a dial-up SprintNet connection at your end first, to see
if you can use *Cim on it?  That would allow you to see if SprintNet is
indeed the problem.

Mike    mk@tfs.com     Speaking for myself only....


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 00:15:29 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers

In article <1994Jan12.212308.25429@novell.com>,
Robert Pratt <rwpratt@novell.com> wrote:
>In article <2050@seqp4.sequoia.com> king@CS1sequoia.com (King) writes:
>>Can anyone recommend a reasonably priced Sniffer that will break
>>down TCP/IP packets and give error stats like runts and crc errors.
>>Jack
>
>   Well, I would never use the term Sniffer generically to refer to network
>analyzers.  Not because its a TM of Network General, but more because I
>just don't like them :-)
>   Depending on what you think a reasonable price is, below are a variety
>of alternatives, with the one I work on listed first.  Of course, its
>the best :-)
>

You missed (at least) one.  We have a product called PacketView that can
capture and decode network traffic on Ethernet, token-ring, ARCNET and
FDDI networks for only $299.

>
>  Basically, you have a wide range of choices, or at least a few :-), for
>DOS-based software only analyzers, including at least one freely available
>one, and LANalyzer for Windows is currently the only choice if you need
>a Windows interface.  I'd suggest finding a reseller who can demo at least
>a couple of the products to you and pick the one best suited to your
>particular needs, although of course if you are going to buy one sight unseen
>you should buy LANalyzer for Windows :-)

If you want to try a "live" demo of PacketView, contact me for details on how
to get the demo from our BBS or the Internet.

>
>Bob Pratt                               | voice     : (408) 473-8274
>Novell, Inc.                            | Fax       : (408) 435-1706
>2180 Fortune Drive, San Jose, Ca. 95131 | Internet  : rpratt@Novell.com

Sincerely,

Patrick Klos
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
============================================================================

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 01:24:30 GMT
From:      leendert@cs.vu.nl (Leendert van Doorn)
To:        comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   SVR4 ioctls: SIOCSLGETREQ & SIOCSLSTAT

I want to find out what the SIOCSLGETREQ & SIOCSLSTAT ioctl's are
for in SVR4's (Lachman) TCP/IP implementation. The source seems to
imply some kind of switched route mechanism (the documentation is
non-existant in this area). Any pointers, or better example programs
that make use of this feature?

	Leendert
-- 
Leendert van Doorn 			   		<leendert@cs.vu.nl>
Vrije Universiteit / Dept. of Math. & Comp. Sci.	+31 20 5484477
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 02:02:25 GMT
From:      beshir@miller.cs.uwm.edu (Abubaker Ali  Ibrahim)
To:        comp.protocols.tcp-ip
Subject:   Help need packet-drv

Hi, I am trying to install the NCSA package and couldn/t
find driver for IBM(protean card) , where can I ftp?
e-mail please


-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 14:02:52 -0700
From:      wilsonj@agcs.com (Jay Wilson)
To:        comp.protocols.tcp-ip
Subject:   SLIP driver for NDIS

Does anyone know of a SLIP drive that will "slip" under the
Microsoft NDIS stack.  I would like to setup a Netbios/IP
connection over SLIP.

I have this working today.

    ------------
    |  Netbios |
 ------------
    |  TCP     |
 ------------
    |  NDIS    |
 ------------
    | 3cDriver |
    ------------

I want this to work:

    ------------
    |  Netbios |
 ------------
    |  TCP     |
 ------------
    |  NDIS    |
 ------------
    |  SLIP    |
    ------------
                    
Thanks
-- 
Jay Wilson ----  AG Communication Systems, Phoenix, AZ
UUCP    : {ncar!noao!enuucp | att}!gtephx!wilsonj
INTERNET: wilsonj@agcs.com
Other   : voice (602) 581-4496   fax (602) 581-4967

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 03:29:41 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing

In article <MISCHLER.94Jan12000224@norman.li.Cubic.COM>, Dave.Mischler@Cubic.COM writes:

| I get the feeling that the restriction on all zeroes and all ones
| subnets stated in RFC 950 should be eliminated with Classless
| Inter-Domain Routing addressing rules, because it seems that it is at
| best meaningless and probably harmful.

Yes, and the restrictions on host & net parts as well.  Even without
CIDR, the use of variable netmasks can create situations where valid
addresses ``look'' invalid from certain hosts.

| For example, I wish to subnet part of network 198.65.56.0/255.255.248.0
| with a mask of 255.255.255.192.  Under the RFC 950 rules
| 198.65.57.0/255.255.255.192 looks like a subnet of a class C network with
| all zeroes in the 2-bit subnet field, and it is therefore unusable.  In
| fact, half the address space in the network block would become unusable
| if this netmask was used.

Or consider an ordinary class B net 128.1 with a subnet 255.255.255.0
in some places and 255.255.255.240 in others.  Host 128.1.1.128 on a
net with mask 255.255.255.0 looks invalid from host 128.1.2.1 on
a net with mask 255.255.255.240 because the latter concludes that the
host part of the former is all-zero.

The underlying problem is that a given host can't possibly decide whether
a particular ip address is intrinsically ``valid'' without (at least)
full knowledge of the subnet allocations of that ip address's network.
As sites start doing more interesting/creative things with subnet masks,
the various validity tests mandated for ip addresses will get in the way.

(Begin semi-controversial opinion)
I think that, to the extent possible, ip implementations should treat
ip addresses as opaque.  For the moment, we are stuck with recognizing
class A/B/C addresses to set reasonable default netmasks.  We also need
to make routing decisions based on masks configured by the user or a routing
protocol.  Beyond that, unless a very strong case can be made that recognizing
specific parts of addresses can prevent real network failure modes (e.g.,
ARP storms), stacks should not be examining addresses at all.  Especially,
they should not be picking apart addresses destined for distant networks in
the hopes of finding a reason to drop the packet.
(End semi-controversial opinion)

				Dan Lanciani
				ddl@harvard.*

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 03:52:50 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing

In article <2h1nuk$b40@organpipe.uug.arizona.edu>, leonard@telcom.arizona.edu (Aaron Leonard) writes:

| On the broadcast side, it is asserted that we have a problem 
| distinguishing between a broadcast sent to "128.196.255.255", an 
| "all-subnets directed broadcast" tonetwork 128.196.0.0, and one 
| sent to "128.196.255.255", a "subnet directed broadcast" to 
| subnet 128.196.0.  (Broadcast taxonomy courtesy RFC 1122, 3.3.6.)
| 
| In fact, this *IS*, as far as I can figure, an insoluble ambiguity.
| But is this a problem in practice?  I don't think so.
| 
| In reality, hosts are not configured to send out broadcasts to 
| various and sundry different possible broadcast addresses, but to
| a single broadcast address.  And that broadcast SHOULD BE the
| limited broadcast 255.255.255.255.  (RFC 1122.)
| 
| In practice, I am not aware of ANY production use of directed
| broadcasts.

Directed broadcasts can be extremely useful.  In particular, they
make WAN versions of RFC1001/1002 netbios work a lot better. :)
Let's not completely discard this feature just yet.

|Hosts, esp. BSD based ones, typically use the subnet
| directed broadcast to signify a broadcast to their local subnet,
| but they could accomplish the same effect with greater ease and
| less likelihood of error by using the preferred limited broadcast.

As long as they have but one interface...

				Dan Lanciani
				ddl@harvard.*

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 10:21:06
From:      consp06@bingsun2.cc.binghamton.edu (Len Borowski)
To:        comp.protocols.tcp-ip
Subject:   setting things up...

Hi,

	I've got two PCs with ethernet cards, a unix box with one
ethernet adapter,another unix box with two ethernet adapters and lots
of appropiate ethernet wire).  I also have a direct line to our campus
backbone.  I need some advice as to how I can set up a LAN.  The
ethernet line from the campus backbone has been assigned an address of
XXX.XXX.1.183 and we've been told to set up the lan subnet as
XXX.XXX.183.0.  Is there documentation on the net(maybe an RFC or
article) I can access that details how to set up this LAN.  In
particular, I am looking for details as to what gets hooked up to
what, physically.  I know how to route things and set up the subnet
mask, I've done that before(with a token ring and ethernet).  
	I apologize for the skimpy information.  If more details are
needed please email me and I will get the needed info.  Thanx in
advance for any help that is provided.

							_len

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 06:02:22 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??

In article <GTHAKER.94Jan12153217@trantor.atl.ge.com> gthaker@atl.ge.com (Gautam H. Thaker) writes:
>
>A while ago I asked about sending UDP/IP on strictly unidirectional
>link. Two readers responded with positive news that this can work as far as
>IP is concerned.  However, after further investigations I am not sure what
>datalink layer will work for us. HDLC (and its variants PPP, SLIP) etc. all
>seem to bidirectional Data Link Layer protocols. THey at least do some
>handshake to get established. This seems rather bad. Can any provide hints
>as to what might be a good data link layer protocol for strictly one
>directional channel? The actual channel is a oneway satellite link.

SLIP?  Handshake?  Ha!

People often do getty/login chatting before starting a SLIP connection,
but it certainly is not necessary.  

Note also that SLIP has nothing to do with HDLC.  While no doubt someone
somewhere has put encapsulated IP packets al la SLIP and put that into
HDLC frames, it is at best a "specialized need."  The whole idea
of SLIP is to take an IP packet, precede and follow it with a special
byte, convert any instances of that special byte in the IP packet
to something else, and then send the result over an async. serial
line such as an old fashioned 1200 bit/second modem.

Some of us still are still unhappy that async PPP was defined with "async
HDLC framing."  (The PPP handshaking to suppress addr. & cntl and compress
the protocol field should not have been necessary for async.)


Vernon Schryver    vjs@rhyolite.com

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 15:55:26 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Clarkson Packet Drivers

In article <2h3uun$rm7@genesis.ait.psu.edu>, malik@cac.psu.edu (Sohail Malik) writes:
> How does one program the Clarkson Packet drivers to go into
> promiscuous mode so that all ethernet frames are received?
> A colleague and I want to develop software to gather
> LAN statistics.

Call set_rcv_mode and set the receive mode to 6.  Note that a driver may
not necessarily implement all receive modes.

BTW the packet drivers no longer have anything to do with Clarkson University.
They are now maintained by (and you can purchase support from) Crynwr Software.
--
James Harvey   harvey@iupui.edu   IUPUI OIT Technical Support/VMS/Unix/Networks
Disclaimer:  These are my own opinions.  I do not speak for Indiana University.

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 08:28:31 GMT
From:      gadi@fibronics.co.il (Gadi Kizner)
To:        comp.protocols.tcp-ip,comp.sys.m68k
Subject:   TCP for m68k embedded system

> Hi.
>
> I am curious to know if anyone has recommendations for off-the-shelf
> ( or public domain ) package of TCP and TELNET implementation for
> embedded m68K system.
>
> We are using MC68302 integrated multi-protocol processor in
> EDX task switcher environment.
>
> Thanks in advance.
>
> gadi@fibronics.co.il

I am soppy that I said that "I am curious", I NEED a solution.

I have Douglas E. Comers sources of TCP/IP for Xinu operating system.
And the main problem is porting of TCP to a system without a real operating
system. EDX, that I use is very limited.

Any more suggestions?


Following is the summary of recommendations I received.


----- Begin Included Message -----

From cyliax@cs.indiana.edu Wed Jan 12 17:41:46 1994
From: "Ingo Cyliax" <cyliax@cs.indiana.edu>
To: gadi@fibronics.co.il
Subject: Re: TCP for m68k embedded system
Newsgroups: comp.protocols.tcp-ip,comp.sys.m68k
In-Reply-To: <CJIrD8.21I@fibronics.co.il>
Organization: Computer Science, Indiana University
Cc:
Content-Length: 1012
X-Lines: 26
Status: RO

Nothing off-the-shelf, but there is ka9q, which has been ported to
many architectures. Also, you could use the protocol stack from BSD
to implement an TCP/IP stack. The latter would be some work, but it
makes for good compatibility, since the BSD implementation is probably
one of the more reobust and most debugged around.

If this is a commercial application, I can offer you my consulting
services of porting one of the above if you can't find anything off-
the-shelf. I have experience with the 68302 as well as tcp/ip
implementations.

See ya, -ingo


From fredch@quad4.phx.mcd.mot.com Wed Jan 12 23:09:24 1994
From: fredch@quad4.phx.mcd.mot.com (Fred Christiansen)
To: gadi@fibronics.co.il
Subject: Re: TCP for m68k embedded system
Newsgroups: comp.protocols.tcp-ip,comp.sys.m68k
In-Reply-To: <CJIrD8.21I@fibronics.co.il>
Organization: Motorola, 2900 S Diablo Way, Tempe, AZ 85282
Content-Length: 653
X-Lines: 14
Status: RO

In article <CJIrD8.21I@fibronics.co.il> you write:
>I am curious to know if anyone has recommendations for off-the-shelf
>( or public domain ) package of TCP and TELNET implementation for
>embedded m68K system.

Network Research Corp's Fusion might be a possibility.

We support TCP stuff under VMEexec for boards we sell, but I'm not
aware of the 68302 being on any of them, sorry.
--
Fred Christiansen ("Canajun, eh?")               Email: fredch@phx.mcd.mot.com
Disclaimer: I do not speak for Motorola Computer Group       Fax: 602-438-3836
  "Most men will proclaim every one his own goodness: but a faithful man who
     can find?"  Proverbs 20:6


From raquels@uhunix.uhcc.Hawaii.Edu Wed Jan 12 23:49:38 1994
From: raquels@uhunix.uhcc.Hawaii.Edu
To: gadi@fibronics.co.il
Subject: Re: TCP for m68k embedded system
Newsgroups: comp.protocols.tcp-ip,comp.sys.m68k
In-Reply-To: <CJIrD8.21I@fibronics.co.il>
Organization: University of Hawaii
Cc: raquels@uhunix.uhcc.hawaii.edu (Raquel Sanborn)
Content-Length: 1990
X-Lines: 44
Status: RO

In article <CJIrD8.21I@fibronics.co.il> you write:
>Hi.
>
>I am curious to know if anyone has recommendations for off-the-shelf
>( or public domain ) package of TCP and TELNET implementation for
>embedded m68K system.

    I have an Amiga, which uses a 14.2Mhz MC68000 CPU and have a public
domain TCP/IP package called AmiTCP.  Full source, API and Postscript
documentation is available.  Various applications, like ftp, ftpd, telnet,
telnetd, ping, finger, fingerd and such are avaible.  More are being
written every month by various people (including me, who wrote a dial
in script for my CSLIP line).  Source code for the example drivers is
also available.
    AmiTCP is based on NET/BSD source, and includes some bug fixes that
were still in the NET/BSD when the authors got it.  It canbe be gotten
from AmiNET, which is a collection of Amiga FTP sites that mirror each
other.  The U.S.A. sites are ftp.etsu.edu, which is slightly strange
since the CD-ROM has gone down, and ftp.wustl.edu the main AmiNET site.
The directory is "pub/aminet/comm/net", anyway I think you should
beable to poke around it.

>
>We are using MC68302 integrated multi-protocol processor in
>EDX task switcher environment.

    I assume this is not an idle whim, but a real project with real time
and resources allocated for it?  If so, you might want to pick up an
Amiga 1200, roughly $600 in the U.S.A. with hard disk, and the SAS/C
compiler which includes source level debugging and very good optimization.
This would allow testing the changes you might want to do to AmiTCP and
yet also support porting to your MC68302 system.




K. Raquel Sanborn                           |   Computer Programmer/Specialist
raquels@uhunix.uhcc.hawaii.edu              |---------------------------------
raquels@arwen.pbrc.hawaii.edu (AmiTCP only) |<-Note the ref. to Middle Earth
------------------------------------------------------------------------------

From daveh@dhcs.demon.co.uk Thu Jan 13 01:07:12 1994
From: daveh@dhcs.demon.co.uk (Dave Hodgkinson)
Organization: The rfc1122 police
Reply-To: daveh@dhcs.demon.co.uk
To: gadi@fibronics.co.il
Subject: TCP for m68k embedded system
Content-Length: 707
X-Lines: 23
Status: RO

In article <CJIrD8.21I@fibronics.co.il> you write:

>Hi.
>
>I am curious to know if anyone has recommendations for off-the-shelf
>( or public domain ) package of TCP and TELNET implementation for
>embedded m68K system.
>
>We are using MC68302 integrated multi-protocol processor in
>EDX task switcher environment.

I'm using one which was hand crafted in 68k assembler
for an OS called Mirage - we've just gone live in a
power station :-)

I don't know how easy it would be to convert - the assembler
is a bit wierd, and the OS unlike OS/9, psos or whatever.
It might me easier to move your app to Mirage ;-)

Let me know if this is of interest....

--
Dave Hodgkinson - Wizard for hire, rfc1122 enforcer



-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 09:41:56 GMT
From:      lmd@avila (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access

ANDY@MAINE.MAINE.EDU (Andrew T. Robinson) writes:
: From: mk@tfs.com (Mike King)
: >Don't forget the link from hermes.merit.edu to CI$ is through SprintNet.
: >Another 7-bit connection....
: >
: 
: What are the access charges for telnetting to CIS via hermes?
: 
: Andy
: 
: PS -- please reply directly to ANDY@MAINE.MAINE.EDU

--
Andrew:

I don't have the precise charges, but its something like this:

	$US 11.70 - During USA Prime Time
	$US 01.00 - During USA non-prime time.

Maybe while telneting to hermes, you will get further info, by issueing the 
help command.

The time periods, are related to the USA used time meridean, which right now
don't remember the name. 


Best Regards,
----------------
Luis Delgado,
INESC-CCAE
e-mail: lmd@inesc.pt

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 13:18:49 GMT
From:      jccw@fred.mitre.org (John C. C. White)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??

You can certainly run IP in one direction only (although ICMP may try to send
some packets back if there are errors). We do it using either SLIP or HDLC
framing (no HDLC protocol, just the framing) depending on whether we want
to run async or synchronous. You may need something a little smarter than
UDP, however, unless you are just sending independent packets with no harm
done if one is occasionally lost.

-John White-
jccw@mitre.org


-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 14:20:15 GMT
From:      mattp@apertus.com (Matt Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over 802.3/802.2

In article <1994Jan10.225203.22548@aqm.com> rturner@aqm.com writes:
>
>Does anyone on the group know where I might find the "standard" way to encode
>and decode link-layer 802.3 information for IP packets?
>
>I'm aware that the majority of the world uses Enet V2 formatted packets, but I
>have recently been asked to provide TCP/IP support over 802.3 (with 802.2
>SNAP IDs as well).  Is/Are there RFC information relating to this?
>
>
I too would be interested in this information.  I am using Unixware
(SVR4.2) with a Lachmann's TCP/IP stack and SMC's WD driver.  I have
been told that I need to write a STREAMS module to fit between the stack
and the wd driver.  That is, in the strcf file I would need to have the
stack open my module and then I would open the wd driver.  Then I would
issue a DLPI bind request to the wd driver to use 802.3 and 802.2 SNAP
rather than Ethernet 2.  I am not sure what element(s) should set nor
am I sure how to encode/decode the 802.3 data.  In addition to RFC's, is
there any example code to demonstrate how this might be done?


Matt

Matt Perry
mattp@mattp.apertus.com


-- 
Matt Perry
mattp@mattp.apertus.com

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 14:35:25 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

Don't tell a bumblebee that it can't fly.

Don't tell the people who broadcast and listen to the IETF sessions
over the MBone that it's impossible to carry useful voice or video
across the Internet.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 13:35:01 +0100
From:      mhart@rowan.coventry.ac.uk (M J HART)
To:        comp.protocols.tcp-ip
Subject:   HELP


I have to right an assignment on TCP/IP and know nothing about this protocol,
i need any information on the history of this protocol and the ussaly sort of
pros and cons of this protocol over the ISO model

I would be really greatfull if anybody can help me via Email.
-- 
************************* Barclays Bank: An institution where you can borrow
*      M A T T          * money if you present sufficient evidence that you 
* mhart@uk.ac.cov.rowan * don't need it!!!!!!!!
*************************

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 16:00:18 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for tcp-ip Gatekeeper TIS

>I am looking for a ftp server where i can find a Gatekeeper fot tcp-ip networks
>called TIS ( like HSC ).

	Are you thinking perhaps of the TIS firewall toolkit? It's a
set of tools for building internet firewalls (or "gatekeepers" if you will).
You can FTP it and its documentation from ftp.tis.com [192.94.214.100] in
pub/firewalls/toolkit

mjr.

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 17:04:23 GMT
From:      malik@cac.psu.edu (Sohail Malik)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Clarkson Packet Drivers

How does one program the Clarkson Packet drivers to go into
promiscuous mode so that all ethernet frames are received?
A colleague and I want to develop software to gather
LAN statistics.

-Sohail

P.S. The ethernet cards we are using are based on 
the National Semiconductor 8390 chip.

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 17:29:26 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Large IP Site Management Tool Wanted

In article <dewayneaCJIuID.158@netcom.com>, dewaynea@netcom.com (Dewayne
Adams) writes:
->
->Does anyone know of a management tool that assists in the administration 
->of the IP addresses and the users? I guess that it should talk and update 
->the Sun NIS+ files (DNS).
->

    What exactly do you mean by admin of IP addresses and users?  If you
    mean dividing up the IP addresses that NIC gave you and keeping track
    of subnetting, etc...I would like to hear of one (Although I am sure
    that somewhere within IBM one exists, I just dont know about it).  If
    you mean a tool to help keep track of users on systems and typical 
    admin stuff, NIS+ should do the trick.  If you want to make it even 
    easier than that, look into the Tivoli product line - they have a series
    of systems management tools.  From what I have seen (and worked with)
    DNS and NIS(+) are not connected.  You would use NIS(+) to distribute
    a local copy of the /etc/hosts file, but DNS would keep track of hosts
    referenced by the /etc/resolv.conf file with its own protocol and 
    processes (bind(1)).  And, lastly, if you want something to monitor your
    new IP network, IBM Networking Systems's NetView product is seemingly
    very robust (I have just played with it, not made it do everything it
    can...)

Hope this helps-

Sean Allen                                        AIX/Sybase Administration
(919)543-6021 Fax 7996                         Planning Acquisition Systems
Internal Zip: D533/B205                       IBM Personal Computer Company
VNET: RTP(SALLEN)                                Research Triangle Park, NC
#include<std_disclaimer.h>                   Internet: allensd@vnet.ibm.com

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 17:52:13 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJIyw6.H7w@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Ran
Atkinson) writes:
->In article <CJHIHr.GsI@sernews.raleigh.ibm.com> allensd@vnet.ibm.com writes:
->
->I gather that you haven't been tracking the IETF/IRTF work on resource
->reservation mechanisms.  I'd suggest you look at the Internet Draft on
->RSVP (draft-braden-rsvp-* I think) as a starting point.
->

   You are correct, I have not followed the referenced draft.  But, all
   all I said, or implied, was that TCP/IP was never meant to carry
   isochronous traffic - and I still think this to be true.  Whether or
   not it can be modified to carry it is not at issue.

->
->Not really.  ATM as currently specified and built can't handle multicast
->efficiently.  
->

   As it is currently specified, the standards committees have not finished
   yet!  As ATM is specified now, class A AAL provides a constant bit-rate -
   very nicely handles isochronous traffic.  Class B AAL provides for variable
   bit rate with a timing relationship between source and destiniation which
   will work well for teleconferencing.
    
   Those classes coupled with 155Mbit/622Mbit starting bandwidth seems to be
   better suited to handle audio and video traffic.  I realize there is a 
   battle going on in the standards committee on where ATM should start, but
   it looks like OC3 will win.

->encoding algorithm one is using).  Ah yes, and I spend most of
->1991-1993 working with ATM so I have some small experience with the
->technology.  ATM has its uses, but it isn't the panacea that it is
->hyped to be.

   Agreed, however, IMHO it shows more promise than TCP/IP.  By the way-
   I am not advocating the dismissal of TCP/IP by any stretch!

Sean Allen                                        AIX/Sybase Administration
(919)543-6021 Fax 7996                         Planning Acquisition Systems
Internal Zip: D533/B205                       IBM Personal Computer Company
VNET: RTP(SALLEN)                                Research Triangle Park, NC
#include<std_disclaimer.h>                   Internet: allensd@vnet.ibm.com

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 18:04:15 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling

In article <2h0qm1$pa2@unidui.uni-duisburg.de> griesser@zeus.uni-duisburg.de writes:
>In article 2gsc1rINNi11@early-bird.think.com, barmar@think.com (Barry Margolin) writes:
>>The long timeouts in TCP/IP's fault recognition mechanisms are there for a
>>reason: they should not be tripped by temporary network problems (such as a
>>dial-on-demand SLIP line hanging up, a network administrator unplugging
>
>That's all pretty useful in a large LAN or a WAN, but one could imagine 
>applications for what setting timeout values to a few seconds is a need.

One could imagine such applications, it's true, but what I can't
imagine is that application being able to tolerate the transport layer
maintaining the timeout.  It strikes me that an application with such
exacting timeout requirements would need to maintain its own timers
instead of overloading some vaguely related transport layer timer to
accommodate the application's secondary purpose.  For one thing, such
an application would presumably need to immediately detect *all* types
of failure including the ones where the transport connection is still
operational.

						don provan
						donp@novell.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 19:06:50 GMT
From:      pgraffmn@world.std.com (Peter a Graffman)
To:        comp.protocols.tcp-ip
Subject:   Source to TNVT220 Emulator


 
We are software developers looking for a way to enhance a telenet vt220 
emulator (TNVT220 on TCP/IP) that runs on a PC in either DOS or windows. We 
wish to add in drivers to the TNVT220 emulator so it can communicate to local 
devices on the PC.  Our specific requirements are that we will be sending HEX 
codes from our host based application to TNVT220 on the PC. Upon receipt of 
the HEX codes, the TNVT220 will call linked in subroutines to communicate via 
software drivers to devices.  
 
Our application is a retail POS application, and has been host based, 
communicating to terminals with configured cash drawers, pole displays etc. We 
would like to utilize integrated DOS based cash registers such as NCR, etc. tied 
in over TCP/IP. These DOS based registers have their own software drivers that 
control cash drawers, pole display printers etc. Our application, being host 
based, sends HEX codes through auxiliary ports off of dumb terminals.  
 
What we are trying to accomplish, is to use a terminal emulator (TNVT220) that 
will capture the HEX codes and translate them to device driver calls on the DOS 
based register to print, open cash drawer etc. 
 
To accomplish this we need to get source code to a TNVT220 emulator under 
DOS (and associated libraries), so that we can link in NCR drivers (these are 
developed in Microsoft C) to operate this DOS based register. 
 
Does any body know where we can get reliable source for a TNVT220 emulator 
to accomplish our goals? We need to run this under Novell's LAN workplace. 
 
Any and all suggestion would be appreciated. 
 
Thanks. 
 
Peter Graffman				pgraffmn@world.std.com 
197 Oak St. 
Natick MA 01760  
Tel:  508-650-1502  
Fax: 508-655-8595

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 19:18:56 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <BOB.94Jan13093519@cowfish.MorningStar.Com>,
bob@MorningStar.Com (Bob Sutterfield) writes:
->
->Don't tell the people who broadcast and listen to the IETF sessions
->over the MBone that it's impossible to carry useful voice or video
->across the Internet.
->

I never did...I have seen those broadcasts, and was impressed.  The word
impossible in our industry is about as dangerous as assume and never!


Sean Allen                                               Programmer/Analyst
(919)543-6021 Fax 7996                         Planning Acquisition Systems
Internal Zip: D533/B205                       IBM Personal Computer Company
VNET: RTP(SALLEN)                                Research Triangle Park, NC
#include<std_disclaimer.h>                   Internet: allensd@vnet.ibm.com

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 94 19:43:23 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <BOB.94Jan13093519@cowfish.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
|> Don't tell a bumblebee that it can't fly.
|> 
|> Don't tell the people who broadcast and listen to the IETF sessions
|> over the MBone that it's impossible to carry useful voice or video
|> across the Internet.
|> --

But you will notice that airplanes don't look like bumblebees.

Not impossible, just not dependable.  You couldn't, for example, depend on
running you PBX's across an IP internet if they had to compete with your general
data traffic.  I think people would be a little upset when their conversation
became garbled by the passing of a large file transfer.  Now, if ONLY the PBX's
were on the net, then you could design it right but that would be trivial and not
particularly useful since what virtually everyone talks about is carrying voice,
video, and data across the same mesh.

I've no hands on with MBONE:  are you saying the quality is good enough to run a
phone system over it?  If not, it is merely an interesting technology trial and
not something that could be considered a productive, sellable service.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 20:34:58 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <DRW.94Jan12204433@euler.mit.edu> drw@euler.mit.edu (Dale R. Worley) writes:
>1) One reason TCP/IP is so simple is that it does not deal with
>resource allocation.

The Internet community is working on adding resource reservation
mechanisms (e.g. RSVP) to IP.  See the Internet Drafts archive near
you for details.


-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 21:06:42 GMT
From:      haydenh@bearriver.com (Hayden Harman)
To:        comp.protocols.tcp-ip
Subject:   BSD Socket Books

I'm looking for a good place to start learning the BSD socket interface. 
Are there any good books/resources anyone can recommend?

Thanks,

-Hayden

-------------------------------------------------------------------------------
Hayden Harman                           
Software Engineer                       
Bear River Associates, Inc.             Voice: 510-644-9400             
P.O. Box 1900                           FAX: 510-644-9778  
Berkeley, CA 94701                      Internet: haydenh@bearriver.com

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 21:44:27 GMT
From:      jeffd@ngc.com (Jeff Douglass)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers

In <1994Jan12.212308.25429@novell.com> rwpratt@novell.com (Robert Pratt) writes:
>In article <2050@seqp4.sequoia.com> king@CS1sequoia.com (King) writes:
>>Can anyone recommend a reasonably priced Sniffer that will break
>>down TCP/IP packets and give error stats like runts and crc errors.
>>Jack
>
>   Well, I would never use the term Sniffer generically to refer to network
>analyzers.  Not because its a TM of Network General, 

Although that's a good reason, too. :-)

>   Depending on what you think a reasonable price is, below are a variety
>of alternatives, with the one I work on listed first.  Of course, its
>the best :-)
[ list deleted ]

Also, there's products by ProTools, H.P., IBM, and a few others.
Oh yeah, I think Network General makes some.  *grin* (see sig for #)
It really does depend on your price/features tradeoff threshold.

[ careful clipping follows ]
>I'd suggest finding a reseller who can demo at least
>a couple of the products to you and pick the one best suited to your
>particular needs, 

To this I agree!

>Bob

Regards,
/Jeff
-- 
If lost, please return to:  JeffD@NGC.COM / uunet!ngc!jeffd
Network General, Menlo Park, CA USA, Voice:(415) 473-2000, FAX:321-0855

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 22:01:52 GMT
From:      davek@melupl (Dave Kennedy)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Old TCP connections in ESTABLISH state

I have an Unix based RPC server that accepts connections from 
MS-Windows clients.  If the client does not properly tear down the 
connection (clnt_destroy), the connection gets left on the Unix box
in the ESTABLISH state (per netstat -a).  

It was suggested to me to turn on SO_KEEPALIVE.  Is this a reasonable 
solution?  The leftover connections are mostly a resource issue.  
Second, how can SO_KEEPALIVE be turned on using RPC.  Should I just 
climb under the RPC covers and setsockopt(SO_KEEPALIVE) on the socket?  

Thanks for your help.
-- 
|   Dave Kennedy             UUCP:   {gatech,emory}!dscatl!melupl!davek    |
|  Voice: 404-409-4575  Internet: davek%melupl.atl.ga.us@mathcs.emory.edu  |

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 01:30:25 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJKxn1.120K@sernews.raleigh.ibm.com> allensd@vnet.ibm.com writes:
>
>   You are correct, I have not followed the referenced draft.  But, all
>   all I said, or implied, was that TCP/IP was never meant to carry
>   isochronous traffic - and I still think this to be true.  Whether or
>   not it can be modified to carry it is not at issue.
> ...

Who sez "TCP/IP was never meant to carry isochronous traffic"?   Besides
the telco guys?

It is not clear what if any modifications to the IP suite are needed.  Of
course, eventually, TCP/IP will be replaced, just like everything else in
the universe, but the continued crying that "you can't possibly do audio
over TCP/IP" or "isochronous traffic is really hard and totally wrong for
datagrams" was boring 10 years ago.

Have you looked at the various picture phones as well as the MBONE?  Can
you honestly say that for the same cost (bandwidth, CPU, whatever) and
performance, one is clearly superior and therefore "TCP must be modified"?

Of course if you're making a PBX or central office switch, you're not
going to pick IP datagrams for moving the voices around.  On the other
hand, no one knows an excellent recipe for "multimedia" (although all of
the currently best recipes use IP).  This talk of "isochronous traffic"
is often political "technology" from people who have never tried digital
pictures over TCP, UDP, ATM, or tight strings, and have no idea which if
any of those protocols are remotely suitable.


Vernon Schryver    vjs@rhyolite.com

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 01:42:51 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <1994Jan13.194323.17392@mmm.mmm.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
> ...
>I've no hands on with MBONE:  are you saying the quality is good enough to run a
>phone system over it?  If not, it is merely an interesting technology trial and
>not something that could be considered a productive, sellable service.

What does a telephone system have to do with the MBONE?
Do you complain that your sports car is a terrible pickup truck?

Multimedia is not the same as a plain ol' telephone signalling.  If it
were, picture phones would not be more than 20 years old and still a
commercial flop.

What's with all of this political technology?  This "it can't possibly
work and so it doesn't work and everyone who is trying it is stupid and
should go get jobs as telco linemen because that's the coming thing"?

There are commercial products that involve cameras, microphones,
CRT's, speakers, and IP.  People are buying the stuff.  Let's hope
those buyers think it is "a productive, sellable service."  I don't
think those products are roaring successes yet, but it's early.


Vernon Schryver    vjs@rhyolite.com

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 94 10:05:10 +1100
From:      lukeh@softtruk.apana.org.au (Luke Howard)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ethernet modem?

In <2gse4s$p1m@gap.cco.caltech.edu> dbikle@cco.caltech.edu (Daniel B. Bikle) writes:
>Hi There,
 
>Is there a product on the market which is a modem with an ethernet
>interface?
 
>Here's how I'd want it to work:
 
>I give the etherModem an IP address via a simple builtin keypad.
 
>I attach the etherModem to my ethernet.
 
>Then, I attach the etherModem to a phone jack via a phone cord.
 
>Then, I fly to Telluride and dial in to the etherModem which would
>allow me to telnet into any machine on the ethernet.
 
>Please let me know if you are aware of such a product.

Telebit make their NetBlazer. I believe this is a high speed
Telebit modem with an Ethernet interface. I'm not sure whether it
works like a terminal server - in that you can dial in and telnet
to a machine on the Ethernet, but you can almost certainly
dial in and connect to any machine with SLIP or PPP.

If you are planning on needing either

o	More than one dialin modem

and/or

o	Dumb terminal rather than SLIP/PPP access

you're probably better getting a terminal server (such as an Annex)
and connecting standard modems to that.


L.

-- 
Luke.Howard@apana.org.au - Si seulement j'avais un SGI, je serais content...

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 14:10:26 -0500
From:      grichard@cis.ohio-state.edu (Golden Richard)
To:        comp.protocols.tcp-ip
Subject:   Improving interactive SLIP performance


Unfortunately I'm a SLIP user rather than a SLIP guru.  Is it possible
to improve interactive response at the expense of non-interactive
things such as ftp?

I have a 14.4k line and I'm usually using telnet with sporadic ftp's.
I wouldn't care if some of the ftp's took longer if only I could
improve the response time in the telnet session (while an ftp is in
progress) a bit.  Are there parameters to tweak which can pull this
off?

Mail responses if you wish and I'll a summary to save a little bandwidth.


Thanks,

--Golden
-- 
Golden Richard III            OSU Dept. of Computer and Information Sciences
grichard@cis.ohio-state.edu (614) 292-0056    "I'm your huckleberry..."  -DH

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 94 14:07:11 CST
From:      wayne@tachyon.com (Wayne Sewell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP vs Netbios/IPX LAN performance

In article <2h6if7$61k@hopper.acm.org>, wkh@ACM.ORG writes:
> Does anyone have hard numbers on TCP vs Netbios/IPX performance in
> a LAN environment?  I've always found TCP adequate for networks of
> Unix boxes.  Now I'm in a PC environment where the locals claim that
> TCP is a WAN protocol and Netbios or IPX are the protocols of choice
> for LAN apps.  Not being a network performance kind of a guy all
> I can do is say, "Gee, TCP/IP always seemed plenty fast to me ..."
> 
> Ward K. Harold		wkh@ACM.org

It's probably a religious issue, i.e. "what I am familiar with is better/faster
than what I am not familiar with."

-- 
==============================================================================
Wayne Sewell                            |INET: wayne@tachyon.com
Tachyon Software Consulting             |UUCP: uupsi!uupsi6!tachyon!wayne
P. O. Box 550937, Dallas TX  75355-0937 |Voice: (214)-553-9760, Fax: -553-0077
=============================================================================
Curly: "I keep tryin' to think, but nuthin' happens!"

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 09:36:22 GMT
From:      mychan3@ie.cuhk.hk (chan man yiu)
To:        comp.protocols.tcp-ip
Subject:   NCF Protocol and Simle reliable UDP?

I think I should post my question here.  If I am wrong, would you please
give me a pointer ?

What's NCS protocol ?  It seems a protocol over UDP to provide a
reliable service.  Is there anybody can give me more info ?

Can you suggest a very simple reliable UDP protocol ?

The problem I am thinking of is to protect integrity of a data block while
sending through TCP/IP.  I have considered TCP connection.  It cannot provide
this. The only thing it can in network error is sending part of the data block.
Therefore, my receiving side can easily run into out-of-syn and it would
wait for ever.  The choice seems to be UDP but it do not guarantee reliable
service.  Help !

Secondly, how can I detect the disconnect event when the TCP connection
is fail.  The manual does not concretely stating how to really detect
this event.  EOF is not enough for me.

Thirdly, how can I detect how many free bytes in the sending buffer so
that I can put a whole block of data if the buffer do has space in order to
avoid blocking ? Are lower watermark and high watermark doing these
thing ?

Suggestions for IBM and UNIX are perfectly welcome.

Thanks a lot in advance ! :)

Cheers,
Man Chan	{B)
NNNN

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 94 15:05:49
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: TCP vs Netbios/IPX LAN performance


Netbios/IPX tends to have smaller "window sizes", allowing a resident driver
to be written that uses less memory, which can be in short supply on a DOS
box.  On a LAN, the resulting behavior isn't bad, but it sucks rocks on a
high-delay WAN.  In that sense, TCP is a WAN protocol, and IPX or NETBIOS is
a LAN protocol.     

Both can perform adequately on a LAN, but the TCP implementation will likely
be much bigger (not that it NEEDS to be, but that is a separate issue!)

BillW
cisco


-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 16:49:43 GMT
From:      wkh@ACM.ORG
To:        comp.protocols.tcp-ip
Subject:   TCP vs Netbios/IPX LAN performance

Does anyone have hard numbers on TCP vs Netbios/IPX performance in
a LAN environment?  I've always found TCP adequate for networks of
Unix boxes.  Now I'm in a PC environment where the locals claim that
TCP is a WAN protocol and Netbios or IPX are the protocols of choice
for LAN apps.  Not being a network performance kind of a guy all
I can do is say, "Gee, TCP/IP always seemed plenty fast to me ..."

... WkH

Ward K. Harold		wkh@ACM.org
MCI Consumer Markets
4115 Freidrich Lane
Austin, TX  78744

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 16:54:27 GMT
From:      klinde@silver.sdsmt.edu (Karen Linde)
To:        comp.protocols.tcp-ip
Subject:   Cu-See-Me

Can someone point me to the source for this video conferencing software  ; 
Cu-See-Me  (all I know is that it's available from Cornell). Also, can you 
give me a general discription of what it is, what it runs on, and how it works?

Thanks,
Karen Linde
South Dakota School of Mines & Technology
klinde@silver.sdsmt.edu

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 17:15:38 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD Socket Books

Hayden Harman (haydenh@bearriver.com) writes:
> I'm looking for a good place to start learning the BSD socket interface. 
> Are there any good books/resources anyone can recommend?

  The best one I know of, hands-down, is W. Richard Stevens' "Unix Network
  Programming".  I consider it required reading in our work group.

  Then study the man pages and experiment on your own.  No documentation
  that I know of fully explains BSD sockets.

-- Ken Mintz

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 18:16:42 GMT
From:      bmah@propaganda.cs.berkeley.edu (Bruce A. Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

Vernon Schryver writes:
> In article <CJKxn1.120K@sernews.raleigh.ibm.com> allensd@vnet.ibm.com writes:
>> 
>> You are correct, I have not followed the referenced draft.  But, all
>> all I said, or implied, was that TCP/IP was never meant to carry
>> isochronous traffic - and I still think this to be true.  Whether or
>> not it can be modified to carry it is not at issue.
>> ...
[part of reply deleted]

> Have you looked at the various picture phones as well as the MBONE?  Can
> you honestly say that for the same cost (bandwidth, CPU, whatever) and
> performance, one is clearly superior and therefore "TCP must be modified"?
[rest of reply deleted]

I think it's important here to distinguish the difference between
using TCP/IP to carry voice and using the Internet protocols to carry
voice.  Note that the MBONE uses UDP/IP, *not* TCP.  There's a couple
of good reasons (among others):

1.  It's kind of hard to do TCP as a multicast.

2.  In many cases, if the audio/video/whatever data disappears, it's
probably better not to try to get it retransmitted because it might
take a long time, by which time the data would be useless.

These are reasons not to use TCP for the transmission of this kind of
traffic.  But it doesn't say anything about whether or not it's
feasible to do this stuff using UDP, or some other transport layer
protocol running on top of IP.  As has been pointed out by several
people, the MBONE works pretty well, considering there are no resource
reservation schemes used (a la Tenet, RSVP, et al.)

> Vernon Schryver    vjs@rhyolite.com
--
------------------------------------------------------------------------------
Bruce A. Mah		   Graduate Student	       bmah@tenet.Berkeley.EDU
		      Computer Science Division
		  University of California, Berkeley

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 18:59:57 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJLJFG.Du2@calcite.rhyolite.com>, vjs@calcite.rhyolite.com
(Vernon Schryver) writes:
->
->What's with all of this political technology?  This "it can't possibly
->work and so it doesn't work and everyone who is trying it is stupid and
->should go get jobs as telco linemen because that's the coming thing"?
->

Where in this thread did you find that quote????  I am not saying that it 
cannot be done (I reiterate).  I am not saying that it is stupid or a waste
of time, and from what I read, no one else is either!  Talk about politics!

Sean Allen                                               Programmer/Analyst
(919)543-6021 Fax 7996                         Planning Acquisition Systems
Internal Zip: D533/B205                       IBM Personal Computer Company
VNET: RTP(SALLEN)                                Research Triangle Park, NC
#include<std_disclaimer.h>                   Internet: allensd@vnet.ibm.com

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 19:17:39 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??

In article <GTHAKER.94Jan12153217@trantor.atl.ge.com> gthaker@atl.ge.com (Gautam H. Thaker) writes:
   ... sending UDP/IP on strictly unidirectional link (a oneway
   satellite link)...  I am not sure what datalink layer will work for
   us.  HDLC (and its variants PPP, SLIP) etc. all seem to
   bidirectional Data Link Layer protocols.  THey at least do some
   handshake to get established.

SLIP has no startup handshake.  (That lack is why PPP's option
negotiation mechanism was created.)  You can simply tell your SLIP
implementation that your link is ready to carry datagrams, with no
messy preliminary bidirectional exchanges.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 21:04:11 GMT
From:      flin@saturn.sdsu.edu (Frank K. Lin)
To:        comp.protocols.tcp-ip
Subject:   Socket Write

Is there a limit on the size of data that each write() system call
with socket can handle?  

Frank Lin
flin@cs.sdsu.edu

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 21:46:22 GMT
From:      swcxt@teal.csn.org (Shane Castle)
To:        comp.protocols.tcp-ip
Subject:   Re: Source to TNVT220 Emulator

TNVT220 is a Novell product.  You should talk to Novell about any mods
you require.

Shane Castle			<swcxt@boco.co.gov, swcxt@csn.org>
Boulder County Info Svcs
Boulder CO

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 21:49:31 GMT
From:      klinde@silver.sdsmt.edu (Karen Linde)
To:        comp.protocols.tcp-ip
Subject:   desktop video conferencing options

We are thinking about doing desktop video conferencing, preferably DOS or 
Windows based. What are my options? What do you use? What's the price, money 
wise and bandwidth-wise?

Thanks,
Karen Linde
South Dakota School of Mines & Technology
klinde@silver.sdsmt.edu

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 22:13:30 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Improving interactive SLIP performance


In article <2h6qn2INNh0s@swimming.cis.ohio-state.edu>, 
grichard@cis.ohio-state.edu (Golden Richard) writes:

|Unfortunately I'm a SLIP user rather than a SLIP guru.  Is it possible
|to improve interactive response at the expense of non-interactive
|things such as ftp?
|
|I have a 14.4k line and I'm usually using telnet with sporadic ftp's.
|I wouldn't care if some of the ftp's took longer if only I could
|improve the response time in the telnet session (while an ftp is in
|progress) a bit.  Are there parameters to tweak which can pull this
|off?

Shrinking the MTU on the line is a good way to go.  Many SLIPs 
will default to an MTU of 1006 or so bytes.  If you have a TELNET
keystroke stuck behind a 1006-byte FTP packet, then it'll have a bit
of a wait.  It is reasonable to cut the MTU to about 250 bytes.
This will still provide reasonable bulk transfer throughput but will
improve interactive feel substantially.

VJ header compression (CSLIP) is always a win, of course.  Make sure
it's on.

Some SLIP implementations (well, MultiNet) support multiple packet 
queues per interface.  The small packet queue will be drained out-of-
order before the large packet queue.  Your implementation may have a
knob that lets you pick the split between large and small.

Some SLIP implementations (well, Xylogics') support TOS (Type of Service)
queueing.  If the application sets, say, the Low Delay bit in the TOS
field in the IP packets it emits, then SLIP could let those packets
cut in front of other packets.  This would probably be the ideal way
of ensuring that interactive packets get priority.  Alas, in practice
almost no real applications set bits in TOS.

Anyway, there's some ideas.  Of course, the brute force method is
always to be preferred - get a (proto) V.34 modem with V.42bis and
get your DTEs set to 115.2Kbps.  Then your FTPs might won't
bother you.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721




-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1994 11:40:48 -0800
From:      reick@girtab.usc.edu (Michael Reick)
To:        comp.protocols.appletalk,comp.protocols.ibm,comp.protocols.iso,comp.protocols.pcnet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Questions on protocols


I am trying to write a protocol for high speed modem communications, for a 
specific application, and am wondering where (on the Internet) I can find 
information, such as source code or articles on existing protocols, like 
Zmodem, BiModem, etc.  A quick session with Gopher was fruitless.  
Basicly my questions are regarding what kind of errors to expect, and how to 
handle _loss_ of bytes within a packet.  Its simple to assume that if your 
packets are 1024 bytes long, then all you have to do is read 1024 bytes, check 
the crc, and accept or discard them for retransmission.  But what I want to 
know is, what if line noise (or some kind of error) makes my nice little 1k 
packet 1017 bytes or 1033 bytes long?  Should I expect this kind of error? 
Do I search the entire data stream for a END_PACKET token followed by a 
START_PACKET token, and then hope that its the real MacCoy?  I have found 
articles on Xmodem and Ymodem, and no mention of this problem was made, 
so maybe it doesn't happen much, that bytes can be corrupted or changed, 
but not actually lost or inserted.

Any help would be.... Helpful




-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 23:45:11 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP protocol bug?

In article <CJHoE2.Cv8.3@cs.cmu.edu> esb+@cs.cmu.edu (Edoardo Biagioni) writes:
>I have been implementing TCP, and I have been puzzled by a bug
>that seems permitted by the standards (RFC 793 and RFC 1122).

Well, since no one's posted any wisdom on the subject, I suppose my
vague recollections will have to do.  My first TCP implementation in
1982 did, in fact, stick fully formed segments on the retransmission
queue, and I encountered these problems back then.  They were
discussed on -- gee, I guess it was on this mailing list, although you
wouldn't recognize it anymore if you were on it back then.  I recall
two decisions being announced by one of the "fathers of TCP", but I've
since been unable to turn up any evidence or witnesses, and that
wisdom doesn't seem to be included in RFC-1122.  Either it's lost
wisdom, or this was all made up in my fevered brow.  Anyway...

>In some implementations, the exact same segment as originally sent may
>be retransmitted...

The first wisdom was that implementations were encouraged to always
send the latest ACK and window information in every retransmission.

>The retransmissions actually go through, and A issues an ack for B's
>packet. A must use snd.nxt as its sequence number [RFC 793, p. 74].
>When B gets the ack, it queues the packet [RFC 793, p. 70: "In the
>following it is assumed that the segment is the idealized segment that
>begins at rcv.nxt... Segments with higher beginning sequence numbers
>may [*should* as per RFC 1122] be held for later processing"].

The node queues the packet, it's true, but the second wisdom was that
the ACK information in the packet should be processed *immediately*,
not later when the *data* in the packet is finally next in line for
processing.  Since ACKs can be processed in any order, the wisdom held
that "the sooner, the better."  I believe the same recommendation was
tendered for window information, but I'm a little foggier on that
matter.

Another similar mistake made by many implementations is to lose the
ACK and window information because they discard the packet if, after
"normalizing" it, there's no data left in the window.  The ACK and
window information is still good and, in some cases, important even in
retransmitted packets, so it should be used even if the data in the
packet is entirely redundant.

>I have (of course) modified my implementation so retransmits now carry
>the latest ack, but I was just wondering if this was a well-known bug
>in the TCP standard. If not, and if it is indeed a bug, who should it
>be reported to?

As I say, I thought this was all discovered a dozen years ago, but
since then it appears to have been lost to antiquity.  I'm not sure
who you should take it up with now.  Bob Braden (braden@isi.edu) is
the author/editor of RFC-1122.  Perhaps he'd be the place to start.

					don provan
					donp@novell.com

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 00:45:46 GMT
From:      tsai@li.loral.com (Edward Tsai)
To:        comp.protocols.tcp-ip
Subject:   X.25 Source code


Hello there,

Does anyone out there know where I can obtain Source Codes for X.25 software
or purchase them from ??.  Maybe a FTP Site name ??.

Thanx.


Edward Tsai
Loral Instrumentation
tsai@li.loral.com
(619)674-5100  ext: 4488



-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 03:10:43 GMT
From:      tede@alcor.concordia.ca ( TED EWANCHYNA )
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   protocol engineering bib files


I think that this is the right newsgroup ....
I am interested in knowing if anyone out there keeps a LaTeX bib
database of references in the protocol engineering, formal
description techniques, protocol validation area
- papers by people like Holzmann, Bochmann, etc.

Also, there was a mailing list for Estelle at udel.edu.
Does anyone know what became of it?

If anyone can help with the bib files it would be most appreciated.
Please send e-mail or pointers to where/if these answers can be found.



-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 94 14:33:06
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Does anybody have mods to tcpdump to decode Novell traffic?

We need to know a bit more about the Novell traffic on our backbone network,
and I'd prefer to use some of our tested and proven tools for this, more
specifically tcpdump. Does anybody have mods to tcpdump to decode Novell
traffic, or do I have to write this myself?

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 14:36:25 GMT
From:      cml0464@ultb.isc.rit.edu (C.M. Leung)
To:        comp.protocols.tcp-ip
Subject:   X protocol over TCP/IP

Hello:
	I have two questions:

	X operates over TCP/IP.  Does it deal with both BSD and SYSV
interfaces or operate at a lower level?

	Secondly, X protocol, as far as I know, most of the times buffers
requests.  What about entered characters?  Are these manipulated by setting
certain options over the sockets (if sockets are used at all) ?

Regards

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 94 19:43:12 GMT
From:      mayshah@gandalf.rutgers.edu (Mayank Shah)
To:        comp.protocols.tcp-ip
Subject:   Mosiac for Winsock



I down loaded mosaic for winsocket but it does not have any documentation.

Does any one know where I can get doc. on setting it up to connect to
info.rutgers.edu

 Mayank

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 20:47:53 GMT
From:      johannes@titan.os.open.de (Johannes Stille)
To:        comp.protocols.tcp-ip
Subject:   How to switch off the Nagle algorithm?


Hello everyone!

I'm working on an implementation of TCP/IP (i.e. trying to improve it),
and I just came across section 4.2.3.4 of RFC 1122. It says that I
SHOULD use the Nagle algorithm to avoid sending short segments
unnecessarily, but I MUST give applications a way to disable the Nagle
algorithm, and the current code doesn't.

Now this particular implementation of TCP/IP uses Berkeley-style sockets
for communication with applications.

My question: Is there are standard way (e.g. a socket option) for an
application to disable the Nagle algorithm using Berkeley-style sockets?
And if there is no standard way in the original Berkeley code, are there
other common implementations of the socket interface that offer such an
option?

Thanks in advance,
	Johannes Stille

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Jan 1994 01:00:36 GMT
From:      mcr@Sandelman.OCUnix.on.ca (Michael Richardson)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

In article <2etup7$8jr@zip.eecs.umich.edu> zeeff@zip.eecs.umich.edu (John Zeeff) writes:
>>Inetd would however need to be changed if you wanted
>>to offer different services depending on address used.
>>You may prefer to change gopherd instead.
>
>This sounds like a job for a tcp wrapper type program (ie, inetd runs this
>program and it spawns the right process).  Does anyone have one?
>

  If you *do* have two network interfaces, (or can fake it via proxy
ARP and another loopback device), then you *can* bind to a specific
address. Usually one binds the socket you are going to listen on to
INADDR_ANY, but you can, bind it to a specific address as well.
  You'll have to write a modified inetd, or modify gopherd itself.
  
  Why not just use CNAMEs, and different port numbers?


 

-- 
   :!mcr!:            |  "Elegant and extremely rapid for calculation are the 
   Michael Richardson | techniques of Young tableaux. They also have the merit
 mcr@ccs.carleton.ca /of being fun to play with." - p.47 Intro to Quarks&Partons
 mcr@sandelman.ocunix.on.ca / +1 613 729-5409 / +1 613 788-2600 3853 (work)

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1994 11:37:45 -0500
From:      hal@clark.net (hal)
To:        comp.protocols.tcp-ip
Subject:   looking for secure tcp-ip code.

I'm looking for source for tcp/ip that can provide basic types of crypto
security. I've seen this discussed and even plans for doing it but never
have I ever see any actual code for it.  What I'm after works like this:
It would use conventional crypto-keying with manually distributed DES
keys, it would provide encapsulation of the TCP/IP datagram adding chained
checksum to the datagram, perhaps relying on some IP option as a carrier.
It relies on the TCP session variables and the encapsulation to provide
strong integrity. It relies on DES key distribution to provide
authentication, at least at the host level. The application I'm working on
involves linking tcp/ip based hosts over a VHF/UHF radio link at speeds of
about 250Kbps. Mainly, I need to keep out hackers and spoofers. Privacy is
not really crtical (except to protect login passwords, a different problem)
and I'd like to not have to run kerberos if there's another way. If anyone
has seen such source or could point me at a source for this code it
would be very much appreciated. 

Please e-mail me direct since I don't usually subscribe directly to this 
group. Thanks again.  -hal@clark.net

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 94 07:01:15 GMT
From:      rickt@mecs.oau.org (Richard Thiessen)
To:        comp.protocols.tcp-ip,comp.sources.wanted,alt.sources.wanted
Subject:   Source for SMTP on Ethernet Network

I am starting a project soon to interface a version of TCP/IP for QNX
on an Ethernet System to allow mail to be sent and receive using the SMTP.
I am looking for the source to SMTP so I can import it to QNX.  

If I can't Get the Source is there some specifications that I can get 
to allow me to do an easier interface.

Thanks for your help

Rickt

o--------------------------------------------------------------------------o
| Richard Thiessen -- << N4YEZ >> --      | rickt@mecs.oau.org             |
| Micro Electronic Computer Systems Inc.  |                                |
| SCO Authorized Trainer                  | Office Phone:  (407) 290-2564  |
o--------------------------------------------------------------------------o

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 94 13:13:32 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: How to switch off the Nagle algorithm?

> I'm working on an implementation of TCP/IP (i.e. trying to improve it),
> and I just came across section 4.2.3.4 of RFC 1122. It says that I
> SHOULD use the Nagle algorithm to avoid sending short segments
> unnecessarily, but I MUST give applications a way to disable the Nagle
> algorithm, and the current code doesn't.
>
> Now this particular implementation of TCP/IP uses Berkeley-style sockets
> for communication with applications.
>
> My question: Is there are standard way (e.g. a socket option) for an
> application to disable the Nagle algorithm using Berkeley-style sockets?

The TCP_NODELAY socket option.

	Rich Stevens

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Jan 1994 14:36:26 GMT
From:      wdawson@willard.atl.ga.us (Willard Dawson)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

bernhard@trick.ani.univie.ac.at (Bernhard Strassl) writes:

>I would suggest the following:
 
>3) "UNIX Solution"
 
>  PC ---------------------- LAN or WAN ---------------- Relational DB
>  (running UNIX)                                       (Sybase/Oracle)
 
>Then you are able to have the clients running on both sides with
>less troubles. If you still need DOS - nearly ervery PC UNIX provides
>a stable DOS emulatior. Most MS-Windows stuff should run pretty good
>under SUN's WABI (I couldn't test this myself up to now, but I hope to
>get it soon).

My attempts to install PowerBuilder under WABI result only in crashing
WABI.  The effect is *immediate*.  So, if you're expecting to run "most
MS-Windows stuff" under WABI, I believe you're being extremely
optimistic.


-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Jan 1994 15:08:12 GMT
From:      treeves@Cadence.COM (Tim Reeves)
To:        comp.protocols.tcp-ip
Subject:   Trying to write a telnet appl.

I'm trying to transfer some stuff from a Mac to a Sun using 4th Dimension -
I thought I'd do it by opening a TCP connection to port 23 (telnet) on the
Sun and 'logging in' then have the program type stuff into a file, then 
logout. When I connect to port 23 I get some control characters coming back,
which are to do with terminal control. Does anyone know what codes I need
to send back to set up as a simple terminal and get the login prompt?

Thx,


-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Jan 1994 23:48:10 GMT
From:      gja@ee.mu.OZ.AU (Grenville Armitage)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJKxn1.120K@sernews.raleigh.ibm.com> allensd@vnet.ibm.com writes:
>In article <CJIyw6.H7w@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Ran
>Atkinson) writes:
 [..]
>->encoding algorithm one is using).  Ah yes, and I spend most of
>->1991-1993 working with ATM so I have some small experience with the
>->technology.  ATM has its uses, but it isn't the panacea that it is
>->hyped to be.
>
>   Agreed, however, IMHO it shows more promise than TCP/IP. 
	[..]

Lines like this will continue to get you somewhat terse responses.
Even assuming you're using 'TCP/IP' as a generic descriptor of
Internet protocols (so covering UDP/IP), you're comparing apples
and oranges.

How can _ATM_ show more promise than TCP/IP anymore than Ethernet
shows more promise than ftp for transferring data around?
Even assuming you include the basic AAL services in 'ATM' the
comparison is still wrong-headed. Its been argued [1] that
even at the top of the AAL, the service is analogous to
a Data Link layer.

gja

[1] M. De Prycker, R. Peschi, T. Van Landegem, "B-ISDN and the
    OSI Protocol Reference Model", IEEE Network, March 1993, pp.10-18.

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1994 00:39:50 GMT
From:      jcant@wonga.awadi (John Cant)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP

In article oda@rowan.coventry.ac.uk, mhart@rowan.coventry.ac.uk (M J HART) writes:
>
>I have to right an assignment on TCP/IP and know nothing about this protocol,
>i need any information on the history of this protocol and the ussaly sort of
>pros and cons of this protocol over the ISO model
>
>I would be really greatfull if anybody can help me via Email.
>-- 
>************************* Barclays Bank: An institution where you can borrow
>*      M A T T          * money if you present sufficient evidence that you 
>* mhart@uk.ac.cov.rowan * don't need it!!!!!!!!
>*************************



Try reading a good book about the topic. Its always good to try to find out the 
information yourself. Computer Networks by Andrew S. Tanenbaum (Prentice Hall
ISBN 0-13-164699-0) has a good introduction to networks and TCP/IP in particular.
I think that this well writen book will give you a better understanding then you are 
likely to get over the Net. (I dont intend to criticise the people out there on the
net, but if you could write a better description than any available book, you would be 
an author selling you work rather than giving it away on the net).

 -----------------------------------------------------------------------------
John Cant            | 
Research Engineer    | My Opinions are my own. I sell them to my Employers  
AWA Pty. Ltd.        | who accept, or reject them as they feel fit.
Australia            |
jcant@awadi.com.AU   | 
-----------------------------------------------------------------------------


-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 94 01:00:57 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing

In article <2h1nuk$b40@organpipe.uug.arizona.edu>, leonard@telcom.arizona.edu (Aaron Leonard) writes:
> 
> In article <MISCHLER.94Jan12000224@norman.li.Cubic.COM>, 
> Dave.Mischler@Cubic.COM writes:
> 
> In practice, I am not aware of ANY production use of directed
> broadcasts.

The Columbia AppleTalk Package (CAP) running over the IPTalk
encapsulation method uses directed-broadcasts to emulate/support
Apple's Zone-based NBP LookUp (the way AppleTalk finds services).
Directed broadcasts are send to other IP Subnets in order to locate
file-serving, pront-spooling and other services.

CAP actually forms a very sensitive "canary" to subnet and mask
misconfiguration problems, indicating that it is usually the only
protocol that depends on directed-broadcasts working properly.

There is a program (atalkrd) that allows CAP/IPTalk to operate
without (working) directed broadcasts, but it is not used much.

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-560-1100  FAX ...560-0067  A.C.N. 004 818 455


-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 01:24:07 GMT
From:      tendo@netcom.com (Thomas A. Endo)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for secure FTP servers

John Bourke (john_bourke@inmarsat.org) wrote:
| Howdy,
 
| Are there any secure FTP servers available that will only allow users's to see 
| their home directories, and leave good audit trails.
 
| Are there any security enhanced versions of standard IP application protocols.
 
| I'm looking for these for SCO, or source code.
 
| thanks


| john

This sounds like a firewall type of package that you're asking for.
Part of the job of a firewall is to make sure that every transaction that
goes across a domain border gets logged.  (Incidentally, almost all
firewalls nowadays will cause all of the processes to go through a proxy
that will log transactions and they will not route traffic between the
trusted and untrusted networks.  They will run the traffic through user
processes for logging and auditing purposes.)

I've read in the Firewalls group about some proxy servers written by
Marcus Ranum.  You may pick these up at ftp.tis.COM under the directory
/pub/firewalls/toolkit.  You may wish to contact the author as well,
at mjr@tis.COM, but I do know these are free for the taking.  (In fact,
I've got one of the pieces running on my home NetBSD system as well.)
Their site is a firewall as well, so it likely runs the FTP proxy.

The API is Berkeley Sockets, but I do know that SCO Unix does have a
Socket library available in its TCP/IP developer's kit.  I've used it
a bit on my ODT 1.0 machine at my workplace, but haven't tried putting
the firewall toolkit on that machine.

If you have any more questions about firewalls, I would say that you may
wish to E-mail mjr@tis.COM for further details, or subscribe to the
firewalls mailing list via E-mail to Majordomo@GreatCircle.COM, message
body "subscribe firewalls you@yoursite.domain".  Once you E-Mail the
firewalls@GreatCircle.COM list, you can get answers from firewall
sysadmins.  (I did so once without subscribing to the mailing list.)

Another interesting application I found was the xinetd source code.  I
have a copy, but I think I'll need to look to tell you what newsgroup
I took it from.  I think there's another place to beef up security even
with UDP.  (This I haven't tried yet.)

Tom

(All disclaimers are standard....)
--
Thomas A. Endo                   | Internet:  tendo@arinc.com [Work];
ARINC Research Corporation       |            tendo@netcom.com [Home/Misc]
2250 E. Imperial Hwy., Suite 450 | FAX:       (310) 322-4474
El Segundo, CA 90245             | Phone:     (310) 322-2010

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 01:43:56 GMT
From:      tendo@netcom.com (Thomas A. Endo)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a firewall

Sextant Group (sextant@netcom.com) wrote:
|  Zo> I have a small TCP network of 50 or so Unix platforms that I would
|  Zo> like to bridge to my campus WAN, which is on the internet. The catch is
|                     ..           ..            ..
|  Zo> I understand that this would be called a "firewall" and that many
|  Zo> companies use such a set up to isolate their networks from intrusion. I
|  Zo> am looking for references detailing how something like this is put
|  Zo> together.  
|  Zo> At the least, I would like to enable the one machine with the two
|  Zo> interfaces to act on both of my networks. But I am uncertain how to
|  Zo> direct the machine to treat one interface differently from the other.
|  Zo> All of my references on networking seem to assume a single network
|  Zo> interface.  
|  Zo> Are there references or an FAQ that address this issue? 


| First of all, you can't create a firewall with a bridge. You have to
| route. A bridge passes everything regardless - it doesn't examine or
| verify packets. A router can make intelligent choices and disallow
| transactions.

Agreed.

| The easiest method is to put two cards into a unix box and kill routed.
| Since this box doesn't route packets, they will have to telnet to this
| box and do their operations from there. By making access extremely
| limited on that system, it'll stop most things.
 
| That's really just the tip of the iceberg for security, but it is the
| first necessary measure.

True, but I also asked another question and sent it to the firewalls
mailing list at GreatCircle.COM.  I wanted to find out how to ensure
traffic separation between the trusted and untrusted networks.  So,
the synopsis:

To ensure a dual-homed firewall to have complete control of its
transactions, you must also set a kernel variable, _ipforwarding, to
zero.  This needs to be permanently stored in the kernel so that
traffic between network interfaces does not flow via the kernel.
Under SunOS, I think it is a config file entry such as

OPTIONS "IPFORWARDING=0"

That's deeper into the iceberg as well.  Apparently, routed may
advertise, but if the option is set to a 1, you'll get autoforwarding
with no knowledge of it.

Firewalls essentially control traffic via user processes that can log
what's happening as well as be set for the required security policy.
In other words, ALL traffic crossing your domain boundary goes through
a user process (or processes) and does not get routed via the kernel.

Tom
--
Thomas A. Endo                   | Internet:  tendo@arinc.com [Work];
ARINC Research Corporation       |            tendo@netcom.com [Home/Misc]
2250 E. Imperial Hwy., Suite 450 | FAX:       (310) 322-4474
El Segundo, CA 90245             | Phone:     (310) 322-2010

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 01:48:09 GMT
From:      tendo@netcom.com (Thomas A. Endo)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for SMTP on Ethernet Network

Richard Thiessen (rickt@mecs.oau.org) wrote:
| I am starting a project soon to interface a version of TCP/IP for QNX
| on an Ethernet System to allow mail to be sent and receive using the SMTP.
| I am looking for the source to SMTP so I can import it to QNX.  
 
| If I can't Get the Source is there some specifications that I can get 
| to allow me to do an easier interface.
 
| Thanks for your help
 
| Rickt

Richard,
Of course, we could always get sendmail from our 386 or NetBSD distribution
via agate.berkeley.edu.  Or try mmdf via archie.

I am running mmdf on an SCO box (of course no source code) but I do have
sendmail running on my NetBSD partition.  Under the CERT advisories you may
also find the site for the latest sendmail distribution.

Tom
--
Thomas A. Endo                   | Internet:  tendo@arinc.com [Work];
ARINC Research Corporation       |            tendo@netcom.com [Home/Misc]
2250 E. Imperial Hwy., Suite 450 | FAX:       (310) 322-4474
El Segundo, CA 90245             | Phone:     (310) 322-2010

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 05:38:49 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a firewall

In article <tendoCJr3H9.3Iz@netcom.com> tendo@netcom.com (Thomas A. Endo) writes:
>To ensure a dual-homed firewall to have complete control of its
>transactions, you must also set a kernel variable, _ipforwarding, to
>zero.  This needs to be permanently stored in the kernel so that
>traffic between network interfaces does not flow via the kernel.
>Under SunOS, I think it is a config file entry such as
>
>OPTIONS "IPFORWARDING=0"
>
>Thomas A. Endo                   | Internet:  tendo@arinc.com [Work];
>ARINC Research Corporation       |            tendo@netcom.com [Home/Misc]
>2250 E. Imperial Hwy., Suite 450 | FAX:       (310) 322-4474
>El Segundo, CA 90245             | Phone:     (310) 322-2010

To turn off forwarding this should be set to -1, 0 allows forwarding if
there are more than two interfaces (excluding lo0), 1 turns forwarding
on regardless of the number of interfaces.

This is trus of SUNOS 4.1.X. On other platforms your milage may vary.

Mark

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 10:58:38
From:      rodin@lard.ftp.com  (Jonathan A. Rodin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers

rwpratt@novell.com (Robert Pratt) writes:
>    LANWatch, from FTP Software.  DOS based, TCP/IP oriented, also
> in the ~$1000 range.

List price $1200 unit one.

It is not "TCP/IP oriented".  A common misconception, based on the fact that
FTP Software is a TCP/IP vendor.  LANWatch decodes many protocols including 
the following protocol families:

    TCP/IP, XNS, Netware, Lan Manager, Decnet, OSI, Banyan and AppleTalk.

Altogether, LANWatch decodes over 60 protocol layers in these families.
LANWatch runs over ethernet/802.3, token-ring and serial line (Slip/PPP).

Jon

--
Jonathan Rodin              FTP Software, Inc.            voice: (508) 659-6261
rodin@ftp.com               2 High Street                 fax:   (508) 659-6105
                            North Andover, MA 01845


-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 06:54:00 GMT
From:      pbowyer@pcl.demon.co.uk  (Peter Bowyer)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: SMTP <-> DISSOS/Memo

In article <CJBMH2.14K@eunet.ch> Florian.Gutzwiller@open.ch (Florian Gutzwiller) writes:

 >> Can anybody comment on solutions that would make SMTP talk to IBM Dissos Mail  
 >> and vice versa. I know high price solutions like HP OpenMail or EMX SoftSwitch  
 >> can do that, but I'm rather looking for something really open and simple.
 >> 

If you're looking for a service-based solution, then IBM Mail Exchange now has an SMTP
gateway into Internet.

Peter


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 16:42:49
From:      shehab@rogers.com (Shehab Nawawi)
To:        comp.protocols.tcp-ip
Subject:   dynamic allocation of ip addresses

Is there anyway I can get a (BOOTP) ?server to dynamically allocate ip 
addresses, without a MAC-ip translation? I mean just send over the first 
available ip address as opposed to mapping a particular MAC to a particular ip 
address. Of course, it would have to check for authenticity of the client 
machine in a database containing the authorized MAC addresses.


i appreciate your responses


.sn

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 12:10:16 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP

John Cant (jcant@wonga.awadi) wrote:
: In article oda@rowan.coventry.ac.uk, mhart@rowan.coventry.ac.uk (M J HART) writes:
: >
: >I have to right an assignment on TCP/IP and know nothing about this protocol,
: >i need any information on the history of this protocol and the ussaly sort of
: >pros and cons of this protocol over the ISO model
 
: Try reading a good book about the topic. Its always good to try to find out the 
: information yourself. Computer Networks by Andrew S. Tanenbaum (Prentice Hall
: ISBN 0-13-164699-0) ...

I would suggest Douglas E Comer's "Internetworking with TCP/IP" myself. 
You'd want Vol 1 of the 2nd Ed.  I only have the one-volume 1st Ed to
hand so I can't give you the ISBN.

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK


-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1994 12:22:15 +0100
From:      jpmens@ingres.com (Jan-Piet Mens)
To:        comp.protocols.tcp-ip,comp.periphs.printers
Subject:   HP Laserjet IV & Ethernet

Perhaps one of you could give me some info on the following:

I have a customer who has a HP Laserjet IV with an Ethernet card and NO
manual (so I can't RTFM :-)
The printer is connected to a UNIX box w/ SVR4.

What protocol is used to "talk" to the printer (get it to print something) ?
Is there a fixed port-address that the printer listens on for data ?
What would be the best method to interface to that printer ?

Thank you for any help you can give me...
Regards,
	Jan-Piet
-- 
Jan-Piet Mens                                               jpmens@ingres.com
ASK Ingres GmbH, Frankfurt, Germany                          +49 69 66413-285

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 14:36:46 GMT
From:      lapp@waterloo.hp.com (David Lapp)
To:        comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: HP Laserjet IV & Ethernet

Jan-Piet Mens (jpmens@ingres.com) wrote:
: Perhaps one of you could give me some info on the following:
 
: I have a customer who has a HP Laserjet IV with an Ethernet card and NO
: manual (so I can't RTFM :-)
: The printer is connected to a UNIX box w/ SVR4.
 
: What protocol is used to "talk" to the printer (get it to print something) ?

No "protocol" as such. Simply open a TCP connection and send data.
(Assuming your using tcp and not Netware or something :-)

: Is there a fixed port-address that the printer listens on for data ?

Yes Port 9100. The printer should support bootp I believe
and SNMP as well. If you have software installed on the UNIX
box you may have the MIB file there somewhere. (I'm not familiar
with the directory structure on SVR4 boxes so I can't suggest
where. Sorry) You don't absolutely need SNMP to make it work.

: What would be the best method to interface to that printer ?

Depends on what you are doing. I'd suggest you consider 
using the spooling system on the Unix box but if that
woun't work for some reason 

: Thank you for any help you can give me...

You're welcome.

Dave Lapp

Standard Disclaimer etc...



-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 94 14:45:19 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJLJFG.Du2@calcite.rhyolite.com>, vjs@calcite.rhyolite.com (Vernon Schryver) writes:
|> In article <1994Jan13.194323.17392@mmm.mmm.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:
|> > ...
|> >I've no hands on with MBONE:  are you saying the quality is good enough to run a
|> >phone system over it?  If not, it is merely an interesting technology trial and
|> >not something that could be considered a productive, sellable service.
|> 
|> What does a telephone system have to do with the MBONE?
|> Do you complain that your sports car is a terrible pickup truck?
|> 
|> Multimedia is not the same as a plain ol' telephone signalling.  If it
|> were, picture phones would not be more than 20 years old and still a
|> commercial flop.
|> 
|> What's with all of this political technology?  This "it can't possibly
|> work and so it doesn't work and everyone who is trying it is stupid and
|> should go get jobs as telco linemen because that's the coming thing"?
|> 
|> There are commercial products that involve cameras, microphones,
|> CRT's, speakers, and IP.  People are buying the stuff.  Let's hope
|> those buyers think it is "a productive, sellable service."  I don't
|> think those products are roaring successes yet, but it's early.

Now, hang on Vernon, nobody made any political statements.  The idea here was to
convey that TCP(UDP)/IP has no way of informing the media that it needs guaranteed
bandwidth which is what you pretty much need to do QUALITY video and voice. 
Nobody said that you can't do voice and video over current Internet technology
but then no one said that you can do voice and video RELIABLY over current
Internet technology.

The reason video phones never took off was because of the price of the sets
and because of the bandwidth requirements.  Both of those restraints are being
dealt with through smarter compression algorithms and through the general
availability of cheap computer technology.

As far as the video toys that are currently being sold, I can easily trash the
transmissions of any one of them if I'm allowed to put general data traffic of
sufficient magnitude on the same line.  You'll notice that even at Interop,
booths doing that sort of thing were done on networks that were grossly
underutilized and in most cases, isolated.  The trick is traffic integration. 
That's what a phone system has to do with MBONE:  voice, video, and data all
using the same pipes (multiplexing) and interacting (multimedia).

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 94 15:01:10 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: HP Laserjet IV & Ethernet

In article <2hdsd7$p7k@trsun1.ingres.com>, jpmens@ingres.com (Jan-Piet Mens) writes:
|> Perhaps one of you could give me some info on the following:
|> 
|> I have a customer who has a HP Laserjet IV with an Ethernet card and NO
|> manual (so I can't RTFM :-)
|> The printer is connected to a UNIX box w/ SVR4.
|> 
|> What protocol is used to "talk" to the printer (get it to print something) ?
|> Is there a fixed port-address that the printer listens on for data ?
|> What would be the best method to interface to that printer ?
|> 
|> Thank you for any help you can give me...
|> Regards,
|> 	Jan-Piet
|> -- 
|> Jan-Piet Mens                                               jpmens@ingres.com
|> ASK Ingres GmbH, Frankfurt, Germany                          +49 69 66413-285

If the card in question is an HP "Jet Direct" card, the card probably loads using
BOOTP.  Once loaded, the print data typically comes from a UNIX print queue via
an HP proprietary protocol using a high order port in the 5000's or 6000's.

Charles.


--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 94 17:47:30 GMT
From:      king@CS1sequoia.com (King)
To:        comp.protocols.tcp-ip
Subject:   RS6000 rlogin to Sun problem

Has anyone every had a problem with RS6000s rlogin to other
systems?  I am getting a "hostname unknown" message.  When
I use a Sun, I can make the connection.  I suspect some cryptic
field in "smitty" has to be set.  If anyone has an idea, let
me know.

Jack

 

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 18:30:45 GMT
From:      sallen@herbie.raleigh.ibm.com (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <BMAH.94Jan14101642@propaganda.cs.berkeley.edu>,
bmah@propaganda.cs.berkeley.edu (Bruce A. Mah) writes:

->
->I think it's important here to distinguish the difference between
->using TCP/IP to carry voice and using the Internet protocols to carry
->voice.  Note that the MBONE uses UDP/IP, *not* TCP.  There's a couple
->of good reasons (among others):
->

I apologize for being vague.  When I say TCP/IP, I mean the entire protocol
suite...Which includes UPD.

Sean Allen                                        AIX/Sybase Administration
(919)543-6021 Fax 7996                         Planning Acquisition Systems
Internal Zip: D533/B205                       IBM Personal Computer Company
Internet: allensd@vnet.ibm.com                   Research Triangle Park, NC
#include<std_disclaimer.h>           Sponsor of the US Olympic Bobsled Team

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 19:16:56 GMT
From:      dowd@acsu.buffalo.edu (Patrick Dowd)
To:        comp.protocols.tcp-ip
Subject:   FINAL CALL - SIGCOMM94



			   Call for Papers
		      ACM SIGCOMM'94 CONFERENCE
       Communications Architectures, Protocols and Applications
				   
		      University College London
			      London, UK
				   
		    August 31 to September 2, 1994
		 (Tutorials and Workshop, August 30)

An  international forum  on  communication  network  applications  and
technologies, architectures, protocols, and algorithms.

Authors are invited to submit  full  papers concerned with both theory
and practice. The areas of interest include, but are not limited to:
   --  Analysis and  design  of  computer  network  architectures  and
       algorithms, 
   --  Innovative results in local area networks,
   --  Mixed-media networks,
   --  High-speed networks, routing and addressing, support for mobile
       hosts, 
   --  Resource sharing in distributed systems,
   --  Network management,
   --  Distributed operating systems and databases,
   --  Protocol specification, verification, and analysis.

A   single-track,   highly  selective  conference   where   successful
submissions   typically  report   results  firmly   substantiated   by
experiment,  implementation,  simulation,  or  mathematical  analysis.
Papers must be less than 20 double-spaced pages long, have an abstract
of  100-150  words,  and  be  original  material  that  has  not  been
previously  published  or  be  currently  under  review  with  another
conference or journal.

In addition to its high  quality technical  program, SIGCOMM '94  will
offer  tutorials by  noted  instructors  such  as  Paul  Green and Van
Jacobson (tentative), and a workshop  on  distributed systems  led  by
Derek McAuley.

Important Dates:

          Paper submissions: 1 February 1994
         Tutorial proposals: 1 March 1994
 Notification of acceptance: 2 May 1994
    Camera ready papers due: 9 June 1994

All  submitted papers will  be  judged  based  on  their  quality  and
relevance through double-blind reviewing where  the  identities of the
authors are  withheld from  the  reviewers.  Authors names should  not
appear on the paper.  A cover letter  is  required that identifies the
paper title and lists the name, affiliation, telephone  number, email,
and fax number of all authors.

Authors of accepted papers need to sign an ACM copyright release form.
The  Proceedings will  be published as a  special issue of ACM SIGCOMM
Computer Communication  Review. The program committee will also select
a few papers for possible publication in the IEEE/ACM  Transactions on
Networking.

Submissions from North America should be sent  to:
     Craig Partridge
     BBN
     10 Moulton St
     Cambridge MA 02138

All  other submissions  should  be sent to:
     Stephen Pink
     Swedish Institute of Computer Science
     Box 1263
     S-164 28 Kista
     Sweden

Five copies are required for paper submissions. Electronic submissions
(uuencoded,  compressed  postscript)  should be  sent  to each program
chair. Authors should also e-mail the title, author names and abstract
of  their  paper  to  each  program  chair  and  identify  any special
equipment that will be  required during its  presentation.  Due to the
high  number of  anticipated  submissions,  authors  are encouraged to
strictly adhere to the submission date.

Student  Paper Award:  Papers  submitted  by  students  will  enter  a
student-paper award contest.  Among the accepted papers, a maximum  of
four outstanding papers will be awarded full  conference  registration
and a  travel grant  of $500 US dollars.  To  be eligible the  student
must  be the sole author, or the first author and primary contributor.
A cover  letter must  identify  the  paper  as  a  candidate for  this
competition.


Mail and E-mail Addresses:

General Chair
-------------
    Jon Crowcroft
    Department of Computer Science
    University College London
    London WC1E 6BT United Kingdom

    Phone: +44 71 380 7296
    Fax: +44 71 387 1397
    E-Mail: J.Crowcroft@cs.ucl.ac.uk


Program Chairs
--------------
    Stephen Pink (Program Chair)
    Swedish Institute of Computer Science
    Box 1263
    S-164 28 Kista
    Sweden

    Phone: +46 8 752 1559
    Fax: +46 8 751 7230
    E-mail: steve@sics.se

    Craig Partridge (Program Co-Chair for North America)
    BBN
    10 Moulton St
    Cambridge MA 02138

    Phone: +1 415 326 4541
    E-mail: craig@bbn.com


-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1994 19:57:27 GMT
From:      pkarrer@bernina.ethz.ch (Peter Karrer)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Sockets on MVS

Hello,

We have a set of existing APPC appliciation which we would like to convert
to TCP/IP sockets. The applications in question run NS/DOS under Windows
and talk to APPC/MVS. They are very simple (only one-to-one conversations).

Writing a simple sockets server program on MVS is easy; however, I
see two administrative problems implementing a sockets solution:

(1) Before a client connects to a server program, the server program
must be running. As far as I know, there is no such thing as an inetd
- which would schedule servers on demand - in TCP/IP for MVS.

(2) The server program must run under the security context of the connecting
user. Of course, we would like to avoid to ask for userid/password each time
a connection is made; but we must take care not to break security rules (e.g.
store an unencrypted password on the PC).

Both these issues are no real problem with APPC; APPC/MVS has a scheduler,
and an NS/DOS user can specify a userid/password pair which is sent to a
particular partner node each time a conversation is allocated.

However, we would like to use sockets because we have more options for
client software on PCs (and Macs; NS/DOS is a memory hog and not 100%
stable under Windows).

Any ideas?

-- 
Peter Karrer                                   pkarrer@bernina.ethz.ch

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 94 20:22:37 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: RS6000 rlogin to Sun problem

In article <2061@seqp4.sequoia.com>, king@CS1sequoia.com (King) writes:
|> Has anyone every had a problem with RS6000s rlogin to other
|> systems?  I am getting a "hostname unknown" message.  When
|> I use a Sun, I can make the connection.  I suspect some cryptic
|> field in "smitty" has to be set.  If anyone has an idea, let
|> me know.
|> 

The issue isn't rlogin but name service.  Your systems don't agree on what their
names are.  You'd have to be a bit more specific about the names, the combination
of platforms that work, and the feedback from the platforms that don't.  The
message above indicates a name service failure not a rlogin failure.

Also, be aware that DNS and NIS differences come into play as well.  The names in
the /.rhosts and /etc/hosts.equiv will require full canonical names on the Sun
for those nodes not in the NIS database.  On the 6000, the simple hostname can be
used providing all of the nodes are in the same DNS domain, regardless of NIS
domain.  You also have to make sure that any nodes using NIS are able to use DNS
for non-NIS hosts.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 94 20:30:59 GMT
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.protocols.tcp-ip,comp.sys.mac.apps
Subject:   Is there an RPC package for MACs?


Fellow Netters,

	Is there a package similar to the Sun Remote Procedure Call
available on the Macs? I would appreciate it if someone could direct me
to either a PD or a commercial package.

	Any and all responses appreciated on this matter.

Thanx,

Raj.
-- 
===============================================================================
  __  __     .
 /   __/    /                               Raj Malhotra.
/   ( /_   /                                voice : (609)860 7111. 
        __/                                 email : manmetha@gauss.rutgers.edu

===============================================================================

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 21:20:05 GMT
From:      mgic <mgic@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   SLIP/PPP server - how to?


I am seeking a means to implement on-demand, dial-up SLIP/PPP service.

Requirements:

	- Assign the IP address at the time of the call

	- Record connect time stats

	- Optionally monitor connect time usage so that when a limit 
	  is reached the user can be disconnected

What hardware/software products will allow me to do this? Thank you.

Dean
-- 

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 21:52:48 GMT
From:      lbd@osreq48.rockwell.com (Lionel Dyck)
To:        comp.protocols.tcp-ip
Subject:   IMS and CICS LPR Interface...?

I am looking for an interface for IMS and CICS that will allow an IMS or CICS 
transaction to print using the LPR interface.  Is anyone aware of any code that 
will do this that is generally available, perhaps on some user tools/mods tape?

Thanks.

Lionel Dyck - Rockwell International
IBMMail:  USROKNTN     Internet:  lbd@osreq48.rockwell.com


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 13:56:37 -0600
From:      baji@bnr.ca (Baji Edupuganty)
To:        comp.protocols.tcp-ip
Subject:   Hashing of IP addresses - summary of responses


My query:
---------
> I'm working on an application that will key off of IP addresses; therefore
> I'm looking for a hash alg. that will hash IP addresses to something in the
> range 2000. Anyone, know of any PD algs, or code that I can leverage? Any 
> help will be appreciated. My e-mail addr is "baji@bnr.ca". Thank you.

Response 1
----------
I was wondering if you received any replies.  I'm doing something
like this at the moment except that I'm using a port number as
well, and what I am doing is XOR-ing the high and low halves
of the IP address and the port number (in 16 bits) and then
taking that modulo the hash table size.  It works (of course)
but I am not sure how good it is, and would be very interested
to know what you have found out.  Thanks.

Response 2
----------
some reason you don't just %2000 the addr (which is a 32b long, after all)?
also, 1999 is a better hash modulus, since it's prime.  without proof that
the simple approach results in too many collisions, I wouldn't try anything
more complicated.  I'd also be tempted to xor together the ushorts or even
bytes of the addr.

Response 3
----------
Is the modulo function good enough?  It works well in software here.
I never got around to looking for a fancier function.

[You know, I see RFC material here... :-)]

Response 4
----------
I add the 4 octets together and use the lower 8 bits of the sum as
the hash index.  This gives 256 hash buckets.  Using 3 more bits
from the result would give 2048 hash buckets.

Response 5
----------
I'm not sure what your environment is but if you are using a 32-bit
processor, why not treat the IP address as a 32 bit integer and use the
remainder after dividing by some prime as the hash value.  Since class C
addresses are negative numbers, you may find it more convenient to use

	hash = addr % 997 + 996

to get hash into the range 0 to 1992.

Response 5
----------
What's wrong with the obvious of just taking the IP address, as a 32-bit
integer, modulo 2000 (or whatever, presumably prime, size your hash table
is?).  The bottom 16 bits of an IP address are moderately random.
-- 

My response:
    There is nothing wrong with modulo or XOR or any other scheme
since from the above both methods appear to be used. I was really 
interested in any distributions or studies done on IP addresses. 

    For our application, we expect to predominantly see class B
and Class C addresses. Treating it as an unsigned value avoids the
negative numbers issue. For us, division is not acceptable. We may just
end up using the lower 13 bits and have 8k buckets. Tentative solution,
till we gather more data...

    I was told to look at Douglas Comer's book, but that wasn't much use
to me. I don't recollect much of a discussion on hashing of IP addresses
in there either. 
    Hope that helps. Thanks to everyone who responded. I've not included
the headers from the original responses on purpose. If anyone is interested
I can post the summary with all headers. 

Regards,
baji


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 04:44:30 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

One thing that many of the "TCP/IP can't do voice" proponents miss is that
both the "TCP/IP way" and the "phone company way" involve tradeoffs.

Currently, voice over TCP/IP is designed so that congestion results in
degraded fidelity.  This is what the anti-TCP/IP people notice, and they
say "you can't do QUALITY voice over TCP/IP".  There's work going on to
define protocols for resource reservation in TCP/IP, but that's orthogonal
to my current point.

When the regular phone system gets congested, it simply refuses to
overallocate bandwidth.  The symptom for this is a fast busy reorder, and
you have to try your call again.

Thus, both of them have problems when the resources are near their limits.
The TCP/IP people decided that signal quality could be sacrificed, while
the phone company decided that connection completion could be sacrificed.
But in both cases, the user is inconvenienced.

Just as TCP/IP doesn't currently have a way for the user to request a high
fidelity voice connection (yes, there are header fields for it, but they
don't usually do anything useful in current nets), the phone company
doesn't provide a way for the user to request a low fidelity connection (to
ensure that the call goes through).  They both force a particular design
decision on the user.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 1994 11:14:31 GMT
From:      djn@csc.liv.ac.uk (David Nixon)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   IP multicast for HP-UX

Extensions to the HP-UX 9.01 kernel to support IP multicast
address routing are now available on the Liverpool Ftp archive.

[ftp.csc.liv.ac.uk: the relevant package is
                    /hpux9/Networking/IPmult-1.0.tar.gz]

The distribution consists of kernel libraries, pre-built kernels
and the source for a multicast router.


-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 11:14:37 -0000
From:      adam@kbss.bt.co.uk (Adam BJ Quantrill)
To:        comp.protocols.tcp-ip
Subject:   xti libraries

Are there any PD xti libraries out there running over TCP/IP? I'm targetting
Sun SPARC and Sequent, but am willing to port.

Thanks,
	- Adam

-- 
| Adam Quantrill    | ,-|  | E-mail:  adam@kbss.bt.co.uk | *!> Not the views |
| QCL, 61 Akeman St,| | |  | U-hail: +44 473 293856      | *!> of BT         |
| Cambridge CB4 3HE | `-|  | Contracted to: BT (again)   |                   |
| +44 223 323409    |   `- | Home Email: adam@maxwells.demon.co.uk |         |

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 21:32:42 -0500
From:      reh@cs.umd.edu (Richard Huddleston)
To:        comp.protocols.tcp-ip
Subject:   Multinetting ( IP MUXes ) ?

Am I the only one who's clueless about something I've heard
about called Multinetting -- an IP MUX that can handle some
unspecified number of connections using a single IP address?

If I'm not the only one who's clueless, any pointers or
references would be greatly appreciated.

Thanks, and I will post a summary of any responses within 
10-14 days. 

-- 
Richard Huddleston  : Go, brave ones, past those who call shores their home 
Personal opinion(s) :     you need not see their face again 
and/or              : For you sail towards things not known before, or fail 
correspondance      :     and you will die in good company         (C) 1993 

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 13:49:24 GMT
From:      bernhard@trick.ani.univie.ac.at (Bernhard Strassl)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

In article <wdawson.758730986@willard.atl.ga.us>, wdawson@willard.atl.ga.us (Willard Dawson) writes:
|> bernhard@trick.ani.univie.ac.at (Bernhard Strassl) writes:
|> 
|> >I would suggest the following:
 
|> >3) "UNIX Solution"
 
|> >  PC ---------------------- LAN or WAN ---------------- Relational DB
|> >  (running UNIX)                                       (Sybase/Oracle)
 
|> >Then you are able to have the clients running on both sides with
|> >less troubles. If you still need DOS - nearly ervery PC UNIX provides
|> >a stable DOS emulatior. Most MS-Windows stuff should run pretty good
|> >under SUN's WABI (I couldn't test this myself up to now, but I hope to
|> >get it soon).
|> 
|> My attempts to install PowerBuilder under WABI result only in crashing
|> WABI.  The effect is *immediate*.  So, if you're expecting to run "most
|> MS-Windows stuff" under WABI, I believe you're being extremely
|> optimistic.
|> 

Sorry, I did'nt specify which kind of applications I expect to run
under WABI:

Non-client/server end user programs like word processors, spreadsheets,
drwaing programs etc.

These are the Windows apps which many UNIX users are missing on their
system because of the extremely high pricing of aequivalent UNIX products.
(i.e. compare WordPerfect for MS-Win and WordPerfect for SUN)

I do NOT expect databases and Windows GUI development stuff running
under WABI - maybe it does someday, but I prefer developing new
applications under UNIX...

-bernhard

---------------------------------------------------------------
The Xm++ / CommonInteract Project
Vienna User Interface Group
Bernhard Strassl              University of Vienna
xmplus@ani.univie.ac.at       Dpt. for Applied Computer Science
                              and Information Systems
---------------------------------------------------------------

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 03:29:33 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Socket/TCP/IP calls hang in the OS



Environment is: SVR4.2 UnixWare/Consensys AF_INET socket using the 
SOCK_STREAM (TCP/IP) protocol.

I've written a set of library functions that wrap the Berkeley socket calls
to make it easier for application programmers to use UDP/IP and TCP/IP
for packet oriented IPC services than more traditional Unix IPC facilities.

My problems arise in the TCP/IP protocol when the circuit flow controls
due to being pumped full by the writter filling up the system buffers
faster than the reader can empty.  I've tried to protect the write side
by calling ioctl(fd, I_CANPUT prior to actually calling send/sendto().
This still is not sufficient to prevent a potientially blocking situation
for the send(). 

I've set the send and recv buffers to 32k via the call;
setsockopt(fd, SOL_SOCKET, SO_SNDBUF, etc..  Does this make sense in 
SOCK_STREAM protocol??

The symptoms are:  
	1. Either the client or server sides can hang in various system
	   calls, imune to kill -9 etc.  

	   I've used truss to find clients stuck in:

		write(socket fd,,  about 1k buffers being written.

			Write blocking makes sense if there are no system
			buffers available,
			but imune to kill -9 ?? why.  How can I prevent
			an application from hanging??

		exit(0)
			My test application called exit, when there where
			open fd's with available data no doubt.  But why
			should exit hang when there where open fd's??

		ioctl(socket fd, I_STR,,
			It seems that the top streams module gets hung and
			sending messages down stream hangs the caller??
			
I've allowed for asynchronous use of this API where SIGPOLL signals the
arrival of new data etc. additionally, on the write side I call 
ioctl(fd, I_CANPUT,,).  Even when this ioctl() indicates it's safe to
write, some writes will still block for ever.  Necessitating a re-boot.

It seems that the Lockman & Assoc.'s implimentation of the TCP/IP etc 
protocol stack has many holes and catch 22 situations that I'm excersizing??

Is there a way for me to avoid getting hung??




-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 15:07:45 GMT
From:      Scott W Brim <swb1@cornell.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Cu-See-Me

Karen, FTP to gated.cornell.edu, and look in directory pub/video.

You should look in the README to get real answers to your questions, but 
let's start by saying it currently runs on Macs.  The PC version is more 
than half done (it receives pretty well and they're working on sending); we 
might do an X version.  It's intended to be low-cost, low-bandwidth, 
high-compression video, along with other things like sending stills in a 
separate window (we're building an "auxdata" plug-in interface so you can 
do just about anything with it, if you really want to).  As to how it 
works, well, that's a longer mail file.  Take a look at it and if you 
still want internal details, let me know.

... Scott Brim

In article <klinde.19.2D36CE42@silver.sdsmt.edu> Karen Linde,
klinde@silver.sdsmt.edu writes:
> Can someone point me to the source for this video conferencing software 
 ; 
> Cu-See-Me  (all I know is that it's available from Cornell). Also, can
 you 
> give me a general discription of what it is, what it runs on, and how it
 works?

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 1994 18:31:35 GMT
From:      evansmp@mb48025.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Does anybody have mods to tcpdump to decode Novell traffic?

Steinar Haug (Steinar.Haug@runit.sintef.no) wrote:
: We need to know a bit more about the Novell traffic on our backbone network,
: and I'd prefer to use some of our tested and proven tools for this, more
: specifically tcpdump. Does anybody have mods to tcpdump to decode Novell
: traffic, or do I have to write this myself?

Try ftp.novell.com for the IPX Router Specification (107-000029-001)
This will document IPX, RIP and SAP.
If you need NCP then you are on your own unless you have a very fat
wallet to wave at Novell.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 18:42:48 GMT
From:      ekwan@leland.Stanford.EDU (Edwin Kwan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   FTP Problem in Only One Direction

Hi,

	I am having a problem with FTP using CSLIPPER 1.3 and
QVTNET 3.4 through a SLIP connection.

	Everything is fine with the transfer from Unix to PC 
(both ASCII and Binary).  But when a file LARGER THAN APPROXIMATELY 
1K BYTES is transferred from my PC to Unix, my PC says all the file 
has been transferred but never receives any (226?) Transfer Complete 
from Unix.  The FTP session seems to hang, but my modem continues
to receive blips of signals which I think QVTNET responds to.  This
stops when I kill FTPD in Unix, and when it is killed, the FTP window
of QVTNET shows the 150 Opening connection for .... again and displays
the message "Unrecognized server response" before it puts up the
Connection Lost dialog box.

	The problem is repeatable more than 90% of the time.  (ie. it 
occasionally, though rarely, works correctly).  Moreover, if I turn on
the FTP server in QVTNET and use Unix as a client to receive a file,
the same thing happens.  But if I press Ctrl-C after the session
"hangs", Unix displays 500 Command not understood and then the file
transfer is completed successfully.

	Could somebody tell me what is happening here?  Thanks!



Edwin Kwan


-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 94 18:52:26 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Questio on voice over TCP/IP

In article <2hfpfeINN7ah@early-bird.think.com> barmar@think.com writes:

   Thus, both of them have problems when the resources are near their limits.
   The TCP/IP people decided that signal quality could be sacrificed, while
   the phone company decided that connection completion could be sacrificed.
   But in both cases, the user is inconvenienced.

I think that's an astute observation.  That seems to be a pervading telco
assumption -- if it's not perfect it's not worth doing.

   Just as TCP/IP doesn't currently have a way for the user to request a high
   fidelity voice connection (yes, there are header fields for it, but they
   don't usually do anything useful in current nets),

Yes, you can't request a high fidelity connection, but you *can*
reject a low fidelity connection.  You just can't ask to have it
automatically restored when the fidelity goes back up again.

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 1994 20:39:00 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   Re: sendmail catatonia?

In article <CJJqLG.AnA@forge.tandem.com> scott@tandem.com writes:
>
>[I know it's bad form to follow-up to one's own postings, but...]
>
>I wrote:
>
>>I'm having a rather severe problem with sendmail - it runs for a few minutes,
>>no more than 5, and then goes completely catatonic.
>
>I've isolated it to being sensitive to my network configuration.  The system
>in question (Sun Sparc 1, SunOS 4.1.2, replicated also on 4.1.3) is dual-homed
>with three interfaces...  Two interfaces are on the same physical net, one
>on a Class B address (130.252.10.x) subnetted at 24 bits, the other on a
>Class C address (192.216.220.x) as an aid to transition.  The system has run
>in this configuration since November.
>
>Now, sendmail goes south whenever the Class C net is configured.  I tried
>de-configuring the Class C first, and sendmail's been running 25 minutes, vs
>no more than 5 previously.  I de-configured the Class B, reconfigured it as
>the Class C, and *poof*, sendmail dies.
>
>Any ideas welcomed.
>
>Thanks,
>
>-- 
>Scott Hazen Mueller, Tandem Computers     +1 408 285 5762  scott@dsg.tandem.com
>Unix System/Network Administrator, Email Postmaster and Usenet Administrator
>           Beware the Subjects bird, and shred/The serious Bandwidth!


Scott: I have X-posted this to comp.protocols.tcp-ip since it looks like that
is the area causing grief 

I hope this causes no offence ;-)
Leo


-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 94 23:21:39 GMT
From:      davek@melupl (Dave Kennedy)
To:        comp.protocols.tcp-ip
Subject:   Post to comp.protocols.tcp-ip - please mail reply

My apologies for doing this, but I've posted a few messages asking 
questions to this group over the past several months and have gotten 
no, absolutely zero, response.  I'm not sure if my posts are making it 
out to this group.  Would you send me e-mail if you read this?  

Thanks.
-- 
|   Dave Kennedy             UUCP:  {gatech,emory}!dscatl!melupl!davek |
|  Voice: 404-409-4575   Internet:  davek@melupl.atl.ga.us             |

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 1994 23:43:14 GMT
From:      plate@cdsmn.mn.org (Doug Plate)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Recommendations Sought: Network Shared Database


I was wondering if anyone can recommend a multi-user database program that
can be shared by both Mac and PC users over a network.  I know this
isn't the "PC/Mac shared network apps" newsgroup, but I figure these groups
are the best place to look for folks with mixed platform network experience.
I always prefer to get input from satisfied users rather than motivated
vendors :-)

I would prefer a UNIX TCP/IP based solution, as our LAN is currently set up
to support this.  Novell or even AppleTalk based solutions are also an option,
but would require additional LAN expansion before they could be implemented
as TCP/IP is the only protocol currently being routed to both the PC's and
the MAC's.

I've read the FAQ regarding 'Freely Available Data Base Systems', but it is
difficult to ascertain from that document, just how much work it would take
to implement any of those systems.

Basic specs: 
 Share customer info, ie. name, address, phone, types of installed equipment.
 Store and index customer call details.
 
User Interface:
 Anything from Telnet to a full blown GUI are fine.  Functionality is the key.
 The main client systems would be >System 7 on the Mac's and Windows on the 
 PC's, but a DOS interface would be nice too.
 
System Options:
 Access answers to frequently asked questions (expert system?).
 
As always, Freeware would be ideal, followed by Shareware, followed by NotVery-
Expensive-Ware, etc, etc, etc :)

How would WAIS, or Gopher serve in this type of application?

I know I'm asking for the world here, but I'm often surprised to find that
the world is at my finger tips! :-) !

Regards,
Doug Plate Sr.


-- 
//////////////////////////////////////////////////////////////////////////////
Doug Plate Sr.                                   plate@cdsmn.mn.org
Senior Design Technician, Dicomed Inc.           (612) 895-3244
//////////////////////////////////////////////////////////////////////////////

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 94 00:04:18 GMT
From:      percosan@lexington.rutgers.edu (Peter Percosan)
To:        comp.protocols.tcp-ip
Subject:   Bidirectional SOCKET throughput


Hello -

I have an interesting problem. I am working on an application that
sends data from one computer to another via a socket. When the data is
unidirectional, the data throughput is fine (plenty fast enough).


        +------------+           +------------+
        |            |           |            |
        | computer a | --------> | computer b |
        |            |           |            |
        +------------+           +------------+


I must now send data between both systems in a balanced fashion. By
balanced I mean that the number of reads and writes between the two
computers is nearly the same:


        +------------+           +------------+
        |            | --------> |            |
        | computer a |           | computer b |
        |            | <-------- |            |
        +------------+           +------------+

the problem here is that the performance goes right into the garbage!
I was wondering if this is a known "rookie" problem (this is my first
shot at this). Any pointers in helping my data throughput would (and
will) be greatly appreciated.

I am sorry if this is an FAQ type question.

Thanks in advance -

Peter Percosan
percosan@caip.rutgers.edu

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 00:25:11 GMT
From:      tnert@bisque.cc.utexas.edu (TNERT)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

In article <1994Jan17.212005.22484@mixcom.mixcom.com>, mgic <mgic@mixcom.mixcom.com> says:
>
>
>I am seeking a means to implement on-demand, dial-up SLIP/PPP service.
>
>Requirements:
>
>        - Assign the IP address at the time of the call
>
>        - Record connect time stats
>
>        - Optionally monitor connect time usage so that when a limit 
>          is reached the user can be disconnected
>
>What hardware/software products will allow me to do this? Thank you.
>

I'm not sure, actually, but there was a discussion in one of the other news groups
about the use of KA9Q and PCRoute, both for DOS.  Both are available at 
oak.oakland.edu (pub/msdos/ka9q and pub/msdos/cad, respectively), and
both apparently allow users to dial up to a normal modem, connect to the server
using SLIP, and then connect to other machines via standard ethernet.  


Here is the text of the note in the other group:

From: ashok@biochemistry.cwru.edu (Ashok Aiyar)
Subject: Re: MSDOS / Winsock SLIP server?
Date: Fri, 14 Jan 1994 01:40:13 GMT

In article <JU8025.94Jan13113624@thor.albany.edu> ju8025@csc.albany.edu
(Johannes Ullrich) writes:

>Anybody knows of a Public DOmain / Shareware SLIP server (SERVER!) for
>a PC? Preferably as a Windows Sockets application.

You could purchase a Windows TCP/IP implementation that supports
ROUTING such as Netmanage Chameleon on Frontier SuperTCP.  You
would then be able to dial-into an ethernet connected PC, and use
it as a SLIP router.

SLIP routing is not a application that can plug into any Winsock.  It
is my understanding that the underlying protocol stack has to support
multiple network interfaces, and routing between the interfaces.

For DOS, I would suggest that you look into PC-Route or KA9Q.  Setting
either up as a dial-in SLIP router is not too difficult, and should not
take more than a day or two of time, even for the uninitiated.


Later,
Ashok
--
Ashok Aiyar                        Mail: ashok@biochemistry.cwru.edu
Department of Biochemistry                       Tel: (216) 368-3300
CWRU School of Medicine, Cleveland, Ohio         Fax: (216) 368-4544
MIME Enclosures OK


Here is a listing of the KA9Q files at oak.oakland.edu (Simtel):

NOTE: This list was created on Sat Jan 15 10:41:50 EST 1994
Some files may have been added or deleted since that date.
See file pub/msdos/filedocs/aaaread.me for additional information.

NOTE: Type B is Binary; Type A is ASCII

Directory pub/msdos/ka9q/
 Filename   Type Length   Date   Description
==============================================
asmobj.msg    A     607  901115  Message from Phil Karn explaining ASMOBJ.ZIP
asmobj.zip    B    6766  920510  Compiled binary files for linking w/KA9Q NOS
bmexe332.zip  B   30898  900722  Electronic mail program for KA9Q TCP/IP
e920603.zip   B  189423  920606  KA9Q TCP/IP, NOS 920603 version, executable
expiry.zip    B   53196  901123  Expire for use w/NNTP and KA9Q NOS TCP/IP
intronos.zip  B   25100  920426  Intro to TCP/IP on amateur radio by ag9v
ka9qbgn.zip   B  190366  910518  Beginner's guide for KA9Q TCP/IP (NOS version)
man-9106.zip  B   57169  910611  Documentation for NOS version of KA9Q TCP/IP
nan24hyc.zip  B   42635  910214  Enhanced ANSI.SYS replacement for KA9Q TCP/IP
nos-slfp.zip  B  310211  911026  NOS vers. of KA9Q with Merit SLFP/PPP support
pcelm321.zip  B  215109  940111  Mailer for NOS, UUPC, WAFFLE & other systems
pktdrvr.inf   A     157  920117  Pointer to the latest Crynwr packet drivers
s920603.zip   B  656302  920606  KA9Q TCP/IP, NOS 920603 version, source code
slfp123.zip   B   30476  910503  SLFP driver for use w/KA9Q and Merit dial-up
view9302.zip  B  373399  930907  Electronic mail program for use w/KA9Q TCP/IP


Best of luck!

Trent Stevens  71172.535@compuserve.com

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 11:01:50 -0500
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: CNAME same as Domain name - OK?

In article <2hjgp6$dc0@ulysses.iol.ie>, Barry Flanagan <barryf@iol.ie> wrote:
>Hi,
>
>Is it OK to set up a CNAME entry which is the same as the domain name? I 
>would like people to be able to telnet to "iol.ie" rather than having to 
>include a host name at all.

No, it is illegal and your nameserver will probably do bad things if
you attempt it.

Make "iol.ie" an A record the same as one of your machines that you
would have pointed the CNAME to.

--Dave
-- 
"I'm not a member of any organized party, I'm a Democrat." - Will Rogers

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 03:21:59 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses

baji@bnr.ca (Baji Edupuganty) writes:
}> I'm working on an application that will key off of IP addresses; therefore
}> I'm looking for a hash alg. that will hash IP addresses to something in the
}> range 2000. Anyone, know of any PD algs, or code that I can leverage? Any 
}> help will be appreciated. My e-mail addr is "baji@bnr.ca". Thank you.

   I did a simple test, and it would seem that a simple scheme is
   likely adequate.  I collected the addresses of all active
   connections on one of our big systems.  Unfortunately, I only
   had 46 unique addresses to play with.  I treated the addresses
   as an unsigned integer.

      ipaddr % 2000    gave 46 buckets of 1 (quite expected)

      ipaddr % 64      gave 25 buckets of 1, 7 buckets of 2, 1 of 3, 1 of 4

      ipaddr % 61      gave 21 buckets of 1, 11 of 2, 1 of 3

   Doing:

      (a ^ b ^ c ^ d) % 64   gave 24 of 1, 11 of 2

      (a ^ b ^ c ^ d) % 61   gave 21 of 1, 11 of 2, 1 of 3

So much for the "conventional wisdom" of using a prime modulus...


John


-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 04:19:49 GMT
From:      jamie@clark.net (Jamie H. Clark)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

mgic (mgic@mixcom.mixcom.com) wrote:

: I am seeking a means to implement on-demand, dial-up SLIP/PPP service.
 
: Requirements:
 
: 	- Assign the IP address at the time of the call

Xylogic's Annex can do this.  Use 'acp_dialup' file.

: 	- Record connect time stats

We use this via Annex syslog.

: 	- Optionally monitor connect time usage so that when a limit 
: 	  is reached the user can be disconnected

Maybe could do in Annex with some kind of hack.  Why not charge the
user rather than forced disconnect?

: What hardware/software products will allow me to do this? Thank you.

Xylogics's Annex.

Welcome!

: Dean
: -- 

--
Jamie Clark, jamie@clark.net| ClarkNet Public Access Internet, info@clark.net,
Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 15:22:00 -0600
From:      gpalo@sun075.dsccc.com (Gerry Palo)
To:        comp.protocols.tcp-ip
Subject:   Looking for TLI Source

I am looking for the source code for the TLI interface to TCP
in order to port it to Stratus/VOS.  Does anyone know of a source
for this, either vendor or public domain?

Thanks in advance for any advice.

Gerry Palo

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 12:48 MST
From:      gavron@hearts.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <2hjp6t$3cn@hercules.neu.sgi.com>, ove@yoyo.neu.sgi.com (Ove Hansen) writes...
#I've noticed that transferring files over slow links (serial or WAN) 
#using NFS is far slower than using for example ftp, even though the NFS
#parameters have been changed to avoid timeouts and re-transmissions. 
#How come NFS seems to be so inefficient compared with other file transfer
#methods? Has anyone made any analysis of how efficient different 
#methods of transferring files are, both in terms of total elapsed time
#and network overheads?

	NFS uses 8192-byte UDP packets with its own retransmission
	specifications.  FTP uses 512 byte (576 including header) 
	TCP packets.

	Typically 'slow' links (ala SLIP) also have small MTUs meaning	
	that the NFS packet needs to be multiply fragmented, whereas the
	FTP packet can travel unhurt.

#Ove Hansen - Network Administrator                 e-mail: ove@neu.sgi.com

	Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 06:41:07 GMT
From:      ahh@cisco.com (Andy Heffernan)
To:        comp.protocols.tcp-ip
Subject:   Re: Multinetting ( IP MUXes ) ?

In article <2hi64a$gm8@bedrock.cs.umd.edu> reh@cs.umd.edu (Richard Huddleston) writes:
>Am I the only one who's clueless about something I've heard
>about called Multinetting -- an IP MUX that can handle some
>unspecified number of connections using a single IP address?

You may want to check out the following Internet drafts:
	draft-cameron-tmux-01.txt
              Transport Multiplexing Protocol (TMux), Cameron/Crocker
	draft-cameron-cmp-01.txt
              Connection Multiplexing Protocol (CMP), Cameron/Bates

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 13:50:39 +1030
From:      simon@wraith.internode.com.au (Simon Hackett)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multi Cast

cake@cs.tu-berlin.de (Carsten Krebs) writes:


>Hi,
 
>I have to report about IP Multi Cast and I'm searching for examples 
>or references to books explaining IP Multi Cast.
>Does anybody know something about it ?
 
>	Bye,
>-- 

Try reading RFC1112. That's the primary definition and implementation guide.

Simon

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 94 19:00:55 PST
From:      marcus@cpva.saic.com (Mark Jenkins, SAIC/CIR Network Services)
To:        comp.protocols.snmp,comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Net Mgmt Sys Eval Guide Template (450 lines)

(This is a fairly long posting [450 lines], please skip if you are
not interested in Network Management Systems)

I would like to receive constructive criticism on this template so
that I can improve it.  I have posted this to comp.protocols.tcp-ip,
comp.protocols.snmp, and comp.dcom.sys.cisco (because my net is
Cisco-based and I like the newsgroup).  I am sure some people will
find this useful, and I don't think it is so long that it is obscene to
post it, so here goes...  If you think otherwise, I apologize in
advance.

Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views don't perforce match yours.
SAICnet Logical Network Manager    | My opinions aren't perforce SAIC's.
SAIC, San Diego, CA (619) 458-2794 | I take responsibility for my iguana.
----------------------------------------------------------------
          Network Management System Evaluation Guide Template

This template has been developed primarily to help evaluate
graphically-oriented Simple Network Management Protocol (SNMP) Network
Mangement Systems (NMS).  It serves as a template for developing an NMS
evaluation guide.  The NMS evaluation guide should identify NMS
requirements, provide a format for evaluating how various products meet
the requirements, and provide a format for reporting the NMS
evaluations.

I think the term "Network Management System" has been applied rather
broadly.  It includes systems with a wide range of capabilities from
DOS-based programs capable of monitoring the status of a Novell file
server up to high-end workstation systems capable of monitoring and
managing a wide range of network devices and end-user systems.  In this
guide template I make a distinction between systems designed primarily
to monitor and manage end-user computers over the network and systems
designed to monitor and manage the devices that actually comprise the
network, possibly including end-user computers.  I am currently mostly
concerned with systems of the latter type, with little emphasis on
monitoring/managing end-user computers.

My approach in evaluating network management systems is:

o Develop an NMS evaluation guide using this template; the main
  difference between this template and a guide developed from this
  template will be the specific requirements for the desired system.  I
  wanted to create this template to help identify what functionality
  exists in the marketplace today so that the requirements list would
  be somewhat based on reality.  Without surveying the marketplace, a
  requirements list might be too short sighted (Gee, I didn't realize
  that so-and-so's NMS did all that!) or it might be too ambitious (No,
  complete multi-vendor network management is not yet available in a
  $15,000 NMS).
o Evaluate a fairly small (3-5) number of systems pre-selected by my
  overall knowledge of the marketplace and the requirements identified
  already
o Review the requirements list with respect to how many systems met
  various requirements and what new (previously unknown) functionality
  exists which may be of great benefit to my organization
o Re-evaluate the pre-selected list of systems to match their
  functionalities with any new requirements
o Write an evaluation report
o Choose a system

There is a widely-used breakdown of network management functions
(defined by the ISO for OSI management) which should be provided by
network management systems.  This breakdown is: Fault Management,
Accounting Management, Configuration Management, Security Management,
and Performance Management.

I think this breakdown provides a good way of thinking about what areas
must be covered by network management, but it is not necessarily a good
way of evaluating today's network management systems.  Network
management systems provide some of these capabilities, but not all of
these areas are as well defined as I would like.  In addition, some of
the fields require much more integration across the network than is
currently possible.  For instance, Accounting Management: On a
multi-user timeshare computer the manager controls what users have
accounts, when they can use those accounts, how much the users can
consume in terms of resources such as CPU and disk, and keeps track of
how much they do consume in resources so that they can be billed. 
Today's network infrastructures don't support this, even in a
non-standard fashion.  Some of the pieces are there, but there is no
cohesive whole.

I think that for the purpose of evaluating current Network Management
Systems, NMS features can be deviced as per the following list:

o Intended Scope/Cost of the system
o SNMP capabilities
o Multi-user features
o Multi-system capabilities
o Network status monitoring
o Alarm processing
o Alarm monitoring
o Information display
o Data collection, management, and reporting
o Device configuration management
o Network configuration management


Intended scope of monitoring/management of the system

A key part of the requirements list for an NMS is the identification of
the intended scope of the NMS.  A system destined to provide management
for a couple of 10BASET hubs on a small (10-50 user) network with a
Novell fileserver will not need the same capabilities as a system which
will support a 3000 user network comprised of 20 LANs in 15 locations
across a WAN with hubs, bridges, routers, CSU/DSUs, servers, etc.  The
identification of the scope will help set expectations for the features
and capabilities of the system.

At a minimum, this identification should include:
o Who will use the system
o Where the system will be located
o Allowable price range of the system (as vague or precise as necessary)
o A list of devices to be managed by the system (include how many of
  each type, and identify the importance of managing each kind of
  device)
o Any limitations which will be imposed on the system

A basic decision must be made between an NMS capable of managing many
vendor's devices or a single vendor's devices.  Systems developed by
vendors to manage their own equipment are usually superior than any
other systems when managing that equipment.  However, most networks are
built using equipment from two or more vendors.  Separate management
systems can be used, one for each vendor's equipment, but it is often
desirable to provide some level of overall management for all devices. 
Perhaps the ideal situation is to have one NMS which can integrate
vendor-specific applications into one system.  This seems to be the
direction many multi-vendor networks are taking.  However, the ability
for a single system to be all things for all devices can be oversold. 
You must decide if the functionality present in using several
vendor-specific systems is better than the overall integration available
in a single multi-vendor system.  I envision that many ntworks will end
up with the following:

o A multi-vendor framework NMS with APIs and custom vendor or
  task-specific applications
o One or more special purpose vendor or device-specific NMS for devices
  which can't be adequately supported by the integration NMS
o Devices which are managed by TELNET shells or console port
  configurations

That's real life.


SNMP Capabilities.

Since this guide is geared towards evaluating SNMP-based management
systems, SNMP capabilities are very important.  SNMP is a protocol
developed for network management by the Internet folks.  In its original
form, SNMP provided three basic actions: GET, SET, and TRAP.  A GET
action retrieves information from a managed device, a SET action writes
information to a managed device, and a TRAP is sent from a managed
device to a management station (much like an interrupt in a computer
system).  SNMP is being (has been by now?) re-architected to address
some shortcomings which kept it from being used as widely for management
(through SET commands) as it was being used for monitoring (through GET
commands).  There are other technical issues being addressed as well. 
Ultimately, though, you will need to decide if you need SNMP version 1
capabilities or SNMP version 2 capabilities, or both in your NMS.  For
more information on SNMP, see RFCs x,x,x,x and x.  Also see "The Simple
Book", by Marshall T. Rose.  It will really help your evaluation process
if you are familiar with how SNMP works before proceeding.

In addition to the basic choice between SNMP v1 and SNMP v2 (or both),
you will have to decide what Management Information Base descriptions
(MIBs) you will be managing.  The SNMP standards include some standard
MIBs; others have been developed by vendors for greater control over
their equipment (enterprise-specific MIBs).  What MIBs do you want to
have pre-loaded in your NMS?  Do you want the capability to add in other
MIB definitions as provided by different vendors?  How easy is it to add
in those definitions?  Do you have to pay the NMS vendor to do it, or
does the NMS have an application which is easy to use, can read the
standard MIB definitions, and will "Do the Right Thing" with them?

Finally, security is of importance in network management.  You should be
able to modify configurations on your devices, but you don't want the
rest of the world (or even the rest of your organization) able to change
those configurations.  SNMP v1 had a 'password' level of security using
something called a "community string".  While this could have been a
fairly secure method of protecting configurations (and is used by many
vendors for just this purpose), it had problems in that community
strings are often easily viewed in device configurations.  Other
problems include the fact that the community strings are sent in 'clear
text' (unencrypted form) over the network, making it possible for
network snoops to grab your configuration password and do evil things to
your network devices.  These people do exist, although they do not seem
to exist in quite the numbers that some people think they do. 
Unfortunately it only takes one to make your life hell.  SNMP v2 is
going to address this issue in more detail, hopefully encouraging
vendors to provide true standardized interfaces for monitoring and
management of hardware.


Multi-user features.

It is often advantageous to have an NMS accessible by multiple people,
either simultaneously (requires an NMS based on a multi-user platform,
not a PC) or one at a time.  There are different ways in which an NMS
can be 'multi-user'.  Check carefully to make sure that multi-user
features work well.  For instance, some NMSes support multiple users,
but only the first user running the NMS gets any alarm messages.  Here
are some questions which should be answered by your evaluation:

o Should the NMS be usable by more than one person simultaneously?
o Should all simultaneous users be able to monitor the network (ie
  receive alarms, review logs, etc.)
o Should all users have management capabilities? (ie be able to change
  device configurations)
o Should all users have NMS control capabilities? (ie be able to modify
  the configuration of the NMS itself - add maps or devices, change
  monitoring thresholds, etc.?)
o Should monitoring, management, and control capabilities be
  configurable on a per-user basis?  Should there be multiple levels of
  control? (Ie user A can monitor and manage, user B can monitor,
  manage, and control)
o Should monitoring, management, and control capabilities be
  configurable on a per-user/set of devices basis? With multiple levels
  of control? (Ie User A can monitor all devices, but only manage devices
  at location Alpha, User B can monitor and manage devices only at location
  Beta).
o Should network views be limited on a per-user basis? (Ie User A can
  only devices at Location Alpha, User Beta can see devices at Location
  Alpha and Location Beta, User C can see all devices on the network).
o How should the multiple users access the system - X terminals logged
  into a single NMS machine? - Special NMS applications running on PCs or
  workstations which are clients of an NMS server or servers?


Multi-system capabilities.

Most enterprises have more than one network management system.  These
systems may be from different vendors, or they may be from the same
vendor.  If a network is large, there may be two or more control points
for the network.  Does each control point have its own NMS?  Can each
location's NMS talk to each other or to one master NMS?  How are
monitoring, management, and control issues handled between the multiple
systems?  Some questions to be addressed in the evaluation guide follow:

o Should the NMS interoperate with multiple systems from the same
  vendor?  from different vendors?
o If the NMS can interoperate with other systems (same vendor or
  different vendors), should one station be the master, the others
  slaves?  Should they interoperate as peers?
o Should multiple NMSes share information like alarms?
o Should multiple NMSes share management control?  Can these NMSes
  designate which NMS manages which portion of the network?  Can this be
  dynamically updated for 'follow the sun' management?


Network status monitoring.

Most NMSes are at least capable of monitoring functions.  That is, they
can provide information about network devices obtained in a 'read-only'
fashion.  At its most basic level, this would be reachability
information - a device would be considered reachable ("UP") if a simple
connectivity test such as a PING or an SNMP GET succeeds.  Higher levels
of monitoring could include more complex device testing to mark a device
as trouble-free, with various methods of indicating problems such as
high error rates, low disk space, etc.  Network links could be monitored
separately from devices - this would help determine when a network path
was down even though there was a redundant path to all of the network
devices.  Other status information, such as bandwidth utilization, or
packet processing information, could be monitored and displayed using
a basic network map or through special tools.  Here are some questions
to be answered in an evaluation:

o Will the management system be used to monitor real-time status of the
  network and network devices?  Simple reachability or more complex device
  statuses?
o Should the management system monitor links separately from devices to
  help determine when one of several redundant paths goes bad?
o How many devices will need to be monitored today?  In one year?  In
  five years?  Differentiate between devices that will be in the map but
  not actively monitored, as this can make a big difference.
o What kinds of status should be monitored in addition to simple
  reachability? Traffic levels, rates - Error rates, errors to packets
  ratios - CPU utilization levels - bandwidth utilization levels - disk
  space on computer systems?  Be sure to identify where status
  monitoring will require resolution of mathematical expresions using
  variables obtained from managed objects - can the NMS handle those
  calculations?
o How should changes in status, or various status levels, be signaled?
  Alarm mechanism (generate alarm) - flash icons - change icon color -
  change other graphic indicators - send mail, activate pagers, other
  actions?


Alarm processing.

Alarm processing is what happens when the NMS receives an alarm, either
from a managed device or generated internally based on threshold
monitoring.  Here is a list of alarm processing actions which should be
part of an evaluation:

o What kinds of alarms should be handled? SNMP traps - Other kinds of
  alarms from non-SNMP devices - traps or alarms generated internally by
  threshold monitoring?
o How should alarms be handled as they are received by the NMS?  Log
  alarms to a file or files - log alarms to database - cache in on-line
  log and signal through blinking icons, lights, bells, whistles -
  generate mail messages, activate pagers, or cause arbitrary commands or
  command scripts to be executed?
o Should alarms be handled using multiple actions when received (Ie log
  to database, log to on-line cache, and blink the related device icon?)
o Should different alarms cause different actions or combinations of
  actions? (Might be known as 'alarm filters)
o If different alarms should cause different actions, how are these
  actions controlled? Select actions by individual device - select actions
  by device type - select actions by device class or classes as
  determined by network manager (ie based on location, device
  importance, etc.) - select actions by alarm types?  Should
  combinations of the above be used to select alarm actions?


Alarm monitoring.

Alarm monitoring is the overall process of analyzing the types of alarms
being received, the quantity of alarms being received, and initiating
actions based on multiple alarms.  It is related to alarm processing in
that alarm processing handles single individual alarms; it can be viewed
as meta-alarm processing.

o Should the system provide any kind of alarm monitoring such that
  multiple alarms cause special actions?  For example, repetitive 'soft'
  failure alarms might generate a higher priority 'impending hard failure'
  alarm.
o Should multiple hard failures be reduced to a single alarm that
  identifies a single point failure based on the NMS's knowledge of the
  network and how devices are interconnected?  (Note: NMS may provide
  this sort of alarm correlation during alarm processing and not as a
  'meta' alarm processing function in general)


Information display.

A key component of an NMS is how the NMS information is presented to the
network operators and managers.  In this case, the information
presentation to be examined is at the user-interaction level.  We are
not concerned with reports, etc.

o Should the NMS provide a graphical interface?  The industry seems
  geared towards providing this fairly intuitive form of information
  presentation, but there may be lower-cost NMS applications which are
  quite useful despite their lack of a graphical front end.  However,
  this analysis guide is geared towards graphical display applications.
o Should the NMS display conform to standards such as the X window
  system, display PostScript, etc.?  If so, which ones and why?
o Should the graphical display provide the ability to construct network
  map diagrams?
  - Should the map display have hierarchical levels?  How should these
    hierarchical levels work?  How should the be navigated?
  - Should map icons be 'intelligent', displaying information about the
    device or sub-map they represent?
    - Show device or map types through a selectable icon design?
    - Showing device or map state (by color, flashing, etc.)?
    - Show LAN or WAN traffic rates by miniature graphs or size indicators?
    - Show device or map outstanding alarm conditions?
    - Show link states as opposed to just device or map states?
    - Show relative WAN link traffic rates in realtime through utilization
      indicators such as line thickness?
o Should the NMS provide a graphical front-end for device
  configurations?  Customizable?  Allow third-party products to provide
  the graphical front end?
o Should the NMS provide any real-time monitor graphing capabilities?
  - Should these graphs be printable as well as viewable on the screen?
  - Where should graph data be sourced?
    - Real-time from network devices?
    - Real-time from special network taps or pods?
    - Historical information from a database of collected info?
    - Historical information from alarms logs (ie graph alarm types and
      quantities over time)?
  - When graphing, should the graph be capable of displaying more than
    one variable at a time?  With different scales?
  - Should the graph be able to combine multiple input variables using a
    mathematical expression to general the graphed variable?  (For
    instance, use InputErrors/InputBytes to generate a real-time error
    ratio graph)
  - Should the graph be capable of displaying more than one variable at
    a time with variables calculated from multiple input variables?
  - Should the graph be able to take variable or device descriptions
    from device MIB variables and use them to identify the graph or the
    variables on the graph?
  - Should 'canned' graphing configurations be provided?
  - Should the user be able to construct graphing configurations and
    save them for use on multiple devices?


Data collection, management, and reporting.

o Should the NMS be able to collect data at set periodic intervals from
  devices?  Collections of devices with one collection instance?
o Should the NMS store collected data in a flat file?  A database? Both?
o Should the NMS be able to archive data from the database for long-term
  storage?  Should the archive be controlled by time, by device type, by
  data collection group, by network segment?
o Should the NMS be capable of supporting different data collection
  schedules for different collecton instances?
o Should the data come from SNMP MIB variables or proprietary protocols?
o Which MIBs must be supported?  MIB II, various enterprise-specific
  MIBs?
o Should any pre-configured reports be provided?  Should pre-configured
  reports be customizable?
o Should the system be able to develop new customized reports using
  collected data?
o Should report generation from collected data be schedulable (ie so
  that the reports are generated on a regular basis without manual
  activity)?
o What should the reports include - tables, graphs, other means of
  presenting information?  Can report tables and report graphs combine
  multiple variables, with mathematical expressions, with labels generated
  from other variables?
o Can reports combine information from multiple sources - archived data,
  alarm logs, etc.?
o Does the report utility provide summary information from tablular
  info?


Device configuration management.

Device configuration management consists of changing device
configurations, tracking changes to configurations, and saving device
configurations for backup purposes.  For most devices, really good
device configuration management probably requires a custom management
application written by the device vendor.  This application may or may
not be part of a broader network management system.  What capabilities
do you need in your NMS, either directly or with an add-on application?
These questions need to be asked and answered for all of the devices you
intend to manage with the NMS.

o Can you change device configurations?  Using SNMP SET or do you have
  to TELNET to the device from the NMS?
o Is the configuration portion of the NMS graphically oriented?
o Can you customize the screens used for device configurations?
o Does the NMS track changes made to device configurations?
o Does the NMS store a complete backup of the device configuration? 
  This can be very useful for hardware swaps to fix problems.
o Does the NMS allow you to track hardware and software versions for
  various devices automatically?


Network configuration management.

Network topologies change and devices used within the network change.
Should the NMS track these changes in some fashion?  What parameters
should the NMS store to track network configurations?

o Individual device repair records, failure records, etc.
o Device replacement history
o Network map histories
o Network traffic load/performance histories?


This is the end of the Network Management System evaluation template.

Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views don't perforce match yours.
SAICnet Logical Network Manager    | My opinions aren't perforce SAIC's.
SAIC, San Diego, CA (619) 458-2794 | I take responsibility for my iguana.

-- 
Mark Jenkins <Marcus@CPVA.SAIC.Com>| My views don't perforce match yours.
SAICnet Logical Network Manager    | My opinions aren't perforce SAIC's.
SAIC, San Diego, CA (619) 458-2794 | I take responsibility for my iguana.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 11:43:32 GMT
From:      jgavilan@tid.es (Fco Javier Gavilan Casado)
To:        comp.protocols.tcp-ip
Subject:   RFC 1323 implementation

Hello everybody:
I'm working about LAN internetworking using satellite links. I've had 
problems with TCP perfomance, and I found the RFC 1323 about TCP 
extensions for high perfomance. 
All is ok... . But the big problem
is that I don't know where this RFC is implemented. I'm using KA9q over PC
and SUNOS 4.3.1 over SUN. Is it necesary to make any change inside the
OSs? Is there any software which has RFC 1323 included? .

See you.

Javier Gavilan.


-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 13:19:06 GMT
From:      wongm@latcs1.lat.oz.au (M.C. Wong)
To:        comp.protocols.tcp-ip
Subject:   How to SLIP back onto the same machine ?

Hi,
  I am running FreeBSD 1.0 on a 486DX/33 with 4 COM ports (tty00-tty03).
My question is if it is possible to SLIP back to the same host say using
tty00 and tty02 with null-modem, instead of setting up a dial-up SLIP
connection ? The reason for me to do that is that I only have one machine
running FreeBSD, and I will like to test some softwares running over SLIP,
including ISODE.

  Can some kind soul please email a detail explanation to, say, set up  PPP
between tty00 and tty02 such that when I did telnet, ftp , rlogin etc, it
defaults to using PPP interface instead of lo0 ? Does it mean, I got to have
2 PPP interfaces, ppp0 and ppp1 ?

  Thanks in advance, and email replies please

- wongm@latcs1.lat.oz.au (M.C Wong)
-- 
- wongm@latcs1.lat.oz.au

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 14:40:38 -0000
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   CNAME same as Domain name - OK?

Hi,

Is it OK to set up a CNAME entry which is the same as the domain name? I 
would like people to be able to telnet to "iol.ie" rather than having to 
include a host name at all.

I can't really afford to mess with the nameserver to experiment with 
this, so would appreciate some guidance from the 'net!

Thanks.
-- 
Barry Flanagan - <barryf@iol.ie>
 ----
| Ireland On-Line, West Wing, Udaras Complex, Furbo, Galway,Ireland
| Tel/Fax : +353 91 92727 / 26 * BBS : +353 91 92711 (4 Lines)

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 94 15:00:29 GMT
From:      cnbr73@vaxa.strath.ac.uk
To:        comp.protocols.tcp-ip
Subject:   ESTELLE help

Hi,

I am looking for a PD or ShareWare ESTELLE compiler/intrepreter
for dos or windows environment. I searched SIMTEL20 with no luck.
I'd highly appreciate any info or pointer regarding it. Thanks
in advance.

Anwar

e-mail : cnbr73@uk.ac.strath

-- 

-------------------------------------------------------------------------------
     ____       __                        |  e_mail   
    /          / |                        |
   /---       /--|  __      _ __. ._      |  Janet    : CNBR73@uk.ac.strath
(_/     o  (_/   (_/ /_ |/|/ (_/|_/<      |  Internet : CNBR73@strath.ac.uk
                                          |___________________________________
Farhat Anwar,                             |  Phone
Communications Division,                  |    Office : (041) 552 4400 Ex-2082
Dept. of Electronic & Electrical Engg.,   |    Home   : (041) 558 6258
University of Strathclyde,                |   
204 George Street, Glasgow G1 1XW, U.K.   |  Fax      : (041) 552 2487
-------------------------------------------------------------------------------

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 23:33:08 -0500
From:      korz@news.cs.columbia.edu (Frederick Korz)
To:        comp.protocols.tcp-ip
Subject:   TCP behavior of various TCP/IP implementations on ICMP SOURCEQUENCH?

I'm interested in what various TCP/IP implementations do on receipt of
an ICMP SOURCEQUENCH message for a TCP connection.

I've already checked the RFC's (791, 792, etc) and the BSD Net/2 sources.

Net/2 and probably all of common heritage (BSD 4.3 descendants)
decode the message and call tcp_quench(), reducing the congestion
window to size 1.

What do other implementations (e.g. Ultrix, AIX, AUX, ...) _actually_ do?

 * Do they pass the QUENCH up to tcp?
 * What do these implementations have tcp do?

Fred Korz                       korz@cs.columbia.edu    (212) 939-7068
450 Computer Science Building,  Columbia University,    NY, NY  10027 (USA)

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 15:24:35 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses

In article <2hi90n$6vn@news.iastate.edu> john@iastate.edu (John
Hascall) writes: 
>Unfortunately, I only
>   had 46 unique addresses to play with.  I treated the addresses
>   as an unsigned integer.
 [...]
>So much for the "conventional wisdom" of using a prime modulus...

The "conventional wisdom" (from Knuth and others) assumes the domain
of the hash function is uniformly distributed.  I don't think IP
numbers are uniformly distributed numbers, especially in light of the
various subnetting and numbering practices in use today.

If you look at the number of connections that a server is likely to
have, then you can likely us the last 8-12 bits of the IP address as
your hash key, and have a table size of between 1024 and 8192 bytes
(assuming a 4 byte pointer to some data structure).  If you assume a
locality of reference (eg, most connections are local), this is likely
"good enougyh" for most applications.  If you can't assume that, then
this will likely produce skewd results because people like to start
numbering their machines with '1' and getting connections from all
over the internet will likely bump into this skewing depending on the
application.  Even so, it will still likely produce numbers that are
good enough.  If memory is cheap, then (ip >> 16) ^ (ip & 0xffff) will
likely produce hash buckets of depth 1 in almost all cases (at the
cost of 256K of memory).  To get even a 10% loading of a hash table
this size, you'd need 6553-odd connections, which is >> the 1024 limit
that most kernels impose.

[[ Sorry if this repeats earlier parts of this thread.  My news feed
   was disrupted and I have only seen John's article on the subject ]]

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 15:46:46 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <CJLIuq.DqA@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:

>Of course if you're making a PBX or central office switch, you're not
>going to pick IP datagrams for moving the voices around.  On the other
>hand, no one knows an excellent recipe for "multimedia" (although all of
>the currently best recipes use IP).  This talk of "isochronous traffic"
>is often political "technology" from people who have never tried digital
>pictures over TCP, UDP, ATM, or tight strings, and have no idea which if
>any of those protocols are remotely suitable.

Well said.  

  In fact yesterday I was using a 2400 bps voice application over
UDP/IP and it works fine.  We like the narrow-bandwidth stuff more
because it is easier to make work over 2400 bps Radio links that the
Navy has lots of, but very high quality voice/video/whiteboard
applications also exist.  The quality is directly proportional to
available bandwidth, IP doesn't use much overhead and so is ideal for
this sort of application.  Resource reservation extensions to IP will
make things work even more efficiently.

Ran
atkinson@itd.nrl.navy.mil




-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 15:51:08 GMT
From:      tony@scotty.dccs.upenn.edu (Anthony Olejnik)
To:        comp.protocols.tcp-ip
Subject:   How to administer IP address space?  Database/spreadsheet/?

What are some of the methods used to administer IP addresses?
How do some of the other places out there, keep track of your addresses?

In my particular organization, we use a custom (Ingres) database
application (running on a DEC machine running Ultrix). That way,
all authorize individuals can simply establish a telnet session
(from anywhere) to obtain a unique (and unassigned) IP address.


--tony

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 15:51:36 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <BMAH.94Jan14101642@propaganda.cs.berkeley.edu> bmah@propaganda.cs.berkeley.edu (Bruce A. Mah) writes:

>I think it's important here to distinguish the difference between
>using TCP/IP to carry voice and using the Internet protocols to carry
>voice.  Note that the MBONE uses UDP/IP, *not* TCP.  There's a couple
>of good reasons (among others):
>
>1.  It's kind of hard to do TCP as a multicast.

Yes.  Although it isn't clear how many users really want to have a
multicast transport protocol.  The existing examples (e.g. XTP, MTP)
have not taken off and are not widely used.

>2.  In many cases, if the audio/video/whatever data disappears, it's
>probably better not to try to get it retransmitted because it might
>take a long time, by which time the data would be useless.

Yes.  

  In fact, this is exactly why ATM Adaptation Layer 1 drops cells
without retransmission.  AAL 1 is intended for real-time voice, in
particular telephone calls.  


Ran
atkinson@itd.nrl.navy.mil


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 16:02:51 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <1994Jan17.144519.15703@mmm.mmm.com> ccg@tcdsp1.mmm.com ("Charles Ganzhorn") writes:

>Now, hang on Vernon, nobody made any political statements.  

Patently untrue.

> The idea here was to convey that TCP(UDP)/IP has no way of informing
> the media that it needs guaranteed bandwidth which is what you pretty
> much need to do QUALITY video and voice.  Nobody said that you can't
> do voice and video over current Internet technology but then no one
> said that you can do voice and video RELIABLY over current Internet
> technology.

	I keep mentioning the current IETF work on resource
reservation extensions to IP.  There are several prototype
implementations already.  Please do not ignore this ongoing work when
you make sweeping comments like the above.

	Now the issue isn't whether any service is fully reliable, the
issue is whether the service is _sufficiently_ reliable.  In practice,
the MBONE is *normally* reliable enough for me to participate in
networking conferences in Europe or Australia or California from my
desk here in DC.  Certainly it could stand improvement and needs more
research, but the existing service is surprisingly decent.  When we
get some resource reservation mechanisms, I think it will be much
better.

>The reason video phones never took off was because of the price of the sets
>and because of the bandwidth requirements.  Both of those restraints are being
>dealt with through smarter compression algorithms and through the general
>availability of cheap computer technology.

  Funny how those bandwidth needs are independent of which kind of
interconnection technology is being used.  Bandwidth is one of the big
issues in UDP/IP conferencing.

>As far as the video toys that are currently being sold, I can easily trash the
>transmissions of any one of them if I'm allowed to put general data traffic of
>sufficient magnitude on the same line.  

The same assertion is true for phone company technology, particularly
ATM which has horrible cell loss due to ATM switch congestion in
current commercial standards-compliant implementations.  ATM is not
going to eliminate the problem without additional R&D into ATM
technology.

Ran
atkinson@itd.nrl.navy.mil




-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 16:15:11 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: CNAME same as Domain name - OK?

barryf@iol.ie (Barry Flanagan) writes:

>Is it OK to set up a CNAME entry which is the same as the domain name? I 
>would like people to be able to telnet to "iol.ie" rather than having to 
>include a host name at all.
This is not allowed by the spec, and also not possible. The nameservers
did refuse this construct. Instead you could use a A record. Not as 
flexible as an CNAME but does its job.

Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-85748 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 17:04:29 GMT
From:      ove@yoyo.neu.sgi.com (Ove Hansen)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Why slower? NFS over slow links compared with rcp, ftp, mail

I've noticed that transferring files over slow links (serial or WAN) 
using NFS is far slower than using for example ftp, even though the NFS
parameters have been changed to avoid timeouts and re-transmissions. 
How come NFS seems to be so inefficient compared with other file transfer
methods? Has anyone made any analysis of how efficient different 
methods of transferring files are, both in terms of total elapsed time
and network overheads?

Thanks in advance,  
-- 
Ove Hansen - Network Administrator                 e-mail: ove@neu.sgi.com
Silicon Graphics Manufacturing S.A. (Switzerland)  Phone : (41-38) 433 535
Chemin des Rochettes 2, CH-2016 Cortaillod         Fax   : (41-38) 433 900

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 18:02:32 GMT
From:      chaoli@titanic.net.com (Chao-Li Tarng)
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP stack source code vendors

I am looking for TCP/UDP/IP stack source code to port to an M68k embedded
system.  I know about Doug Comer's code but I also heard it is "buggy".
I may incline to get a commercially supported source code.  Can anybody
recommend some vendors' names and provide experience with them?  


Thanks,
Chao-Li Tarng
--
===============================================================
Chao-Li Tarng, Ph.D.                      voice: (415) 780-5957
Network Equipment Technologies, Inc.      fax:   (415) 780-5001
M/S 23.2.3                                email: chaoli@net.com
800 Saginaw Drive, Redwood City, CA 94063 

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 94 19:07:07 GMT
From:      dsrekrg@prism.gatech.EDU (Rob Gibson)
To:        comp.protocols.tcp-ip
Subject:   Anyone successfully get FTP PC/TCP DOS 2.2 and MS Windows for Workgroups 3.11 to coexist?


Configured for NDIS.
The FTP side of things continues to function, but access to MS LAN Manager 
resources like print queues results in error messages reporting not enough 
memory.  The system has 16 MB RAM, plenty of hard drive space.  

-- 
Rob Gibson   ARPA: dsrekrg@prism.gatech.edu

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 19:19:21 GMT
From:      derekj@zip.sbi.com (Derek Jean-baptiste)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Novell LanWorkPlace 4.1 with SLIP and MSWindows

Netters,
	I am running a i486 with LWP4.1 the SLIP driver
and MSWindows 3.1.  When I startup  I
1) run lsl.com
2) run slip_ppp.com
3) dialup -T - then hook up my terminal connection over the modem line
4) run tcpip

Once I do this, I should be able to talk to my server via TCP/IP.  Guess what,
I can .  From DOS I can run ftp to my server and my server (unix box with
slip kernel) can ping and ftp to my PC.  The problem is, when I run
windows,  all of this functionality disapears and when I exit windows
this condition still persists.  Is there any way around this?  Can I use
the SLIP_PPP driver with windows and keep my tcpip services operational?

Thanks for any help,
Derek

---

 [The Above Opinions are MY OWN and NOT those of Salomon Bothers]
---------------------------------------------------------------------------
Derek Jean - Baptiste					"...End Racism..."
----------------------------------------------------------------------------
US Postal Mail		|E-Mail				|Phone
Salomon Brothers	|Zip	:derekj			|Work:(212) 783-1572
7WTC			|Salomon:derekj@zip		|FAX :(212) 783-4838
N.Y., NY. 10048		|I-net	:djeanbaptiste@sbi.com	|Beep:(212) 646-7200


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 20:00:48 GMT
From:      derekj@zip.sbi.com (Derek Jean-baptiste)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Novell LanWorkPlace 4.1 with SLIP and MSWi

Sorry Guys,
	I found the problem.  I had some modem software that
initialized the modem from system.ini.  This was of course breaking my
connection with my server every time windows came up.
Derek
In article juh@sbi.sbi.com, derekj@zip.sbi.com (Derek Jean-baptiste) writes:
>Netters,
>	I am running a i486 with LWP4.1 the SLIP driver
>and MSWindows 3.1.  When I startup  I
>1) run lsl.com
>2) run slip_ppp.com
>3) dialup -T - then hook up my terminal connection over the modem line
>4) run tcpip
>
>Once I do this, I should be able to talk to my server via TCP/IP.  Guess what,
>I can .  From DOS I can run ftp to my server and my server (unix box with
>slip kernel) can ping and ftp to my PC.  The problem is, when I run
>windows,  all of this functionality disapears and when I exit windows
>this condition still persists.  Is there any way around this?  Can I use
>the SLIP_PPP driver with windows and keep my tcpip services operational?
>
>Thanks for any help,
>Derek
>
>---
>
> [The Above Opinions are MY OWN and NOT those of Salomon Bothers]
>---------------------------------------------------------------------------
>Derek Jean - Baptiste					"...End Racism..."
>----------------------------------------------------------------------------
>US Postal Mail		|E-Mail				|Phone
>Salomon Brothers	|Zip	:derekj			|Work:(212) 783-1572
>7WTC			|Salomon:derekj@zip		|FAX :(212) 783-4838
>N.Y., NY. 10048		|I-net	:djeanbaptiste@sbi.com	|Beep:(212) 646-7200
>



---

 [The Above Opinions are MY OWN and NOT those of Salomon Bothers]
---------------------------------------------------------------------------
Derek Jean - Baptiste					"...End Racism..."
----------------------------------------------------------------------------
US Postal Mail		|E-Mail				|Phone
Salomon Brothers	|Zip	:derekj			|Work:(212) 783-1572
7WTC			|Salomon:derekj@zip		|FAX :(212) 783-4838
N.Y., NY. 10048		|I-net	:djeanbaptiste@sbi.com	|Beep:(212) 646-7200


-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 20:06:00 GMT
From:      chrisc@central.nmmc.mn.org (Christopher Cox)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   LAN Workplace for DOS & BOOTPD-2.2

Ladies & Gentlemen,

Has anyone noticed a problem with LWP4DOS (at LWP168 patch level) when 
learning its configuration using BOOTP?  Specifically, since upgrading our 
BOOTPD server to revision 2.2 or greater from 2.1, and enabling the newer 
options to return the client's hostname and domain (bootptab options 'hn' 
and 'dn=xxx.yyy') random PC clients (all Compaq 486/44 Prolineas with 
Compaq DOS 5.0 or 6.0, LWP4DOS , & NetWare) will lockup.

It seems that the lockups only occur when resolving an address using DNS.  
If ip addresses are specified using dotted decimal notation then all seems 
well.

If this has been observerd elsewhere, is there a fix available?

Thanks in advance.

Chris
--
Chris

   Chris Cox  W0/G4JEC                     chrisc@Central.NMMC.Mn.Org
   Network Analyst                                NIC Handle:   CC345
   North Memorial Medical Center                  Tel: (612) 520-7321
   3300 Oakdale Avenue North                      Fax: (612) 520-5237
   Robbinsdale, MN  55422

     ----- For mail of a more social nature, please use -----
           Internet: chrisc@moron.vware.mn.org
           Amprnet:  chrisc@biggus.g4jec.ampr.org


-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 21:04:12 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: X protocol over TCP/IP

In article <1994Jan15.143625.2046@ultb.isc.rit.edu>, cml0464@ultb.isc.rit.edu (C.M. Leung) writes:
|> Hello:
|> 	I have two questions:
|> 
|> 	X operates over TCP/IP.  Does it deal with both BSD and SYSV
|> interfaces or operate at a lower level?

Yes, the source code has both the BSD socket interface and the SYSV
poll/tli interface.  This is in both the server (display station) and
the clients (applications -- using Xlib).  The server sets up TCP listen
ports on 6000+x (where x is the display number for servers with multiple
displays), and applications connect to 6000+x where x is the number
after the colon in the DISPLAY variable.

|> 	Secondly, X protocol, as far as I know, most of the times buffers
|> requests.  What about entered characters?  Are these manipulated by setting
|> certain options over the sockets (if sockets are used at all) ?

I'm not sure I understand that question.

The X protocol is not too terribly complicated.  The server sends back
"events" for cursor motion, button presses/releases and key presses/
releases, et cetera, depending on state masks in each window.  These
events are fixed-size 32 byte chunks which include a lot of state
information (eg, time stamp, where the pointer was when the key was hit,
which control/alt/shift keys were pressed, et cetera).  Applications use
commands to tell the server which events are "interesting."

X doesn't really have a notion of "entered characters" -- it just has
"events."  Key up/down information is generally sent as scan codes from
the keyboard itself -- it's up to the client to decide if the user is
typing or firing his thrusters or whatever.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 21:48:37 GMT
From:      jdf@nitehawk.East.Sun.COM (Jim Fiori - Special Projects)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 implementation

In article 4950@tid.es, jgavilan@tid.es (Fco Javier Gavilan Casado) writes:
>Hello everybody:
>I'm working about LAN internetworking using satellite links. I've had 
>problems with TCP perfomance, and I found the RFC 1323 about TCP 
>extensions for high perfomance. 
>All is ok... . But the big problem
>is that I don't know where this RFC is implemented. I'm using KA9q over PC
>and SUNOS 4.3.1 over SUN. Is it necesary to make any change inside the
>OSs? Is there any software which has RFC 1323 included? .

SunIntegration Services has a consulting special called CONSULT-TCPLFN that
implements RFC 1323 for SunOS 4.X. It's a mod to the tcp driver in the kernel. In
addition, your TCP/IP application must turn on new options via setsockopt to take
advantage of the enhancements.

Send e-mail to  consult-info@sun.com with the first line containing 
"send index specials" for more info.

Jim Fiori


>
>See you.
>
>Javier Gavilan.
>








-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 94 22:40:57 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

Well, I'm being accused of  being political here and I guess my intent was to
point out that the current designs and implementations assume that the network
only infrequently becomes congested enough to interfere with the transmission. 
I'm lobbying for a design which would guarantee voice and video quality rather
than depending on capacity planning and luck.

It's not a matter of politics but rather I'm not as willing as everyone else to
sacrifice quality.  The postings have made it clear that congestion is handled by
degrading quality.  In a circuit switch environment, congestion is handled by
refusing service.  Now that is being interpreted as I have some vested interest. 
I do not. 

In current video conferencing, as long as the line stays up, I can expect the 
same level of quality for the duration of the call since I have a dedicated 
service.  In the current packet environments, there is a non-zero probability 
that the call will experience some sort of degradation.

What I guess I'm taking away from this discussion (and some 3M's had with
PictureTel, for example) is that everyone feels that with proper capacity
planning and, for example, switched ethernet hubs, I can reduce that probability
to a very small number.

I'm just saying that we are at a cross roads where new media are emerging and IP
has to be redone anyway due to the addressing crunch:  why not build in the
capability to offer circuit switch quality.  Is the answer that there will be
clear guidelines to reduce the probability of significant degradation?   Will I
be able to guarantee a certain level of quality?  Would you be willing to sign a
contract based on the figure?

Have any of you moved people from data PBX connections to ethernet using LAT or
TELNET or some other such?  If you have, you know exactly where I'm coming from. 
Never mind that the overall throughput is better via the network:  the customers 
get upset when they see uneven typing response 'cuz they're too used to having 
exactly the same response on each keystroke.  It is this sort of user perception 
that seperates the technical users from the business user:  business users don't 
want to hear excuses, they just want the thing to work and work well.  Technical
users will take "99%" perfect because they understand the tradeoffs.

Hopefully this clears up the politics issue.  I really was intending to discuss
this on the basis of technical merit.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 94 22:51:57 GMT
From:      gds@york.cs.ucla.edu (Greg Skinner)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <2hjp6t$3cn@hercules.neu.sgi.com> ove@yoyo.neu.sgi.com (Ove Hansen) writes:
>Has anyone made any analysis of how efficient different methods of
>transferring files are, both in terms of total elapsed time and
>network overheads?

There was a study of network performance done by Domenico Ferrari (I
think) of Berkeley sometime in 1988, I think.


-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 01:40:41 GMT
From:      jonathan@leland.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 implementation


In article <1994Jan19.114332.4950@tid.es>, you write:
|> Hello everybody:
|> I'm working about LAN internetworking using satellite links. I've had 
|> problems with TCP perfomance, and I found the RFC 1323 about TCP 
|> extensions for high perfomance. 
|> All is ok... . But the big problem
|> is that I don't know where this RFC is implemented. I'm using KA9q over PC
|> and SUNOS 4.3.1 over SUN. Is it necesary to make any change inside the
|> OSs? Is there any software which has RFC 1323 included? .

I hope that's a type for SunOS 4.1.3.

Thomas Skibo (then at UIUC, now at SGI) implemented
RFC1323 as patches to the networking code from 4.3BSD-Net2.
They are available via anonymous FTP, at:
uxc.cso.uiui.edu:/pub/tcplw.shar



Tim Seaver (tas@concert.NET) integrated these changes
into Net-2 derived TCP code and ported that to both
SunOS 4.1.x (which has essentially 4.3BSD-Tahoe networking
code), and to Ultrix 4.1 and 4.2. These are available via anonymous FTP
from ftp.concert.cert:/dist/tcp.sunos41+.tar and
ftp.concert.cert:/dist/tcp.ultrix4.1.tar


A slightly newer version of Thomas Skibo's code is in 4.4BSD;
use that, if you can.

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 02:11:55 GMT
From:      nam@peregrine.esl.com (Nam N. Nguyen)
To:        comp.protocols.tcp-ip
Subject:   UDP Packet size


I am using UNIX (SunOS4.1.3) version of TCP/IP (socket) to send data
from one workstation to another.  The problem is the packet size of UDP.

UNIX implementation seemed to limit this UDP packet size to a few Kbytes.

In my application, I would like to use UDP but to send a large packet
(video images of about 20-30Kbytes per compressed image).  How can I 
do this under SunOS or other UNIX-like environment?  

I do not want to split up my packet because I do not want reliable
service (as TCP or ACKNOWLEDGEMENT), so when a packet is lost, it can
be lost as a whole image.  If I split an imagery packet up, then there
is a high chance of losing a few packets of one image, and this is
no good.

Please help! (via personal email to nam@esl.com)

Thanks,

Nam N.




-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 13:53:46 -0600
From:      dpm@bga.com (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   Re: Admin of multiple SLIP lines?

Peter Espen <pespen@bbx.basis.com> wrote:
>
>I have heard of some large institutions providing dialup SLIP
>access for a large number of people.  How is this managed?
>Do such places assign unique IP addresses to everyone who
>wants dialup SLIP access?  Are IP addresses somehow dynamically
>assigned when someone dials in?

You can do either one or both (re: permanent IP address vs dynamic IP
assignment).  

Some terminal servers support both options (e.g., Cisco).  A lot of
large sites--especially universities--support SLIP by hanging banks of
terminal servers on the net and turning on dynamic IP support.  This
is probably one of the easiest options to manage.

One advantage of using dynamic IP assignments is the reduced
administrative load.  It can also simplify routing in some cases.  If
you support BOOTP, then a lot of client software can be setup to
automatically configure itself for the dynamic address.  I would guess
that dynamic IP serves the needs of probably ~90% of people who use
SLIP as a way to multiplex their terminal sessions and to utilize GUI
network clients on their home computer.

Most UNIX SLIP software doesn't directly support assigning or using
dynamic IP addresses, but it's certainly doable.  (Although you
typically have to modify the kernel drivers to support a BOOTP server
for SLIP lines.)

At Real/Time (a service provider in Austin) we support everything from
low-cost ($20/month or $135/year) dynamic-IP, time-limit-per-call
accounts up to permanent-IP, dedicated SLIP lines (starting at
$75/month).  There are options in between for permanent-IP dialup
accounts.  In our case, the modem lines are connected to banks of
BSD/386 boxes running custom SLIP software.  (Sorry if this sounds
like an ad, I just want to emphasize that you can support a range of
options for not much money.  I doubt many potential customers in
Austin read this group anyway.)

-David

-- 
 David P. Maynard, Carnegie Mellon University & Dependable Solutions
 USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862
 EMail: dpm@depend.com,  Tel: +1 512 251 8122,  Fax: +1 512 251 8308
--

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 94 09:32:00 EST
From:      SWEET_ROBERT_A@lilly.com (Bob Sweet)
To:        comp.os.ms-windows.setup,comp.protocols.tcp-ip
Subject:   WFWG 3.11 Solution to some problems

I've been having severe problems with 3.11 and TCP/IP and was helped by
an article by Robert X. Cringely in the 1/10/94 InfoWorld.  He picked
up the following suggestion from Microsoft to help with 32 bit disk
access problems, but it helped me too.

Delete from SYS.INI
  Within [386Enh]
  INDOSPolling=TRUE
  EMMExclude=some memory range
  TimerCriticalSection=5000 (or some other value)
  UniqueDOSPSP=TRUE
  PSPIncrement=5
  NetHeapSize=76 (or some other value)
  NetAsynchTimeout=50
  NetAsynchFallback=TRUE
  PerVMfiles=0

Delete from WIN.INI
  load=winpopup.exe
  load=nwpopup.exe
  LPT1.DOS=
  LPT2.DOS=
  LPT3.DOS=

I'm not sure what this will impact per other capabilities, nor do I
know which line fixed the TCP/IP bug.  I'm just thankful and wished to
share the wealth.

Cheers,
Bob 

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 12:44:58 +1030
From:      simon@wraith.internode.com.au (Simon Hackett)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: SMTP <-> DISSOS/Memo

pbowyer@pcl.demon.co.uk  (Peter Bowyer) writes:

>In article <CJBMH2.14K@eunet.ch> Florian.Gutzwiller@open.ch (Florian Gutzwiller) writes:
 
> >> Can anybody comment on solutions that would make SMTP talk to IBM Dissos Mail  
> >> and vice versa. I know high price solutions like HP OpenMail or EMX SoftSwitch  
> >> can do that, but I'm rather looking for something really open and simple.
> >> 
 
>If you're looking for a service-based solution, then IBM Mail Exchange now has an SMTP
>gateway into Internet.

If you have a VMS Vax lurking in the picture somewhere, then you can
use Innosoft's PMDF Vax/VMS mail gateway product with it's Message Router
option to get SMTP mail over to DEC's Message Router environment. That, in turn,
has an option to support talking to IBM mainframe mail environments.

A little "multi-stage", but still... iii@innosoft.com can give you more
details I expect.

Simon

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 06:21:42 GMT
From:      vogety@CS.ColoState.EDU (ramanagopal vogety)
To:        comp.protocols.tcp-ip
Subject:   FAQ??


Does anyone maintain a FAQ for this newsgroup?

-Gopal

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 10:36:24 GMT
From:      jk@dde.dk (Jens Kjerte)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for SMTP on Ethernet Network

Richard Thiessen (rickt@mecs.oau.org) wrote:
: I am starting a project soon to interface a version of TCP/IP for QNX
: on an Ethernet System to allow mail to be sent and receive using the SMTP.
: I am looking for the source to SMTP so I can import it to QNX.  
: 

Obtain a copy of the sendmail source. Among other places it can be
found on ftp.cs.berkeley.edu:/ucb/sendmail

Regards

-- 

      __    __   __ 
     /_/|  /_/| /_/	|  Jens Kjerte                 | Email: jk@dde.dk  
    | | |  | ||/ /	|  Dansk Data Elektroniks A/S  | Phone: +45 42845011

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 13:00:56 GMT
From:      jlangri@relay.nswc.navy.mil (James B. Langridge)
To:        comp.protocols.tcp-ip
Subject:   Printing using PCTCP without a host?

I've been asked to find out if it is possible to print to a printer connected 
(in some fashion) to an ethernet but not hanging off from any host.

Here's what we have in a nutshell:

We have Netware 4.01 servers and UNIX (various flavors) hosts hanging off from 
a rather large ethernet.  Most of the user community has an ID on some server 
or host at present.  Some folks out there want to know if they can run PCTCP 
on their PC and have printers connected to the net (most likely with some type 
of "netport" or "jetpress" server card or box) without having to run a daemon 
on a unix host and be able to capture or print directly to one of these 
printers.

I know it may not make a lot of sense but does anyone know if it is possible?

				Thanks in advance,
				-Jim Langridge

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 14:35:02 GMT
From:      erdmana@lbm.com (Alan Erdman)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD Socket Books

Hayden,
   You might look at "Internetworking with TCP/IP  Vol III" by Comer and
Stevens (BSD Socket Version).  There are also vols I and II which I've only
glanced at briefly.
   
A fellow BSD novice
---


----------------------------------------------------
Alan Erdman 			Software Engineer          WANTED:
LB&M Associates			erdmana@lbm.com
211 S. W. 'A' Ave.		(405) 581-3776           clever quote
Lawton, OK  73501  
----------------------------------------------------


-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 23:27:47 -0500
From:      levtech@access.digex.net (Leverage Technologists)
To:        comp.protocols.tcp-ip
Subject:   SLIP problems

 I am having some problems installing CSLIP 2.7. I would appreciate any hints/
 advice.

 I am installing a SLIP client and a SLIP server. The client is stout and the
 server is lager. I configured the kernels and installed all the code fine,
 but I am not sure how to configure my /etc/slip.hosts file. Also, I am not
 sure how to operate the entire system. Basically, what do I have to do on the
 client side to call the server and what do I have to do to the server
 to make it respond.
 
 My /etc/remote file on stout looks like:

   lager:\
       :st=slip:ls=/etc/login.script.unix S%h :\       
       :cc=/etc/sliplogin Sstout:tc=dial-stout:

 When I do a 
 
   tip lager
 
 from stout, the modem dials, connects, prompts for the password and then
 stays connected but appears to be locked. I am not sure what to do at that 
 point??????



 I would appreciate ANY help!!!!!!

Thansk,

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 15:33:35 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

Charles,

I missed your original posting so I don't know exactly what you said or
asked.  From your most recent message, I understand that you are
advocating a protocol or mechanisms for guaranteeing bandwidth in packet
networks.  I'm not sure if you are aware of the "ST" family of protocols
(most recent version is ST-2) which have been used for several years in
the DARPA Wideband Satellite Network, the DARPA Terrestrial Wideband
Network, and the Defense Simulation Internet (DSI) to support real-time
applications including packet voice, packet video, and virtual reality.
(all of the above networks were/are part of the Internet and carry
standard IP traffic too.) The ST Protocol was originally devised by
researchers at MIT Lincoln Labs for packet voice over satellite in the
1970's.  The ST-2 protocol is defined in the RFC series (sorry, I don't
have the number handy).  ST-2 is implemented in the BBN T/20V internet
router, and I understand that it will soon be available in Wellfleet
routers.  University of Southern California - Information Science
Institute developed software to packetize the output of PictureTel
codecs and send the packets over ST; video conferences using PictureTel
and ST have been routine in the networks mentioned above for several
years.

    __   
   /  | /\                  Alex McKenzie, BBN
  /   | \/                  mckenzie@bbn.com
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 15:52:09 GMT
From:      pespen@bbx.basis.com (Peter Espen)
To:        comp.protocols.tcp-ip
Subject:   Admin of multiple SLIP lines?



Pardon me if this is a FAQ, I couldn't find it anywhere.

I have heard of some large institutions providing dialup SLIP
access for a large number of people.  How is this managed?
Do such places assign unique IP addresses to everyone who
wants dialup SLIP access?  Are IP addresses somehow dynamically
assigned when someone dials in?

Some details or pointers to sources of info will be appreciated.

Peter Espen
pespen@dino.basis.com



-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 15:55:39 GMT
From:      simon@lia.di.epfl.ch (Simon Leinen)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

Ehud> 	NFS uses 8192-byte UDP packets with its own retransmission
Ehud> specifications.  FTP uses 512 byte (576 including header) TCP
Ehud> packets.

Ehud> 	Typically 'slow' links (ala SLIP) also have small MTUs meaning
Ehud> that the NFS packet needs to be multiply fragmented, whereas the
Ehud> FTP packet can travel unhurt.

I don't think fragmentation causes the speed difference that Ove
experiences.  As long as fragments don't get lost or wildly reordered,
or arrive to fast for the reassembling machine, I don't see that the
reassembly cost can have such a large influence on performance over
long-haul links.

So here's my theory.  NFS is slower because it is more synchronous;
for each (usually 8192-byte-) block that a client reads from an NFS
server, the client sends an RPC "NFS read" request and waits for the
response packet to come in (usually as several fragments, but this
doesn't matter a lot).  Only after the complete response has been
received it sends the next request for 8192 bytes.

This would mean that - with the default options - the speed of a
single NFS read() is limited by 8192bytes/(network_rtt+server_time).
So if your network has an RTT of one second, the best throughput you
can expect is about 8Kbytes per second when doing an NFS file copy.

FTP uses TCP, which has an ingenious window mechanism that is used to
interleave data packets and ACKs so you can have a much larger amount
of "in-flight data" at any given time.  This is what makes FTP more
efficient than NFS over high-latency links.

If this is the correct explanation, then NFS would benefit from even
larger packets - as long as reassembly keeps working reliably -
because that would increase the allowed amount of unacknowledged data.

Regards,
-- 
Simon.

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 94 18:38:38 GMT
From:      syelving@nyx10.cs.du.edu (Steve Yelvington)
To:        comp.protocols.tcp-ip
Subject:   PC-NFS/Telnet/FTP weird problem


We just connected our internal networks to the Internet through a Cisco 
2000 router and a 56K frame-relay line.

With a PC running PC-NFS from Sun Microsystems, I can set up the gateway 
specs with the net route command. After that, I can ping anywhere in the 
world. However, telnet and ftp work only within our metropolitan area. 
This seems really bizarre to me; I don't see why there should be any 
difference among hosts outside of our network.

Does this ring a bell? Where should we be looking to fix this problem?



-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 19:18:09 GMT
From:      erdmana@lbm.com (Alan Erdman)
To:        comp.protocols.tcp-ip
Subject:   HELP

Does anyone have any clues where to find info on SIMNET protocols?  
(especially on the structure of the data packets).

Thanks for any help
Alan
---


----------------------------------------------------
Alan Erdman 			Software Engineer          WANTED:
LB&M Associates			erdmana@lbm.com
211 S. W. 'A' Ave.		(405) 581-3776           clever quote
Lawton, OK  73501  
----------------------------------------------------


-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 94 19:48:57 GMT
From:      rajeev@cbnewsf.cb.att.com (rajeev.dolas)
To:        comp.protocols.tcp-ip
Subject:   How to FTP from an application


Hello all,

	I need to FTP some files from a server over a WAN within my 
	application.  The question is : What is the best way of achieving
	this task?

	I have thought about two methods:

	1). Execute "/usr/bin/ftp" from a p2open () call. This will
	    allow me to control stdin and stdout to ftp and I can use
	    the standard interface to the ftp. The problem with this
	    method is sometimes the data in the stream (stdout of ftp) is 
	    not available for read until something is written through
	    the stdin of ftp.

	    e.g

	    A call to p2open ("/usr/bin/ftp -v machine_name", fp)
	    will dump 
	    "Connected to machine_name"
	    "220 machine_name FTP server (SunOS 4.1) ....."
	    to the stream but will not dump

	    "Name (machine_name:user_name): "
	    to the stream unless I write something to it. Using fflush()
	    did not help.

	    Any suggestions on this method?

	2). Write a socket based program to connect to the FTP server.
	    Question is after you connect to the server (opening and
	    connecting a socket is no problem ) what commands does one use
	    to instruct the server to perform login and display the
	    directory, etc. In other words is there an API which will let
	    one use the standard ftp interface through a program.


	    I am positive programmers must have done something similar
	    before. Will you please share your experience?


	Thanks a lot.

	Raj Dolas
	raj@qsun.att.com

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 20:39:56 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail


In article <SIMON.94Jan20165539@liasg3.epfl.ch>, simon@lia.di.epfl.ch 
(Simon Leinen) writes:

|FTP uses TCP, which has an ingenious window mechanism that is used to
|interleave data packets and ACKs so you can have a much larger amount
|of "in-flight data" at any given time.  This is what makes FTP more
|efficient than NFS over high-latency links.
|
|If this is the correct explanation, then NFS would benefit from even
|larger packets - as long as reassembly keeps working reliably -
|because that would increase the allowed amount of unacknowledged data.

No, what NFS *should* do is to use TCP.  And, in fact, you *can* use
NFS over TCP simply by mounting the remote filesystem thus:

$ NFSMOUNT node::"mount_point" logical_name /TRANSPORT=TCP

(If you're not using MultiNet, I'm not sure how you'd do it.)

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
      Don't lock yourself into open systems.

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 20:46:11 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: X protocol over TCP/IP

In article <1994Jan15.143625.2046@ultb.isc.rit.edu> cml0464@ultb.isc.rit.edu (C.M. Leung) writes:
>	Secondly, X protocol, as far as I know, most of the times buffers
>requests.  What about entered characters?  Are these manipulated by setting
>certain options over the sockets (if sockets are used at all) ?

The X library normally buffers output from the application to the display.
Events generated at the display, such as key transitions, mouse movements,
and button presses, are generally transmitted immediately.

No special socket options are necessary for this.  On Unix, TCP normally
transmits data shortly after the application sends it.  There's a short
delay to allow back-to-back transmissions on the same socket to be merged,
but this normally isn't long enough to be noticeable to users.  However,
there's a TCP_NODELAY option that can be used to disable it if you really
need to.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 20:52:02 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Admin of multiple SLIP lines?


In article <1994Jan20.155209.1959@bbx.basis.com>, pespen@bbx.basis.com 
(Peter Espen) writes:

|I have heard of some large institutions providing dialup SLIP
|access for a large number of people.  How is this managed?
|Do such places assign unique IP addresses to everyone who
|wants dialup SLIP access?  Are IP addresses somehow dynamically
|assigned when someone dials in?

Yup, that's exactly what you want to do.  You create an "account",
something like a computer account, for each dialup SLIP (or PPP)
user.  It probably contains info such as hostname, IP address,
personal name, etc.

When the user dials into the access server, he (or his script)
enters "SLIP" or somesuch command.  The access server then prompts
the user for a username(/hostname) and password.  These are 
verified against a database (possibly on a separate security 
server, if the access server is diskless), and the IP address
for this host is looked up.

If the username/password combo verifies, the access server kicks
the serial line into IP mode.  This involves doing some or all
of the following:
- install route to IP address in its kernel
- publish ARP entry so as to proxy ARP on behalf of SLIP client
- log connection to accounting file
- set serial port into 8-bits-clean mode

When the user is done, he just hangs up, the connection closes,
and the access server logs a disconnect record.

Two brands of access servers that I know from personal experience
can do the job are the Cisco and the Xylogics Annex.  There are
probably others.

|Some details or pointers to sources of info will be appreciated.

comp.dcom.servers might be the best place to ask.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
      Don't lock yourself into open systems.




-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 00:54:54 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <2hmq6s$3d4@organpipe.uug.arizona.edu> Leonard@Arizona.EDU writes:
>
>In article <SIMON.94Jan20165539@liasg3.epfl.ch>, simon@lia.di.epfl.ch 
>(Simon Leinen) writes:
>
>|FTP uses TCP, which has an ingenious window mechanism that is used to
>|interleave data packets and ACKs so you can have a much larger amount
>|of "in-flight data" at any given time.  This is what makes FTP more
>|efficient than NFS over high-latency links.
>|
>|If this is the correct explanation, then NFS would benefit from even
>|larger packets - as long as reassembly keeps working reliably -
>|because that would increase the allowed amount of unacknowledged data.
>
>No, what NFS *should* do is to use TCP.  And, in fact, you *can* use
>NFS over TCP simply by mounting the remote filesystem thus:
> ...

No, the other guy is right.

Whether you use NFS/TCP/IP or NFS/UDP/IP, NFS generally lacks the
read-ahead that is natural with FTP/TCP.  The windowing in TCP does not
help NFS, because it is at the wrong layer or level for a network file
protocol.  There is generally no way for the window mechanisms of TCP to
inform or by informed by the NFS client's requests or the NFS server's
cache situation.

The main author of NFS/TCP/IP has written (I think in comp.protocols.nfs)
that NFS/TCP/IP is usually slower than NFS/UDP/IP on local area networks,
but NFS/TCP/IP does better on long haul lines where packet losses are
vastly more common.  That is exactly what everyone should expect,
given the well known natures of TCP, UCP, NFS, LAN's and WAN's.

There are NFS/UDP/IP client implementations to do agressive read-aheads.
Their benchmark numbers are great on work loads consisting mostly of
sequential reads of large files.  Unfortunately, most files are small and
significant applications are random, and blind agressive read-ahead is
either neutral or a big mistake in those situations.

In my experience, `rcp` is significantly faster than FTP.  I expect FTP
to go at about 1.5MByte/sec but expect 2 or 3MB/sec from rcp (over FDDI,
of course).  The reasons for this are entirely in the implementations.


Vernon Schryver    vjs@rhyolite.com

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 01:18:24 GMT
From:      jimbo@oingo.umn.edu
To:        comp.protocols.tcp-ip
Subject:   tcp from PC to UNIX

anyone know the site where I can get MSDOS/Windows TCP software to
connect my PC to a UNIX machine so I can share the network printers
and other such stuff?
---
--------------------------------------------------------------------
	James P. Klett			klett@sunrayce.solar.umn.edu
					jimbo@oingo.umn.edu   (SLIP)
--------------------------------------------------------------------
	Slip Slipping' away...		NeXT Mail Preferred
--------------------------------------------------------------------

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 01:19:07 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

Aaron Leonard (leonard@telcom.arizona.edu) wrote:

: In article <SIMON.94Jan20165539@liasg3.epfl.ch>, simon@lia.di.epfl.ch 
: (Simon Leinen) writes:
 
: |FTP uses TCP, which has an ingenious window mechanism that is used to
: |interleave data packets and ACKs so you can have a much larger amount
: |of "in-flight data" at any given time.  This is what makes FTP more
: |efficient than NFS over high-latency links.
: |
: |If this is the correct explanation, then NFS would benefit from even
: |larger packets - as long as reassembly keeps working reliably -
: |because that would increase the allowed amount of unacknowledged data.
 
: No, what NFS *should* do is to use TCP.  And, in fact, you *can* use
: NFS over TCP simply by mounting the remote filesystem thus:

Well, it really isn't as simple as that. So long as NFS retains a
request/reply paradigm, simply switching from UDP to TCP will not a
priori speed things up. It will still wait for a reply, which TCP will
send at about the same speed as UDP.

If instead, things were set-up so that there could be multiple NFS
requests outstanding at a time, one could make use of the dead time.

This is all ignoring the issues of congestion and such...those can be
compelling reasons to use TCP.

rick jones

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 94 01:22:17 GMT
From:      gds@york.cs.ucla.edu (Greg Skinner)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <2hmq6s$3d4@organpipe.uug.arizona.edu> Leonard@Arizona.EDU writes:
>No, what NFS *should* do is to use TCP.  And, in fact, you *can* use
>NFS over TCP simply by mounting the remote filesystem thus:
>$ NFSMOUNT node::"mount_point" logical_name /TRANSPORT=TCP
>(If you're not using MultiNet, I'm not sure how you'd do it.)

I'd like to know how to do this in SunOS, if possible (without
modifying the source code).

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 94 01:43:20 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   death to GOSIP?

The January 17, 1994 Network World has an article that states that the Federal
Internetworking Requirements Panel has recommended that GOSIP be scrapped
immediately.  It also stated the painfully obvious; that many agencies have
bought software that is ``GOSIP compliant'' but never actually used it, using
TCP/IP software instead.

I for one would not shed any tears at the death of GOSIP.  Are there any
perspectives on how far this will go?  Is this perhaps one more nail in the
coffin of OSI?  Am I engaging in wistful thinking?

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 94 02:13:32 GMT
From:      wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
To:        comp.dcom.modems,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: TCP/IP via Modem?

In article <2h93da$q32@sun8.ruf.uni-freiburg.de> loop@mibm.ruf.uni-freiburg.de (Thomas Loop) writes:
   Can anybody tell me if there exists a TCP/IP package for MSDOS or Windows that 
   can do ftp/Gopher/Mail via Modem -> x25Pad?

(Mail is easy; it doesn't need TCP/IP.)

My guess is that your configuration looks something like this:

PC--modem--phone system--modem-X.25pad---X.25switch---HOST

where the host has a direct X.25 interface or maybe another PAD and RS232?
Does the host run Unix?  (X.25 is more popular in the IBM world...)

If that's the case, you'll have trouble finding anything,
though I've talked with other people who want similar things
(partly to avoid paying $2/hour to get SLIP on netcom :-)

Regular SLIP or PPP (which *are* available for PCs, BTW) is designed
for applications where both ends have SLIP/PPP connections to the
operating system; the Unix end in your system goes to an application process.
You'd need a user-level SLIP or PGP program, if such a thing is possible,
and it would have to survive the packetization delays and any
character damage (e.g. ^s/^Q or parity) that the X.25 system does.
It wouldn't be too hard to make a program that handled outgoing
connections/datagrams, but catching return paths is much harder
(unless you have root permissions and can replace inet daemons, etc.)
which makes it hard to be a server (on user ports) or do ftp right.

There are similar configurations that use Ethernet instead of X.25,
with terminal servers which can process SLIP or PPP directly,
giving you a convenient interface that doesn't drain CPU resources.
--
# Bill Stewart       NCR Corp, 6870 Koll Center Pkwy, Pleasanton CA 94566
# Email: bill.stewart@pleasantonca.ncr.com billstewart@attmail.com
# Phone: 1-510-484-6204 Beeper: 1-510-224-7043
# If people were required to *know* all the laws, and not just to obey them,
# the government would be overthrown tomorrow! (From a button by Nancy Lebovitz)

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 02:28:50 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 implementation

In article <1994Jan19.114332.4950@tid.es> jgavilan@tid.es writes:
>Hello everybody:
>I'm working about LAN internetworking using satellite links. I've had 
>problems with TCP perfomance, and I found the RFC 1323 about TCP 
>extensions for high perfomance. 
>All is ok... . But the big problem
>is that I don't know where this RFC is implemented. I'm using KA9q over PC
>and SUNOS 4.3.1 over SUN. Is it necesary to make any change inside the
>OSs? Is there any software which has RFC 1323 included? .

DEC OSF/1 "provides features from RFC 1323."  Specifically, it implements
the Window Scale Option.  I don't think OSF/1 implements everything in that
RFC, at least not in V1.3.

The Window Scale Option is what you need, I think, but you'd have to
buy an Alpha to take advantage of our implementation :-).

For more information, see
	 gatekeeper.dec.com:/pub/DEC/DECinfo/whitepaper/hiperf-tcp.ps.Z
	 gatekeeper.dec.com:/pub/DEC/DECinfo/whitepaper/hiperf-tcp.ps

-Jeff

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 94 10:47:38 PST
From:      FelineGrace@cup.portal.com (Dana B Bourgeois)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mai

I would like to see PC-NFS support TCP as soon as possible.  Hopefully
the next version?

Dana Bourgeois

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 04:10:53 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
}The January 17, 1994 Network World has an article that states that the Federal
}Internetworking Requirements Panel has recommended that GOSIP be scrapped
}immediately.  It also stated the painfully obvious; that many agencies have
}bought software that is ``GOSIP compliant'' but never actually used it, using
}TCP/IP software instead.

  Here's a relevant paragraph from the report:

     The Panel concluded that no single protocol suite meets the
     full range of government requirements for data
     internetworking.  Both the IPS and OSI have strengths and
     weaknesses, as do proprietary protocols.  While a single
     standard would be preferable, the reality is that there are
     multiple solutions in networking as in other areas of
     information technology.  Each community within the
     Government should pursue the solution to meeting their
     mission requirements as a primary goal without a specific
     technical solution being imposed on them.

}I for one would not shed any tears at the death of GOSIP.  Are there any
}perspectives on how far this will go?  Is this perhaps one more nail in the
}coffin of OSI?  Am I engaging in wistful thinking?

    IMO, GOSIP is down for the count.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 04:13:56 GMT
From:      laine@morningstar.com (Ayfer Karakaya Stump)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

In article <2hhul7$5si@geraldo.cc.utexas.edu> tnert@bisque.cc.utexas.edu (TNERT) writes:

>I'm not sure, actually, but there was a discussion in one of the other news groups
>about the use of KA9Q and PCRoute, both for DOS.  Both are available at 
>oak.oakland.edu (pub/msdos/ka9q and pub/msdos/cad, respectively), and
>both apparently allow users to dial up to a normal modem, connect to the server
>using SLIP, and then connect to other machines via standard ethernet.  

NIX on using PCRoute for dialin SLIP. Not only does it have no capability for 
having a login sequence (== no security, no user accounting), but I have read 
that there is something "non-standard" about its SLIP (as if SLIP wasn't a 
"non-standard" anyway). PCRoute works ok for dedicated connections between two 
PCRouter machines, but shouldn't be considered for any dial-in, dial-out, or 
dial-on-demand applications.

KA9Q may be a more realistic solution, although I'm not sure what it does in 
the way of security. I suppose if you could manage to find a version with 
working PPP (among the myriads available) that would probably give you some 
security features.

Laine
laine@morningstar.com

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 10:36:28
From:      mscarton@mudshark.sunquest.com (Mark Scarton)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD Socket Books

I used to teach a senior/grad level Implementing Operating Systems course, 
where we covered things like the kernel algorithms supporting sockets, etc.
I used and would also recommend a review of "The Design and Implementation of 
the 4.3BSD Unix Operating System" by S. Leffler, M. McKusick, M. Karels, and 
J. Quarterman, Addison-Wesley, 1990.  ISBN #0-201-06196-1.  It is 
similar in outline and scope to the System V version of the same by Maurice 
Bach.  Side-by-side, they make an interesting exploration of OS architectural 
design and extension.  I've always found that if I understood the underlying 
implementation, usage of the API was much clearer.

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 05:52:26 GMT
From:      netapp@netcom.com (Network Appliance)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <1994Jan21.012217.15078@cs.ucla.edu> gds@ficus.cs.ucla.edu (Greg Skinner) writes:
>In article <2hmq6s$3d4@organpipe.uug.arizona.edu> Leonard@Arizona.EDU writes:
>>No, what NFS *should* do is to use TCP.  And, in fact, you *can* use
>>NFS over TCP simply by mounting the remote filesystem thus:
>>$ NFSMOUNT node::"mount_point" logical_name /TRANSPORT=TCP
>>(If you're not using MultiNet, I'm not sure how you'd do it.)
>
>I'd like to know how to do this in SunOS, if possible (without
>modifying the source code).

People at Sun have certainly talked about this -- possibly in
connection with the new "to be released someday" NFS 3.0 protocol
revision, but it isn't possible in any current releases.

Dave Hitz					hitz@netapp.com
Network Appliance Corporation 			(415) 428-5106

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 06:38:40 GMT
From:      jonathan@leland.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

In article <laine.3.00483EEB@morningstar.com>, laine@morningstar.com (Ayfer Karakaya Stump) writes:
|> In article <2hhul7$5si@geraldo.cc.utexas.edu> tnert@bisque.cc.utexas.edu (TNERT) writes:
|> 
|> >I'm not sure, actually, but there was a discussion in one of the other news groups
|> >about the use of KA9Q and PCRoute, both for DOS.

[deleted]


|> NIX on using PCRoute for dialin SLIP. Not only does it have no capability for 
|> having a login sequence (== no security, no user accounting), but I have read 
|> that there is something "non-standard" about its SLIP (as if SLIP wasn't a 
|> "non-standard" anyway). PCRoute works ok for dedicated connections between two 
|> PCRouter machines, but shouldn't be considered for any dial-in, dial-out, or 
|> dial-on-demand applications.

Morningstar is hardly without a commercial interest in this area :).

But as a veteran PCroute hacker, I haven't noticed anything
non-standard about PC-route's SLIP.   Then again, *my* PCroute
did SNMPv1 and IGRP as well; maybe I hacked the SLIP encapsuation,
too.

However, I'd still say  the opinion that PCroute lacks sufficient
authentication for dialup service is mostly correct.
But one option that may be worth investigating is to consider
configuring PCroute to use a packet driver; and installing a SLIP or
PPP packet driver that does appropriate authentication for the
application in question.

--Jonathan Stone
  Stanford Distributed Systems Group

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 12:54:39 UNDEFINED
From:      hendryjl@nextwork.rose-hulman.edu (James L. Hendry)
To:        comp.protocols.tcp-ip
Subject:   PC-NFS


The talk about the PC-NFS has me curious. Does this give you the ability to 
mount NFS over a PC? Does it coexist with tcp/ip? Many questions... any 
answers are greatly appreciated. Thanx in advance.

Jim

---------------------------------------------------------------------
hendryjl@nextwork.rose-hulman.edu
Jim Hendry (student)
Rose-Hulman Institute of Technology

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 08:39:26 GMT
From:      ltk@ss3.vlsi.ee.nus.sg (Teng-Kiat Lee)
To:        comp.protocols.tcp-ip
Subject:   SLIP across Terminal server??

I have a few queries regarding SLIP. The setup at my institution for dialup is through a
terminal server. At this moment, I am not aware of anyone else on campus who has implemented
slip. I have setup cslip on my Sun Sparcstation but wonder if I am able to slip to it
from my home via a modem and terminal server. The terminal server right now lets me rlogin
and telnet to any host within its control, can slip go across this? Or do I need something
on my Sun which accepts slip connection from tty's other than the serial ports?

Thanks for any information.

Regards,
Kiat
 
           ---------------    Teng-Kiat Lee   ----------------------
                           ltk@vlsi.ee.nus.sg  
                             t.lee@ieee.org      
           VLSI CAD & Design Lab                Voice: (65)-772-6319
           Dept. of Electrical Engineering             (65)-467-1518
           National University of Singapore     Fax:   (65)-777-3117
           ----------------------------------------------------------
           The moon may be smaller than Earth, but it's further away.

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 08:48:24 GMT
From:      galileoswieng@cix.compulink.co.uk ("Galileo International")
To:        comp.protocols.tcp-ip
Subject:   Re: HELP

> I would suggest Douglas E Comer's "Internetworking with TCP/IP" myself. 
> You'd want Vol 1 of the 2nd Ed.  I only have the one-volume 1st Ed to
> hand so I can't give you the ISBN.
> 

The ISBN for Comer's book is 0-13-474321-0 and the title is 
Internetworking with TCP/IP Volume 1; Principles, Protocols and 
Architecture

Regards
Antony

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 94 22:42:00 -0800
From:      philip.burton@spacebbs.com (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   SMTP <-> DISSOS/Memo

Mark,


Potential business opportunity.  This is from the comp.protocols.tcpip 
newsgroup on usenet:



>>Message-ID: <CJBMH2.14K@eunet.ch>
>Newsgroup: comp.protocols.tcp-ip,comp.mail.sendmail
>Organization: EUnet Switzerland
>
>Can anybody comment on solutions that would make SMTP talk to IBM Disso
>and vice versa. I know high price solutions like HP OpenMail or EMX Sof
>
>can do that, but I'm rather looking for something really open and simpl
>
>Thanks
>
>-Florian
>

-- Phil Burton --    philip.burton@spacebbs.com
- Palo Alto, CA -
---
þ CmpQwk #UNREGþ UNREGISTERED EVALUATION COPY

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 10:50:58 GMT
From:      sparx@altern.com (sparx)
To:        comp.protocols.tcp-ip
Subject:   help on ibm vm tcp-ip

sparx@altern.com

Paris, Frrance. 01/21/94

did somebody try to install a tcp-ip machine on a ibm vm os
why does it need pascal compiler libraries ... ?

need help very urgently
thanks a lot
yous sincerely


-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 22:16:10 -0600
From:      resnick@cogsci.uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?

In article <id.A0A61.S5I@nmti.com>, ihsan@nmti.com (jaleel ihsan) wrote:

> I am looking for a satellite/radio clock that I can hook up to
> my LAN and unix software (that comes with it or can be bought
> separately) that will run on all the systems on the lan and
> keep the system time synchronized with satellite/radio time.

You want to look at the Network Time Protocol (NTP), RFC 1305, and the xntp
implementation, which is available by anonymous FTP from louie.udel.edu. It
will do exactly what you want. Also look to the comp.protocols.time.ntp
newsgroup for more information on NTP.

pr
-- 
Pete Resnick    	(...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 16:29:08 GMT
From:      peteric@creda (Peter Ivimey-Cook)
To:        comp.databases.oracle,comp.databases.sybase,comp.protocols.tcp-ip,comp.unix.questions,comp.windows.x,comp.windows.x.motif
Subject:   Re: Net Bandwith: X-Server vs PC Client/Server

In article <2hgpd4$87m@infosrv.edvz.univie.ac.at> Bernhard Strassl wrote:
-| In article <wdawson.758730986@willard.atl.ga.us>, wdawson@willard.atl.ga.us (Willard Dawson) writes:
-| |> bernhard@trick.ani.univie.ac.at (Bernhard Strassl) writes:
-| |> 
-| |> MS-Windows stuff" under WABI, I believe you're being extremely
-| |> optimistic.
-| |> 

-| Sorry, I did'nt specify which kind of applications I expect to run
-| under WABI:

-| Non-client/server end user programs like word processors, spreadsheets,
-| drwaing programs etc.

-| These are the Windows apps which many UNIX users are missing on their
-| system because of the extremely high pricing of aequivalent UNIX products.
-| (i.e. compare WordPerfect for MS-Win and WordPerfect for SUN)

Point taken.

-| I do NOT expect databases and Windows GUI development stuff running
-| under WABI - maybe it does someday, but I prefer developing new
-| applications under UNIX...


From what has been seen and heard of WABI so far I would say
"Ask Sun whether WABI supports ANY application, tool or other program."

The literature states that WABI initially will only support 13 apps.

However, I would not assume that it will be usable on all of those.
E.g. some apps take several minutes to load files that load in seconds on
a PC.

Also, certain things - e.g. use of ATM - require you to get hold
of a 'real' copy of Windows and install it.

Of course, WABI will certainly get better given time.

For more info, BYTE is currently doing a comparison of WABI.

--
Peter Ivimey-Cook

Please note that I do not speak for my employer
in any way. My opinions are my own, and will
hopefully stay that way!


-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 17:09:31 GMT
From:      bsmith@rahul.net (Bob Smith)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP test tools ????


Does anyone know of TCP/UDP/IP test tools which:
	- can add delay (<10 seconds) to a link
	- drop packets according to a normal distribution
	- re-order packets
	- duplicate packets
	- act as a 'load-box' for the host application under test
	- log (for later analysis) dropped and duplicated packets
	- Include SLIP, PPP, and Ethernet interfaces

Thanks!
Bob Smith
-- 
Bob Smith <bsmith@rahul.net>

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 17:56:53 GMT
From:      dtoppin@neteng.melpar.esys.com (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   LIFO dequeue of incoming connections?


In Rich Stevens' recent book _TCP/IP Illustrated, Volume 1_
there is a short discussion on the queuing of incoming connections.
In that discussion he says that queued connections are deqeued
in LIFO rather than FIFO order due to a bug in the original implementation.
I had had a problem a couple of years ago that turned out to be due to
the LIFO dequeue.
Rich says that the bug is being corrected by the vendors.
We had to set the listen queue to 0 to avoid this problem and
I am wondering what the side effects of the bug being fixed will cause
throughout the applications using TCP.
I would think that a subtle change like that might catch the world
by surprise and that it might be best to allow the application
to choose the dequeue order.
I'm interested in other opinions on this.
Please post or drop me a line.
thanks
Doug Toppin
dtoppin@melpar.esys.com

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 18:27:26 GMT
From:      nam@peregrine.esl.com (Nam N. Nguyen)
To:        comp.protocols.tcp-ip
Subject:   MBONE (IP Multicast)

I have just copied mbone (ipmulticast) software from the public domain into
my SunOS SunSparc station and have the following questions:

	* The README instructed how to install the software, but
	  not how to use it.

	  Netter having used this feature (ipmulticast), please help
	  show me how to use this.

	* Would the software works if one of my workstation is running
	  SunOS4.1.1 and another running SunOS4.1.3?

	* Does Solaris2.x come with multicast installed?  If no,
	  where can I obtain the version in Solaris2.x?  If  yes,
	  would Solaris2.x ipmulticast 'talk' with the SunOS ipmulticast
	  mentioned above?

Please help, (via email to nam@esl.com)

Thank you in advance,


Nam N.




-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 94 18:29:29 GMT
From:      pat@tatung1.cs.ttu.edu (Parthiban Durai)
To:        comp.protocols.tcp-ip
Subject:   NetBIOS running on TCP

Hi,

I'd like to know if sunOS Rel. 4.1.2 offers some kind of support for NetBIOS
programming or if there is any public domain software that offers emulation of
NetBIOS services.

Any help in this regard will be appreciated.

Thanx

Parthiban


-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 19:11:34 GMT
From:      jime@well.sf.ca.us (Jim Eberle)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Re: Sockets on MVS

    If your application is running on CICS, IBM has a product called
    Sockets for CICS which includes COBOL & C API's for CICS programs. It
    also has a listener transaction which can be started automatically
    when the region is brought up. I know there is a competing product,
    but I can't remember its name.

    Cheers
    JimE


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 19:12:27 GMT
From:      ihsan@nmti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   time sync protocol ?

I am looking for a satellite/radio clock that I can hook up to
my LAN and unix software (that comes with it or can be bought
separately) that will run on all the systems on the lan and
keep the system time synchronized with satellite/radio time.

Am I day dreaming or can this be done ?

Is time sync protocol a good lead to follow ? 

Any help will be much appreciated.


-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 19:22:24 GMT
From:      jime@well.sf.ca.us (Jim Eberle)
To:        comp.protocols.tcp-ip
Subject:   Question: How to find TTL w/o SNMP?

    Is it possible to determine the time-to-live for IP packets w/o using
    SNMP? The call structure required looks like torture. I need this
    because I'd like to start a listener at a given port and have it wait
    around for all of the TIMED_WAIT sockets to die before giving up on
    the port and returning a port not available error. The TIMED_WAIT
    state is supposed to last 2 segment lifetimes.

    So, is this the right strategy and, if so, can it be accomplished
    relatively easily?

    Thanks
    JimE (jime@well.com)

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 00:41:58
From:      tnert@utxvms.cc.utexas.edu (Trent Stevens)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

In article <1994Jan21.214744.10583@montage.com> jas@montage.com (Jim Shankland) writes:
>From: jas@montage.com (Jim Shankland)
>Subject: Re: SLIP/PPP server - how to?
>Date: Fri, 21 Jan 1994 21:47:44 GMT
 
>In article <2hhul7$5si@geraldo.cc.utexas.edu> tnert@bisque.cc.utexas.edu (TNERT) writes:
>> I'm not sure, actually, but there was a discussion in one of
>> the other news groups about the use of KA9Q and PCRoute, both
>> for DOS.  Both are available at oak.oakland.edu
>> (pub/msdos/ka9q and pub/msdos/cad, respectively), and both
>> apparently allow users to dial up to a normal modem, connect
>> to the server using SLIP, and then connect to other machines
>> via standard ethernet.
 
>The pcroute program in oak.oakland.edu:/pub/msdos/cad appears
>to be a Printed Circuit layout (i.e., wire routing) program.
>That does seem to explain why it was in the CAD directory :-)!
 
>Will the *real* PCRoute program please make itself known?

Whoops!  Thanks for the correction.  The news group where this location was 
originally posted (my source) probably has lots of other confused readers, 
whom I'll alert.  The DOS file pcroute.zip (the *real* one) seems to be 
located in only two places:  omnigate.clarkson.edu in the /pub/msdos/tcpip 
directory and lth.se in the /pub/network/pcroute/old directory.  Ironically, 
the one in Sweden was posted two years after the one at Clarkson, according to 
Archie.  

Accuvax.nwu.edu (Northwestern, where it was written) might have an 
even newer version, but the server was down the last time I tried.  It's also 
available in compressed UNIX format at many other sites.  I haven't tested
either program (KA9Q or PCRoute) yet, but again, best of luck to the intrepid!

Trent Stevens  71172.535@compuserve.com


-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 21:05:03 GMT
From:      morley@suncad.camosun.bc.ca (Mark Morley)
To:        comp.protocols.tcp-ip
Subject:   Routing: KA9Q or PCroute?

Hi there,

I currrently have a network that uses PCroute (at our end) to connect via
SLIP to a NetBlazer (their end - our Internet provider).  This set up
works fine, but I'd like to take advantage of CSLIP or PPP - both of which
PCroute doesn't handle.  We have a dedicated leased line with US Robotics
Couriers at each end (operating in leased line mode).  This means that we
don't need any kind of dial-up handshaking, etc. to establish a link.

Is anyone out there using KA9Q purely as a gateway box like this?  Is it
able to handle CSLIP and/or PPP?  If so, are you willing to share your
config files with me?  Which version of KA9Q (I gather there are many) are
you using?  Where can I get it?

Thanks in advance for any and all help!

Mark

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 21:47:44 GMT
From:      jas@montage.com (Jim Shankland)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

In article <2hhul7$5si@geraldo.cc.utexas.edu> tnert@bisque.cc.utexas.edu (TNERT) writes:
> I'm not sure, actually, but there was a discussion in one of
> the other news groups about the use of KA9Q and PCRoute, both
> for DOS.  Both are available at oak.oakland.edu
> (pub/msdos/ka9q and pub/msdos/cad, respectively), and both
> apparently allow users to dial up to a normal modem, connect
> to the server using SLIP, and then connect to other machines
> via standard ethernet.

The pcroute program in oak.oakland.edu:/pub/msdos/cad appears
to be a Printed Circuit layout (i.e., wire routing) program.
That does seem to explain why it was in the CAD directory :-)!

Will the *real* PCRoute program please make itself known?

jas

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 22:31:44 GMT
From:      steve@crc.ricoh.COM (Stephen R. Savitzky)
To:        comp.protocols.tcp-ip
Subject:   Yet Another SLIP Problem (netblazer/Linux)

I am trying to dial in from a Linux box (call it A) to a Telebit
Netblazer (call it B), which is attached to an Ethernet at the place
where I work.

I can ping and even telnet from A to B, but I can't get to anything on
the network that B is connected to.  Traceroute says that the first
hop is OK, so I know that I'm using B as my default gateway.  The
problem seems to be on the B side.  Running routed on A doesn't seem
to have any effect.

Any suggestions?
--
\ --Steve Savitzky--  \    343 Leigh Ave   \ Cyberspace is an alternate
 \ steve@crc.ricoh.COM \ San Jose, CA 95128 \  universe where magic works.
  \ w: 415-496-5710     \   h:408-294-6492   \       Free Cyberia!
   \_________________________________________________________________________

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 22:40:52 GMT
From:      lillie@comm.mot.com (Ross Lillie)
To:        comp.protocols.tcp-ip
Subject:   ICMP Destination Unreachable messages?

In RFC1122, a number of additional message types are defined for the
ICMP DESTINATION UNREACHABLE error message.  Included in this list of
additional types is message type [8] - "source host isolated".

What are the semantics of this message?  Who generates this message?  Is it
passed to the transport layer?  Is this message generated internally in a host's
IP stack, and used to signal higher layers that all interfaces are dead?

Please email any responses if possible.  If enough responses are received to
warrant it, I'll repost a summary.  Thanks,

--
Ross J. Lillie	    	    	    	    Email: lillie@comm.mot.com
LMPS Systems Research Lab   	    	    Phone: 708.576.0012
Motorola, Inc.	    	    	    	      FAX: 708.576.3240
1301 E. Algonguin Rd.  IL02/2240
Schaumburg, Illinois  60196


-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 23:50:07 GMT
From:      neal@gftpd-mail.citicorp.com (Neal Howard)
To:        comp.protocols.tcp-ip
Subject:   Mosaic Documentation

Try FTPingto the NCSA at ftp.ncsa.uiuc.edu and look under the
mosaic directory.  Included in the wmos1_0.zip file are an
Installation and Configuration Guide (install.txt/install.wri)
and a mosaic features manual (features.txt/features.wri).  The
Installation and Configuration guide also tell how to get more 
documentation once you get mosaic running.

Hope this helps!

Neal  (8->

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 23:56:03 GMT
From:      neal@gftpd-mail.citicorp.com (Neal Howard)
To:        comp.protocols.tcp-ip
Subject:   Re: Mosiac for Winsock

Mayank Shah (mayshah@gandalf.rutgers.edu) wrote:


> I down loaded mosaic for winsocket but it does not have any documentation.
 
> Does any one know where I can get doc. on setting it up to connect to
> info.rutgers.edu
 
>  Mayank



You may want to try FTPing to NCSA at ftp.ncsa.uiuc.edu and look under
the mosaic directory.  In the wmos1_0.zip file is an Installation and
Configuration guide (install.txt/install.wri) and a features manual
(features.txt/features.wri).  The Installation and Configuration
guide also contains some add'l info on getting more documentation
once you get into mosaic (pg 2).

Hope this helps!

Neal  (8->


-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 03:16:35 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

In article <MS-C.759116600.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>The January 17, 1994 Network World has an article that states that the Federal
>Internetworking Requirements Panel has recommended that GOSIP be scrapped
>immediately.  It also stated the painfully obvious; that many agencies have
>bought software that is ``GOSIP compliant'' but never actually used it, using
>TCP/IP software instead.
>
>I for one would not shed any tears at the death of GOSIP.  Are there any
>perspectives on how far this will go?  Is this perhaps one more nail in the
>coffin of OSI?  Am I engaging in wistful thinking?

I dunno.  I did read the draft report and what I got from it was that
GOSIP would not go away, but instead would be expanded to include the
Internet protocol suite as a fully acceptable alternative to the ISO
OSI protocols.  If I understand correctly, the government would have
to at least get one of (Internet or ISO OSI) to comply with the
revised GOSIP statement.  It also seemed to be more pragmatic and said
that the government activities should focus on how best to move bits
to achieve their mission.

In the small number of years I've been at NRL, no one has ever asked
me whether I had a GOSIP compliant machine.  When I asked for some
OSI addresses to do some experiments, I was told that OSI addresses
were not available.  As near as I can tell, GOSIP was always a myth.

Ran
atkinson@itd.nrl.navy.mil


-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 03:30:40 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)

In article <2hp6qe$2o7@gatekeeper.esl.com> nam@peregrine.esl.com (Nam N. Nguyen) writes:

>	* Would the software works if one of my workstation is running
>	  SunOS4.1.1 and another running SunOS4.1.3?

The IP Multicast capability only works between machines that understand
and implement IP Multicast.  If both of your workstations have had
the multicast modifications made to the kernel, then both can use
IP Multicast to communicate.  If not, then they can only communicate
using normal unicast IP.

>	* Does Solaris2.x come with multicast installed?  If no,
>	  where can I obtain the version in Solaris2.x?  If  yes,
>	  would Solaris2.x ipmulticast 'talk' with the SunOS ipmulticast
>	  mentioned above?

Every copy of Solaris 2.x is capable of doing IP Multicast.  All
recent versions (past couple of years or so) of SGI's IRIX operating
system can do IP Multicast.  DEC's OSF/1 for the Alpha can also do IP
Multicast.  Any set of IP Multicast-capable machines should be able
to use IP Multicast to communicate with the members of the group.

I'd suggest you go read the RFC on IP Multicasting to learn more.
I believe the Comer books also talk about IP Multicasting.

Ran
atkinson@itd.nrl.navy.mil



-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 07:32:24 GMT
From:      wangw@iti.gov.sg (Wang Wei Jun (CC))
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,alt.security,comp.security.misc
Subject:   Call for Participation: Intl' Conf. on Internetworking&Interoperability

Greetings!
The following is some detail of the conference. Sorry for corssing posting to
several groups. The detail topics are availabe upon request. Please contact
the persons in the end of the message

-----------------------------------------------------------------------------

INTERNATIONAL CONFERENCE ON  INTER-NETWORKING & INTER-OPERABILITY

Mar16-18, 1994		Singapore


INTRODUCTION

The recent  years  have  seen  a  number  of  conferences  held  exclusively  on
networking  technology  and  telecommunication  services,  without  throwing
much  light  on  complex  interconnectivity  issues  between  large networks of
different hardware and operating systems.

Many organisations, having established networks which  are  essentially  
isolated  islands,  find  themselves  faced with the next big question of 
how to get the diverse applications to "talk" to each  other  across  
the  networks.  That is precisely what this conference is intended to 
impart - the ability of applications  running  on top of diverse hardware 
and operating systems to communicate with each other  harmoniously  -  or  
in  two  words -Internetworking & Interoperability.

Internetworking issues relate to the ability of heterogeneous network 
to  communicate  with  each  other.  On  the other hand, interoperability 
issues relate to software applications that are carried and  used  in  
large  diverse systems such as  a  unified  common  SQL  for  DBMS  from  
different  vendors.  Compatibility  issues  between hardware and software 
are a major consideration in this conference.

In the past four years, Systems Education Centre has  successfully  organised  
international  conferences  on  topical themes in Information Technology.  
Past conferences have centred on  topics  such  as  Virus,  Object- Oriented 
Technology, DSS/EIS  and  Multimedia  &  Virtual  Reality.  These  annual  
conferences  have  become  major events in the local IT scene.  Once again, 
we have assembled some of the  best  known  personalities  to  present at 
the conference, all of whom have a wealth of experience in internetworking  
and  interoperability.

WHO SHOULD ATTEND
Every IT Professional who wants to keep himself  abreast  of  technology  
should  pay  more  than  a  cursory  interest to this current "hot" topic.  
In particular, specialists,  consultants  and  managers  in  charge  of  
networks and data communications are encouraged  to  attend.  Also,  
MIS/IT  managers  who  shoulder  the  responsibility of integrating applications
across networks would find their time well-spent in this three-day  conference.


Conference : Administrative Details
Date:    March 16, 17 & 18, 1994
Time:    9:00 am - 5:15 pm
Venue:    Conference Hall 1 & 2, WTC Convention Centre
          11th floor, World Trade Centre, Singapore
Fee       :    S$980.00 per participant
          :    S$880.00 per participant for two or more
Person to Contact  :    Mrs Stella Chan or Ms Jeanne Low at
                        Tel: (65) 278 9789 or Fax: (65) 278 1184

Lunch & 2 tea breaks will be provided.  SFCI, SCS and IEEE members are entitled
to a further 5% discount. Register by January 31, 1994 and get an additional 
5% discount!



Special events   The tutorials are restricted to 50 partcipants!

Tutorial A: Groupware - Software Direction for the Future
                     Lotus Development

Tutorial B: Distributed Computing Environment
                    Mr James Curtin, Open Software Foundation







-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1994 12:39:06 GMT
From:      scoggin@delmarva.com (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?

In article S5I@nmti.com, ihsan@nmti.com (jaleel ihsan) writes:
> I am looking for a satellite/radio clock that I can hook up to
> my LAN and unix software (that comes with it or can be bought
> separately) that will run on all the systems on the lan and
> keep the system time synchronized with satellite/radio time.
> 
> Am I day dreaming or can this be done ?
> 
> Is time sync protocol a good lead to follow ? 
> 
> Any help will be much appreciated.
> 

There is already a protocol and publically-available software to do this.
Network Time Protocol (Version 3) is the best approach - the code is available
on louie.udel.edu in directory pub/ntp as xntp3.3b.tar.Z.  There is another file
called clocks.txt in pub/ntp/docs which lists the radio clocks and Internet
time servers available for synchronization.

Further info available in the Usenet newsgroup comp.protocols.time.ntp.

	- John


---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: scoggin@delmarva.com   |
|  Supervisor, Network Operations       Phone: (302) 451-5200         |
|  Delmarva Power & Light Company       Fax:   (302) 451-5321         |
|  500 N. Wakefield Drive               NOC:   (800) 388-7076         |
|  Newark, DE 19714-6066		                              |
|  The opinions expressed are not those of Delmarva Power, simply the |
|  product of an over-active imagination...                           |
|  Time is Nature's way of preventing everything from happening at    |
|  once.                                                              |
+---------------------------------------------------------------------+



-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Jan 94 02:00:00 -0800
From:      philip.burton@spacebbs.com (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice ove

from CCG@TCDSP1.MMM.COM , we learn that:

>>Message-ID: <1994Jan10.224028.13620@mmm.mmm.com>
>Newsgroup: comp.protocols.tcp-ip
>
>In article <2gsbkiINNhm0@early-bird.think.com>, barmar@think.com (Barry
>Margolin) writes:
>|> In article <CJEy3y.2Ln@ztivax.zfe.siemens.de> huth@stack.zfe.siemens
 (Hans-Peter Huth) writes:
>|> >one problem that may arise with tcp/ip is the end-to-end delay. In 
>|> >networks (i.e. global, met), using udp/ip is much faster because no
>|> >acknowledges are necessary.
>|> 
>|> Acknowledgements don't affect end-to-end delay.  The receiving syste
>|> use the data as soon as it's received, so the acknowledgement time d
>|> slow things down.
>|> -- 
>|> Barry Margolin
>|> System Manager, Thinking Machines Corp.
>|> 
>|> barmar@think.com          {uunet,harvard}!think!barmar
>
>As far as I know, the only issue with any isochronous application over 
>is

Voice isn't necessarily synonymous with real-time.  

A "normal" telephone conversation between two people *is* real-time.  
However, voicemail sent between two voicemail systems (sometimes called 
"networking" in that industry) is just as much store-and-forward as 
e-mail.  In the latter case, the application is not isochronous 
(an-isochronous?).  

Same holds true for different types of video applications.

-- Phil Burton --    philip.burton@spacebbs.com
- Palo Alto, CA -
---
þ CmpQwk #UNREGþ UNREGISTERED EVALUATION COPY

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1994 17:18:46 GMT
From:      slama@ctron.com ( F r e D  S l a m A )
To:        comp.protocols.tcp-ip
Subject:   What's my ethernet address?


	As much as I hate posting this question, I must.

	What is the mechanism through which the 48 bit hardware address
	of my ethernet interface can be obtained?

	The if_req structure doesn't *appear* to provide this information.
	Or, is it disguised as some obscure name like ifr_data?


Thanks,
Fred


-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1994 18:55:49 GMT
From:      mjr@tis.com (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

>Is this perhaps one more nail in the coffin of OSI?

	I think it's already past that point. The coffin has been
nailed shut. This is just one more shovel-load of dirt into the
hole. :)

	Just ignore the feeble scratching noises from inside
the pine box down there and keep shovelling.

mjr.

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 20:36:09 GMT
From:      james@kaiwan.com ( )
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?

In article <tnert.1.0000B31E@utxvms.cc.utexas.edu>,

=
=>Will the *real* PCRoute program please make itself known?
=
=Whoops!  Thanks for the correction.  The news group where this location was 
=originally posted (my source) probably has lots of other confused readers, 
=whom I'll alert.  The DOS file pcroute.zip (the *real* one) seems to be 
=located in only two places:  omnigate.clarkson.edu in the /pub/msdos/tcpip 
=directory and lth.se in the /pub/network/pcroute/old directory.  Ironically, 
=the one in Sweden was posted two years after the one at Clarkson, according to 
=Archie.  
=
=Accuvax.nwu.edu (Northwestern, where it was written) might have an 
=even newer version, but the server was down the last time I tried.  It's also 
=available in compressed UNIX format at many other sites.  I haven't tested
=either program (KA9Q or PCRoute) yet, but again, best of luck to the intrepid!
=
=Trent Stevens  71172.535@compuserve.com
=

Below is from tcp/ip faq(netcom1.netcom.com:/pub/mailcom/IBMTCP).
If you are running Sun Solarie 2.x, you probably need to get a patch
for pcroute.

IMHO, KA9Q in oak.oakland.edu and wuarchive.wustl.edu is good for
SLIP demand dial-out connection with a working dialer supportting
19.2K serial speed. Get rid of the dialer and runs with 16550AFN, 57.6K
is no problem. Heard it will crash if the network traffic runs too
high. If you want to run PPP with working demand dial-out dialer,
you can check ftp.demon.co.uk and idefix.cs.uni-bonn.de.
ucsd.edu has all of the different ka9q collection, though give you
nothing but confusion.

------------------------------------------------------------------------------
PCROUTE v2.24   Free
 
These packages can convert a PC into a TCP/IP router (PCROUTE) or an
Ethernet Bridge (PCBRIDGE).
 
Available via FTP; ftp.acns.nwu.edu, mget /pub/pcroute/pcroute2.24.*
and pcbridge1.2.*
 
Erick Engelke (erick@development.uwaterloo.ca) says: "Excellent
product.  I have used it for years with many heavily used subnets.
Advice: use a 25 Mhz 286 or a similarly fast 386 DX.  Uses only
conventional memory so don't buy more than 1 Mb.Only takes a small
amount of DOS memory."
 
 
Vance Morrison, LANport, Inc., 2040 Polk Street #340, San Francisco,
CA 94109, (415)775-0188, email: lanport@cup.portal.com.
 
Suggestion
PCBRIDGE v2.77  Free
 
Originally by Vance Morrison of Northwester, PCBRIDGE has been taken over by  
Alessandro Fanelli and Luigi Rizzo. The latest version of PCBRIDGE is now ROMabl
e. The  
software is available by anonymous ftp from pical3.iet.unipi.it
(131.114.9.12), cd /pub/bridge.
 
 
Alessandro Fanelli, Luigi Rizzo (luigi@iet.unipi.it),
Universita` di Pisa - via Diotisalvi 2, 56126 Pisa, Italy
Tel. +39-50-568533  -- Fax +39-50-568522
 
 
KarlBridge v1.41
 
This software provides a two port Ethernet to Ethernet bridge that can filter
based on any Ethernet protocol, including IP, XNS, DECNET, LAT, EtherTalk,
NetBEUI, Novell IPX, etc. 
 
 
It will also act as an IP firewall by filtering IP packets based 
on IP address/network/subnet combinations and socket numbers. It can 
also filter DECNET and AppleTalk Phase 1 & 2 packets. Novell SAP and NCR 
WaveLAN filtering are coming in a future release.
Available via ftp 128.146.1.7, cd /pub/kbridge
------------------------------------------------------------------------------
-- 
info@kaiwan.com,Anonymous FTP,Telnet kaiwan.com(192.215.30.2)FAX#714-638-0455 
Data Lines# (714) 539-0829,452-9166, (310) 527-4279, (818) 579-6701,756-0180
ZyXEL U-1496E 16.8K: $279.00, U-1496E+ 19.2K: $389.00 Voice/FAX/Data Modems

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 22:51:32 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?

In article <id.A0A61.S5I@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
>I am looking for a satellite/radio clock that I can hook up to
>my LAN and unix software (that comes with it or can be bought
>separately) that will run on all the systems on the lan and
>keep the system time synchronized with satellite/radio time.
>
>Am I day dreaming or can this be done ?
>
>Is time sync protocol a good lead to follow ? 
>
>Any help will be much appreciated.

You want to learn more about the Network Time Protocol, version 3 (NTPv3)
which is documented in RFC-1305.  You should also go read
	comp.protocols.time.ntp
where NTP is discussed.

A good NTP ftp site is: louie.udel.edu



-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1994 23:05:46 GMT
From:      bmah@propaganda.cs.berkeley.edu (Bruce A. Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)

Ran Atkinson writes:
> In article <2hp6qe$2o7@gatekeeper.esl.com> nam@peregrine.esl.com (Nam N. Nguyen) writes:
>> * Does Solaris2.x come with multicast installed?  If no,
>> where can I obtain the version in Solaris2.x?  If  yes,
>> would Solaris2.x ipmulticast 'talk' with the SunOS ipmulticast
>> mentioned above?
> 
> Every copy of Solaris 2.x is capable of doing IP Multicast.  All
> recent versions (past couple of years or so) of SGI's IRIX operating
> system can do IP Multicast.  DEC's OSF/1 for the Alpha can also do IP
> Multicast.  Any set of IP Multicast-capable machines should be able
> to use IP Multicast to communicate with the members of the group.

A minor clarification: Alpha OSF/1 V1.3 can do IP multicast *with a
patchkit*, it doesn't do it straight out of the box.  (Actually it
lets you run the multicast client programs, but the patch, as
currently released, doesn't let you use as Alpha as an IP multicast
router.)

I believe I can say that V2.0 is supposed to have IP multicast
built-in, complete with multicast routing (mrouted) support.

(I'm not a Digital employee, I don't even play one on TV.)

Bruce.
--
------------------------------------------------------------------------------
Bruce A. Mah		   Graduate Student	       bmah@tenet.Berkeley.EDU
		      Computer Science Division
		  University of California, Berkeley

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1994 13:30:08 -0800
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Setting TCP/streams buffers??+ dead lock conditions


My environment is Unixware SVR4.2,

I'm struggling with a TCP/UDP/IP library I wrote to make application
interface to the sockets library simpler.  I.E. one person (me) sweating
out these issues instead of many.

I can create a dead lock situation at will that does the following:

A TCP server: reads packets on port A and writes same packet on port B. 
server is a sequential server that has set both sockets to O_NDELAY and
enabled SIGPOLL and uses poll() to respond to inbound packets.  Send and
recieve bufs have been set to 32K.  Does setting buffers this large make
sense??  How can I also tune the stream / inetd buffers even higher??

I've set the SO_OOBINLINE flag in an attempt to keep hangups from beating 
packets to the destination and flushing them..  By the way: does the ioctl()
cmd of I_FLUSH mean to push into the O.S. stream or to throw away??
Does OOBINLINE create the following dead lock or is it unrelated?

Dead lock occures when an either synchronous or asynchronous client (
meaning sockets are either O_NDELAY with signals or NOT) that writes
packets to port A back to back , while servicing inbound backets from port B 
as they arrive.  What happens (quickly with large packets) is that the send()
does block even in the asynchronous client where the socket is set O_NDELAY,
FYI I even check with ioctl(fd, I_CANPUT,) to check whether a send()
would be safe, the send hangs anyway...  

Advice on this subject suggests that the streams resources are being
depleted in the round trip path and they can not be free'ed up due to
the send() blocking, preventing the recieve to free buffers.

Any advice??  It seems obvious that receive should be given preference to
send to try to avoid this scenario.  But if there where ample system buffers
this should never be able to happen if ioctl(fd, I_CANPUT,) would detect a
high water point before a send would block??

See the mail message from another author on the stream buffer dead lock
issue that I'm excersizing with this scenario.


Forwarded mail with  more info on this subject
----------------------------------------------

From dane@incg.com Sun Jan 23 11:14:35 1994
Date: Mon, 17 Jan 94 11:43:19 EST
From: Dane Bills <dane@incg.com>
To: cgi@crl.com
Subject: Lachman tcp blocking 


Paul Smith writes:

>My problems arise in the TCP/IP protocol when the circuit flow controls
>due to being pumped full by the writter filling up the system buffers
>faster than the reader can empty.  I've tried to protect the write side
>by calling ioctl(fd, I_CANPUT prior to actually calling send/sendto().
>This still is not sufficient to prevent a potientially blocking situation
>for the send(). 
 
>I've set the send and recv buffers to 32k via the call;
>setsockopt(fd, SOL_SOCKET, SO_SNDBUF, etc..  Does this make sense in 
>SOCK_STREAM protocol??


>It seems that the Lockman & Assoc.'s implimentation of the TCP/IP etc 
>protocol stack has many holes and catch 22 situations that I'm excersizing??
 
>Is there a way for me to avoid getting hung??

Paul,

I read your article posted to comp.unixware, it was forwarded to me by
a colleague.  My environment is SCO 3.0 and Lachman writes the TCP
protocol drivers as well.  I have experienced similiar problems and
have similiar concerns to yours.  Recently I posted (with some other
questions) the following to comp.unix.questions.  

Question follows:

2)
My other questions have to do with STREAMS implementations of
networking protocols ( I am not attempting to implement one).  I do not
know any great detail about this practice but I have a question about
how to deal with what seems to be a deadlock situation given my
current understanding.  According to my OS documentation streams are
available for processes from the kernel at 3 different priority levels.
Low and medium priority requests are subject to the restrictions of a
kernel parameter which will refuse them if the total number of streams
in use has exceeded a certain limit.  High priority requests are
always filled if the physical kernel resources are available.  The
default cutoffs are 80% 90% 100% for low,med and high.  My
documentation for the TLI says that t_snd will block indefinitely
reguardless of the O_NDELAY flag if STREAMS internal resources are
insufficient to complete the operation.  I have on several occassions
locked up all network traffic on my machine with what I hypothesize is
the following situation:

First, it seems like my OS will let me send messages to another
process until it has exhausted all available STREAMS and then finally
report that flow control is present for the connection.  Is this
normal?  Is there some way to adjust the point at which flow control
is reported? I notice that in the Berkely Sockets interface there are
options for SO_SNDBUF and SO_RCVBUF.  Are those the options I need?  
I believe that the TLI always requests its streams at the same level,
say medium, and I cannot control this.  One process sends a lot of
messages exhausting the limit of streams.  The process which could
relieve the streams ( because it wants to read the messages ) cannot
because it was just about ready to send some messages and gets 'hung'
indefinately in a t_snd ( see above ) waiting for STREAMS internal
resources to become sufficient; which will never happen.

How should I configure the transport providers to minimize this STREAMS
deadlock situation?
Is it normal for a STREAMS network protocol implementation to just
hang indefinately if it can't get STREAMS resources, or does it
suggest a lacking design ( could they use some avoidance
technique like raising the priority on one of the connections? ).

**** End question ***

There is a kernal call something like bufcall or something, I don't
remember exactly what.  Anyway witness this brief piece of text from a
book on creating sreams based device drivers

		... One tool bufcall, is somewhat unusual, and very usefull,
in that it allows a module that needs buffer space and canot obtain it
to ask to be scheduled when space is available.  Since it is also a
tool for creating deadlock (something that kernel hackers avoid since
it tends to displease users), it is a dangerous tool.  So is the
kernel.

I have actualy dumped and observerd TCP programs in this kernel call.
While I don't think that their is anything wrong with using bufcall
(and I certainly don't claim I could write a STREAMS based network
driver, without some study, ); I do think that some kind of avoidance
heuristic could have been created that would use the different
priorities available for making STREAMS requests.

I have also experimented adjusting the socket buffers sizes but I have
not done enough playing around to discover how well they work, my
initial impressions show that the value to set them to (at least on my
implementation ) is not proportional to the amount of streams buffers
used ( I use u386mon to monitor in real time the streams used ).  In
other words reducing the buffer size seems to reduce the amount of
messages capable of being sent before software flow control is
exerted, but not in a manner proportional to the amount the buffer was
reduced.  And I have on occasion still caused the deadlock situation
is a send ( or TLI t_snd which I also use in some clients ).  I need to
experiment more though.

I am *REALLY* interested in finding some kind of solution or
improvement to this situation and I would like to keep in touch with
you and will share ALL that I discover that might help this type of
situation.  It is very unpleasant to have the machine hang, the
applications I am working on depend on constant information being
processed through various protocols for both local and remote
machines ( IPX/SPX TCP X25 are all used ).

Dane

-- 
//----------------------------------------------------------------------
//
//  Integrated North Coast Group		Dane Bills
//  925 S Main st.						dane@incg.com
//  Canton, OH 44720			
//
//-----------------------------------------------------------------------

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1994 04:10:36 GMT
From:      mksho@uno.edu
To:        comp.protocols.tcp-ip
Subject:   SLIP questions

Well, I read all the FAQ's I could find, and they were not really very
useful.  Here is my question:

At my school, 19200 bps serial connections to a terminal server are available
(no SLIP).  There are many unix machines one can connect to.  Is it possible
to have one of these machines function as a SLIP server for connections
from the terminal server?  I know I will need administrative help for this
(groan..)  I was talking to some administrative, bureacratic, non-computer
type person in charge of computing services (don't you hate them?) and 
he said 'costs of setting up SLIP would be prohibitive' and from what I
know, on a small scale at least, he is full of sh*t.  

Would PPP be a better idea from a security standpoint?  Also I believe that
these connections are non-error corrected, non-compressed.

Thanks,
Craig.


-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Jan 1994 06:40:35 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS

 
In article <hendryjl.37.00213BCB@nextwork.rose-hulman.edu>, James L. Hendry (hendryjl@nextwork.rose-hulman.edu) writes:
>
>The talk about the PC-NFS has me curious. Does this give you the ability to 
>mount NFS over a PC? Does it coexist with tcp/ip? Many questions... any 
>answers are greatly appreciated. Thanx in advance.
>
>Jim
>
>---------------------------------------------------------------------
>hendryjl@nextwork.rose-hulman.edu
>Jim Hendry (student)
>Rose-Hulman Institute of Technology
>
If you're talking about Sun's PC-NFS you can mount unix file
systems and use unix printers.  It has it's own tcp/ip with all the
standard bells and whistles.  I use it on all my PC's as do all my
clients.  I tried many others and found this to be the easiest to
install and maintain.  I havent had a minute of trouble since I
installed the first one 2 years ago.
 


-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Jan 1994 15:30:18 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mai

In article <101675@cup.portal.com>,
Dana B Bourgeois <FelineGrace@cup.portal.com> wrote:
>I would like to see PC-NFS support TCP as soon as possible.  Hopefully
>the next version?

If it's a NFS-over-TCP client on a PC that you're after, then there's at
least one available, since PC/TCP supports it: I don't know of any
others at present. Details from info@ftp.com, or reply to me, since my
employers sell this in Europe.

Unfortunately, NFS servers supporting TCP are in shorter supply at least
on commercially-available systems; I believe that BSD 4.4 has it.
Interstream demonstrated a TCP/NFS at one Interop, but have never
released it.

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm. News admin, pipex. Internic: IP4
"... we had no interoperability goal when designing ****.  Therefore the product
interoperates with itself." [A quote from a developer of a TCP/IP product.]
Name omitted to protect the guilty.

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 10:27:13 -0500
From:      davidc@hubcap.clemson.edu (David S Condrey)
To:        comp.protocols.tcp-ip
Subject:   KERMIT file transfers via telnet...anyone???

Hi folks. I have a situation here where PC users using kermit for
terminal emulation are dialing up to a terminal server which then starts
a line mode telnet session with our MVS system. 

The users are wanting to transfer a file, so they start up the kermit
file transfer operation on the PC and the MVS system, but it barfs. 

                  kermit                   telnet
             PC<--------->TerminalServer<---------->MVS

When dialing straight into the MVS system (no TCP-IP involved), the file
transfers work fine. Seems like the kermit protocol would be
encapsulated by the IP packets during the MVS<->TerminalServer portion
of the data route without a problem.

Any ideas?  Thanks.
-David

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 02:12:49 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mai

In article <1994Jan23.153018.11397@unipalm.co.uk> ian@unipalm.co.uk (Ian Phillipps) writes:

>Unfortunately, NFS servers supporting TCP are in shorter supply at least
>on commercially-available systems; I believe that BSD 4.4 has it.
>Interstream demonstrated a TCP/NFS at one Interop, but have never
>released it.
>
>Ian

	I think that the more recent Sun operating systems
(e.g. Solaris 2.3) can be configured to support NFS/TCP instead of
NFS/UDP.  Friends at Sun tell me that they use NFS/TCP internally.
The most recent NFS spec reportedly includes NFS/TCP.  Nag your
server vendor to implement the most recent NFS spec.

	On a single-segment LAN, NFS/UDP makes some sense.  However,
in our case with 3 routers between client and server, NFS/TCP is a big
win.  Use of TCP can also help reduce/eliminate the dreaded NFS hang
because when the net goes down or the remote machine goes down, TCP
will close the connection and so the NFS executable knows to give up
on the remote server.

Ran
atkinson@itd.nrl.navy.mil

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 04:33:09 GMT
From:      system@asuvax.eas.asu.edu (Marc Lesure)
To:        comp.dcom.servers,comp.protocols.tcp-ip
Subject:   Modem/Terminal server software for Unix


Does anyone know of any software for a Unix box that allows it
to act like a terminal server?  What I want is a shell that once the
user logs in, looks like a Cisco-type terminal server with all the
options and so forth.  I need source so I can tailor it to our
specific needs.

-----------------------------------------------------------------------
Marc Lesure / Arizona State University / Tempe, AZ
"Between the world of men and make-believe, I can be found..."
"False faces and meaningless chases, I travel alone..."
"And where do you go when you come to the end of your dream?"

UUCP:       ...!ncar!noao!asuvax!lesure  
Internet:   lesure@asuvax.eas.asu.edu

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 05:03:59 GMT
From:      ivan@ntuix.ntu.ac.sg (Ivan Leong)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for SMTP on Ethernet Network

Jens Kjerte (jk@dde.dk) wrote:

> Richard Thiessen (rickt@mecs.oau.org) wrote:
> : I am starting a project soon to interface a version of TCP/IP for QNX
> : on an Ethernet System to allow mail to be sent and receive using the SMTP.
> : I am looking for the source to SMTP so I can import it to QNX.  
 
> Obtain a copy of the sendmail source. Among other places it can be
> found on ftp.cs.berkeley.edu:/ucb/sendmail

There's KA9Q (for MSDOS) that has C src to SMTP server & client. Look
at wuarchive for S920603.ZIP. (This is a Jun92 ver though there's
a Jan94 ver but no src). Jan94 version is at biochemistry.wurc.edu.

_OR_

WATTCP has a SMTPSERV.ZIP (server only) that has an only 20Kb
C src code. Look at dorm.rutgers.edu.

'il
---
Dialup:   +65 755-6463              16.8HST/V32t/V32b/V42b
Fidonet:  6:600/500  (aka 600/510)     Miqas/2 [Singapore]
Internet: ivan@ntu.ac.sg  _OR_  bz7004742@ntuvax.ntu.ac.sg

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 06:03:21 GMT
From:      edbsba@sio25.uio.no (Stein-Aksel Basma)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS running on TCP

Parthiban Durai (pat@tatung1.cs.ttu.edu) wrote:
: Hi,
 
: I'd like to know if sunOS Rel. 4.1.2 offers some kind of support for NetBIOS
: programming or if there is any public domain software that offers emulation of
: NetBIOS services.
 
: Any help in this regard will be appreciated.
 
: Thanx
 
: Parthiban

check out nimbus.anu.edu.au in directory /pub/tridge/server. It's got
a neat PD NetBIOS-implementation.
--

//------------------------------------------------------------
//	Stein-Aksel Basma 
//	IT-consultant
//	Finnmark County Council
//	E-mail:	edbsba@sio25.uio.no
//	Phone:	+47 78 95 07 45
//------------------------------------------------------------

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 94 19:11:34 PST
From:      Skip_-_Kennedy@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?

Does NTP address the problem of synchronizing audio/video/data
as is required for real-time conferencing?  Or are there other
protocols which address this issue?

Any assistance will be greatly appreciated.

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 09:52:03 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Bidirectional SOCKET throughput

In comp.protocols.tcp-ip, article <Jan.18.19.04.17.1994.22500@lexington.rutgers.edu>,
  percosan@lexington.rutgers.edu (Peter Percosan) writes:
> 
> I must now send data between both systems in a balanced fashion. By
> balanced I mean that the number of reads and writes between the two
> computers is nearly the same:
>  [ picture ]
> the problem here is that the performance goes right into the garbage!

What is your code doing? The standard read/write/read/write approach won't
work because you're waiting for data all the time. Use select() and
read/write as appropriate.

-- 
I am a bookaholic.  If you are a decent person, you will sell me books
        at half price.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 09:56:06 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket/TCP/IP calls hang in the OS

In comp.protocols.tcp-ip, article <2hj5it$9vt@crl2.crl.com>,
  cgi@crl.com (Paul Smith) writes:
> 
> I've set the send and recv buffers to 32k via the call;
> setsockopt(fd, SOL_SOCKET, SO_SNDBUF, etc..  Does this make sense in 
> SOCK_STREAM protocol??
> 
 This smells like a signed integer. Try 28k or thereabouts.
> 
> It seems that the Lockman & Assoc.'s implimentation of the TCP/IP etc 
> protocol stack has many holes and catch 22 situations that I'm excersizing??
> Is there a way for me to avoid getting hung??

Switch to NetBSD.  ;-)

-- 
I took a course in speed reading.  Then I got 'Reader's Digest' on microfilm.
By the time I got the machine set up I was done.
                               -- Steven Wright
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 10:10:10 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip,comp.os.386bsd.development
Subject:   Re: RFC 1323 implementation

In comp.protocols.tcp-ip, article <1994Jan20.014041.9301@csd-newshost.stanford.edu>,
  jonathan@leland.Stanford.EDU (Jonathan Stone) writes:
> 
> Thomas Skibo (then at UIUC, now at SGI) implemented
> RFC1323 as patches to the networking code from 4.3BSD-Net2.
> They are available via anonymous FTP, at:
> uxc.cso.uiui.edu:/pub/tcplw.shar
> 
Archie finds uxc.cso.uiuc.edu for that file (I assume the above host name
is a typo), but there's no /pub there.
> 
> from ftp.concert.cert:/dist/tcp.sunos41+.tar and

That's ftp.concert.net.

> A slightly newer version of Thomas Skibo's code is in 4.4BSD;
> use that, if you can.

Does anybody know whether this is/will be in NetBSD?
-- 
Lisa:  "Mom, I'm scared."
Marge: "We all are, dear, but your father says everything is all right."
               -- _Call_of_the_Simpsons_, from The Simpsons
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 94 16:55:24
From:      touch@ISI.EDU (Joe Touch)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail



   Ehud> 	NFS uses 8192-byte UDP packets with its own retransmission
   Ehud> specifications.  FTP uses 512 byte (576 including header) TCP
   Ehud> packets.

   Ehud> 	Typically 'slow' links (ala SLIP) also have small MTUs meaning
   Ehud> that the NFS packet needs to be multiply fragmented, whereas the
   Ehud> FTP packet can travel unhurt.

   This would mean that - with the default options - the speed of a
   single NFS read() is limited by 8192bytes/(network_rtt+server_time).
   So if your network has an RTT of one second, the best throughput you
   can expect is about 8Kbytes per second when doing an NFS file copy.

   FTP uses TCP, which has an ingenious window mechanism that is used to
   interleave data packets and ACKs so you can have a much larger amount
   of "in-flight data" at any given time.  This is what makes FTP more
   efficient than NFS over high-latency links.

The problem is high bandwidth-delay products, not really latency.
Consider a 300-bps line with 250ms latency (1978 phone line through a
satellite link), with only 10 chars in the pipe. Either block-NFS or
TCP will work fine.

For 8192 bytes, NFS block read requests support pipes of only 6.5ms at
10 Mbps. If you're server is very close (2ms here at ISI, via PING),
you're problem may be elsewhere, i.e., in the code that accesses the
NFS.

TCP isn't the solution either, however. It supports only 64Kbytes
outstanding (i.e., the window size). Thus it is sufficient for up to
52ms latencies at 10Mbps.  End-to-end latency in the Internet between
NYC and LA is approx 110ms. So it'll use only 1/2 the optimal
bandwidth. 

There are extensions to TCP that make the window larger, either
directly or via the same number (64K) of larger units than bytes.
This allows TCP to use the max. bandwidth, up to the size of the file
itself.

The real interesting problem comes when we consider gigabit WAN links,
where 20 Mbits is outstanding, but the files themselves are only
500Kbits. The file server needs to do something more than just provide
a large window, it has to figure out what to put into that window.

We've been working on a method to use bandwidth to reduce latency in
high bandwidth delay product networks, by figuring out how to fill
that huge window. We have observed that we can reduce latency to 1/3,
for 7x the original TCP bandwidth.

More information is available via anonymous FTP from
	ftp.isi.edu
in
	pub/hpcc-papers/touch/infocom94.ps.Z

Joe Touch
touch@isi.edu
USC/Information Sciences Institute

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 16:36:49 GMT
From:      csl@pinet.aip.org (chris_lloyd)
To:        comp.protocols.tcp-ip
Subject:   UNIX --> SAME PRINTER <-- Novell





I am looking for a robust solution (Software of
Hardware) to allow laser printers to print from both
Novell Print queues as well as Unix Print queues.

We have currently standardized on Intel Netport Print
Servers, but could change to another vendor if it
provides a better solution.

Environment -

SunOS 4.1.3 using a variety of X-Terminals and
Character based terminals.

Novell 3.11 - Using mostly 386/486 based PCs running
WordPerfect & Lotus.

Thanks in advance for any suggestions.

Chris Lloyd
Manager, Production systems
American Institute of Physics

(516) 576-2313   csl@aip.org






-- 
Chris Lloyd			Internet:	csl@pinet.aip.org
Manager, Production Systems	Bitnet:		csl@aip.bitnet
American Institute of Physics	Voice:		(516) 576-2313
500 Sunnyside Blvd.		

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 18:34:54 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Line Printer Daemon Protocol

I am making an evaluation of the effort required to implement a daemon
following RFC 1179.  Most of it appears straightforward except the various
print formats (troff, plot, etc).

As this is not a Unix box the handling of these formats will be additional
coding effort.  Which, if any, of these formats MUST be supported?  Are
they really site specific, or can some fall under the catagory 'EVERYBODY
with a Unix system will be printing files in the XXX format at one time or
another'?

Steve Lawson
lawson@netcom.com

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 19:26:13 GMT
From:      zeeff@zip.eecs.umich.edu (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses

Simplistic hash algorithms that one would think would be random tend to not
distribute very well.

Here is one that does a good job:

/*
 * This is a simplified version of the pathalias hashing function.
 * Thanks to Steve Belovin and Peter Honeyman
 *
 * hash a string into a long int.  31 bit crc (from andrew appel).
 * the crc table is computed at run time by crcinit() -- we could
 * precompute, but it takes 1 clock tick on a 750.
 *
 * This fast table calculation works only if POLY is a prime polynomial
 * in the field of integers modulo 2.  Since the coefficients of a
 * 32-bit polynomial won't fit in a 32-bit word, the high-order bit is
 * implicit.  IT MUST ALSO BE THE CASE that the coefficients of orders
 * 31 down to 25 are zero.  Happily, we have candidates, from
 * E. J.  Watson, "Primitive Polynomials (Mod 2)", Math. Comp. 16 (1962):
 *      x^32 + x^7 + x^5 + x^3 + x^2 + x^1 + x^0
 *      x^31 + x^3 + x^0
 *
 * We reverse the bits to get:
 *      111101010000000000000000000000001 but drop the last 1
 *         f   5   0   0   0   0   0   0
 *      010010000000000000000000000000001 ditto, for 31-bit crc
 *         4   8   0   0   0   0   0   0
 */

#define POLY 0x48000000L        /* 31-bit polynomial (avoids sign problems) */

static long CrcTable[128];

/*
 - crcinit - initialize tables for hash function
 */
static void
crcinit()
{
        register int i, j;
        register long sum;

        for (i = 0; i < 128; ++i) {
                sum = 0L;
                for (j = 7 - 1; j >= 0; --j)
                        if (i & (1 << j))
                                sum ^= POLY >> j;
                CrcTable[i] = sum;
        }
        DEBUG(("crcinit: done\n"));
}


/*
 - hash - Honeyman's nice hashing function
 */
static long
hash(name, size)
register char *name;
register int size;
{
        register long sum = 0L;

        while (size--) {
                sum = (sum >> 7) ^ CrcTable[(sum ^ (*name++)) & 0x7f];
        }
        DEBUG(("hash: returns (%ld)\n", sum));
        return(sum);
}



-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 09:16:59 -0800
From:      Mark Crispin <mrc@Tomobiki-Cho.CAC.Washington.EDU>
To:        comp.protocols.tcp-ip, John Greene <greene@cs.umass.edu>
Subject:   re: INPUT WANTED: InterSLIP vs. VersaTerm SLIP vs. MacSLIP

I have used MacSLIP for a few years now, and I am very happy/satisfied with
it.  Rick's customer support is *excellent*; and what's more, he listens to
his users' suggestions and acts on them.

The present version of Mailstrom has its own problems.  It has a terrible
internal implementation of both the IMAP protocol and of MacTCP usage.  I have
been in contact with the author of Mailstrom, and there is a new version of
Mailstrom which has a completely rewritten IMAP driver and MacTCP interface
(basically, it uses my c-client library now).  This version is still in alpha
state; there's a lot of creeping featurism going on with that version of
Mailstrom now.

Anyway, any version 1.xxx version of Mailstrom has the old lousy MacTCP
interface and bad IMAP driver.  You won't notice the problems as much on
Ethernet, but on any low-speed IP links such as SLIP you will.  This isn't a
problem with SLIP, it's a problem with 1.xxx versions of Mailstrom.

I haven't had problems with Fetch, although I have noticed that Fetch is quite
slow in its automatic transfer mode.  If you turn off translations and just
retrieve the files as binary with no translation, transfers are much faster.


-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 21:07:48 GMT
From:      grefen@convex.com (Stefan Grefen)
To:        comp.protocols.tcp-ip,comp.os.386bsd.development
Subject:   Re: RFC 1323 implementation

In article <2i039i$302@smurf.noris.de>,
Matthias Urlichs <urlichs@smurf.noris.de> wrote:
>In comp.protocols.tcp-ip, article <1994Jan20.014041.9301@csd-newshost.stanford.edu>,
>  jonathan@leland.Stanford.EDU (Jonathan Stone) writes:
>> 
>> Thomas Skibo (then at UIUC, now at SGI) implemented
>> RFC1323 as patches to the networking code from 4.3BSD-Net2.
>> They are available via anonymous FTP, at:
>> uxc.cso.uiui.edu:/pub/tcplw.shar
>> 
>Archie finds uxc.cso.uiuc.edu for that file (I assume the above host name
>is a typo), but there's no /pub there.
 
That is vixen.cso.uiuc.edu now. It has a /pub and tcplw.shar.Z is there.
It looks like it should fit into NetBSD without major problems.

>> 
>> from ftp.concert.cert:/dist/tcp.sunos41+.tar and

That code is only useable (for getting it into NetBSD) if you have sun a 
source (or for the dec version an ultrix source) license.

>
>That's ftp.concert.net.
>
>> A slightly newer version of Thomas Skibo's code is in 4.4BSD;
>> use that, if you can.
>
>Does anybody know whether this is/will be in NetBSD?
I'll try it tomorrow or at the weekend.

Stefan
>-- 
>Lisa:  "Mom, I'm scared."
>Marge: "We all are, dear, but your father says everything is all right."
>               -- _Call_of_the_Simpsons_, from The Simpsons
>-- 
>Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
>Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
>90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
>
>Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.


-- 
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270


-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 21:17:11 +0000
From:      dms@symmetry.demon.co.uk (Donald M Scobbie)
To:        comp.protocols.tcp-ip
Subject:   PD TCP/IP for SCO Unix

Does anyone know of a public domain TCP/IP for SCO Unix? I suppose I'm looking
for a port of the BSD code, but any info at all would be appreciated.

-- 
Donald Scobbie

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 21:41:29 GMT
From:      khweis@mvmpc31.ciw.uni-karlsruhe.de (Karl-Heinz Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing: KA9Q or PCroute?

In article <CJzzwG.JFB@suncad.camosun.bc.ca>, morley@suncad.camosun.bc.ca (Mark Morley) says:
>
>
>Is anyone out there using KA9Q purely as a gateway box like this?  Is it
>able to handle CSLIP and/or PPP?  If so, are you willing to share your
>config files with me?  Which version of KA9Q (I gather there are many) are
>you using?  Where can I get it?
>

have a look at biochemistry.cwru.edu. You'll find there the very latest version
of nos10b, compiled by Ashok and some other useful support-files. I use
this version in my own gate and it's running very stable.

cu,
    Karl-Heinz

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 23:52:56 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   SMTP refusal of service?

If an SMTP server exceeds a user-definable connection limit, what (if any)
is the standard response code returned?  So far I have settled for the
line:
420 Too many connections, try again later

But would prefer whatever value is most common.  I opted for transient
error as, though it requires a new connection, it does not require user
intervention.

Steve Lawson
lawson@netcom.com


-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 94 01:56:33 GMT
From:      sgarno@oak.cel.scg.hac.com (Steven Garno)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.os.msdos.apps,comp.os.msdos.misc
Subject:   Interrupt 14 Driver

All,

	Does anyone know where I might be able to find the interrupt 14
driver?


	Please send replies to my E-Mail address at

		sgarno@redwood.hac.com

	(I have a hard time getting to news)


			Thanks, 
				Steven Garno



-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 12:17:38 -0600
From:      pug@arlut.utexas.edu (Richard Bainter)
To:        comp.dcom.sys.cisco,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Strange routing problem (was Re: Unknown problem using HighSpeed ethernet card...)

Good Morning,

   I'm including my previous article so that everyone knows what the
   background is. I've found further confusion, and wish for any
   insights out there. Our Ethernet 1 on our Cisco is not sending
   packets onto the Ethernet 2 all of the time. If I do a 'ping -s' on a
   host from the Ethernet 1 to a host on the Ethernet 2, the request
   rarely makes it onto Ethernet 2. The reason I say rarely is it seems
   that about 1 in 500 packets is making it through. If I do a 'ping -s'
   on a host from the Ethernet 2 to a host on the Ethernet 1, the
   requestion makes it to Ethernet 1, the host responds, but rarely does
   it make it back to Ethernet 2. (Again about 1:500) Now the peculiar
   part, if I do a 'ping -slRv' the packet makes it through and back
   both ways just fine all the time. (Well within reason.) What can be
   causing such a problem that didn't exist a week ago? (Note there have
   been no changes in routes, netmasks or broadcast addresses.)

   As an aside, I've verified all the versions are of the specified
   versions. We have the exact same configuration in another router and
   it works just fine. We've replace the card with a new one. Etc. Etc.

Ciao,

In article <2i103m$8qo@ns1.arlut.utexas.edu>,
Richard Bainter <pug@arlut.utexas.edu> wrote:
>   We've got a peculiar problem that we can't diagnose. We just
>   installed a highspeed 6 port ethernet card in our AGS4+, which seemed
>   to go great. Two of the subnets on the card are able to talk to
>   anyone except each other. Ether 1 can talk to Ether 0 and 3. Ether 2
>   can talk to Ether 0 and 3. Ether 1 can not talk to Ether 2 and
>   vice-versa. Does anyone have any ideas on this? We've got on our
>   network analyzer, and traffic looks normal. The packets go to the
>   router and just disappear. This is the same configuration we had
>   working on Friday with the old slow 2 port ethernet cards.
-- 
Richard Bainter          Mundanely     |    System Analyst        - OMG/CSD
Pug                      Generally     |    Applied Research Labs - U.Texas
          pug@arlut.utexas.edu         |    pug@wixer.cactus.org
Note: The views may not reflect my employers, or even my own for that matter.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 10:43:01 -0500
From:      greene@cs.umass.edu (John Greene)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   INPUT WANTED: InterSLIP vs. VersaTerm SLIP vs. MacSLIP


Hi --

  We are having some problems with SLIP on our macs here.  People who
are using unix machines w/ SLIP report no problems, but the same errors
are consistantly being reported w/ the mac.  File transfers (with Fetch)
hang unless you ping the slip node from a telnet window, throughput is
godawfulslow, Mailstrom sometimes bombs, etc.  We are currently using
VersaTerm because when we got interslip we only had mactcp 1.1.1, now
that we have 2.04, I'm considering trying InterSLIP again.
  I guess I want to hear from folks who have a successful SLIP environ-
ment on the mac.  If you do, please e-mail me so we can exchange notes.
Thanks in advance.

-- 

Take care,

-jg              greene@cs.umass.edu - RCF Macintosh Specialist
      Department of Computer Science - University of Massachusetts
           [work ip]  128.119.41.182 - (413) 545-5733  [work phone]
           [home ip]  128.119.43.33  - (413) 253-0744  [home phone]
                    yeP! Keyboardist - Newton Enthusiast

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 02:30:20 GMT
From:      wvr@chestnut.asd.sgi.com (Walter Van Riel)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp from PC to UNIX

>>anyone know the site where I can get MSDOS/Windows TCP software to
>>connect my PC to a UNIX machine so I can share the network printers
>>and other such stuff?
---
Check into into Chameleon/NFS - it allows you mount Unix file systems and
supports tcp/ip - I used it, and it worked fairly well.  It is provided
by Netmanage (I think the company is located in the San Francisco Bay 
Area).  Also, a package called PC-X View provides X Windows to run on 
your PC (Windows) and required Chameleon NFS.

-walter


-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 03:13:37 GMT
From:      jimbo@oingo.umn.edu
To:        comp.protocols.tcp-ip
Subject:   WOW!! Aint that cool

anyone know the site where I can get MSDOS/Windows TCP software to
connect my PC to a UNIX machine so I can share the network printers
and other such stuff? Mount NFS?

---
--------------------------------------------------------------------
	James P. Klett			klett@sunrayce.solar.umn.edu
					jimbo@oingo.umn.edu   (SLIP)
--------------------------------------------------------------------
	Slip Slipping' away...		NeXT Mail Preferred
--------------------------------------------------------------------


-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 04:06:09 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses

In article <2i17cl$5fr@zip.eecs.umich.edu> zeeff@zip.eecs.umich.edu (Jon Zeeff) writes:
>Simplistic hash algorithms that one would think would be random tend to not
>distribute very well.
> ...

Sometimes simpler is better.

I know some people who spent a lot of their time and a considerable number
of CPU cycles looking for as good a hash function for addresses as
practical.  They collected addresses traces on various networks and then
looked at how various hash functions behaved.  The hash function was to
be used in chips intended to move network data as fast as possible.  Among
the features of the silicon was a novel RISC core and provisions for
what was hoped to be a faster protocol than TCP/IP.

As I recall, they decided XOR'ing the address down to 8 or 12 bytes is
good enough.  They specifically considered various CRC polynomials.
Because this was cost-is-no-object silicon and early enough that die space
was not yet a major worry, the significant extra time required by a CPU
to compute the CRC compared to a simple XOR was not a major consideration.

This should not be surprising.  Network addresses, whether MAC or IP, tend
to be very uniformly distributed.  Hashing English words or 256-bit
database keys down to 11 bits is very different from hashing 32-bit IP
addresses down to 11 bits.


Vernon Schryver    vjs@rhyolite.com

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 10:11:58
From:      djmiller@tasc.com (Dean J. Miller)
To:        comp.protocols.tcp-ip
Subject:   User location services

Are there any "standard" services for determining if and where a user is 
currently logged in? We are constructing collaborative services (e.g. network 
telephone, et al) and need to know how to contact a user since he may be 
logged into any one of several machines. Before we go build something, we'd 
obviously like to avoid reinvention. Thanks.
dean
+-----------------------+-----------------------------------+
| Dean J. Miller        | TASC (The Analytic Sciences Corp.)|
| djmiller@tasc.com     | Reading, Ma.                      |
 +-----------------------+-----------------------------------+
|    Sigh... So many beers to brew and so little time....   |
+-----------------------------------------------------------+

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 05:27:36 GMT
From:      fit106@its.csiro.au (Kent Fitch)
To:        comp.protocols.tcp-ip
Subject:   A SUNOS/WINSOCK Internet echo performance monitor

Sometimes is it very hard to understand what is going on in a large and
complicated network.  Ping and traceroute are very handy tools, but don't
give you the big, graphical picture, and don't allow you to easily observe
trends and correlations. 

TWEETY is a system for measuring, displaying and logging TCP/IP echo
response times across a network. 

It attempts to show you what is happening to response times over a part of
the Internet.  We are not really sure how useful it will be - it may even
add to general confusion by making available more interesting but
sometimes inconclusive data. 

It is a considerable expansion of an idea and implementation of Mark
Andrews (CSIRO), which measures the time taken for a TCP/IP echo request
to a host (or router). 

The tweety server currently runs on SUNOS 4.1, the client on MS-Windows
3.1.  If worrying about connectivity and response times to remote hosts is
a MAJOR part of your life, AND you have access to a SUNOS 4.1 system and
PC running WINSOCK then you might like to beta test this software and give
us some feedback. 

It is important to stress that tweety is not a tool for the average or
even advanced user, but should only be used by experienced comms
administrators.  Uncontrolled and careless use could degrade network
performance. 

The doco file can be anon ftp'ed from the tweety home at
commsun.its.csiro.au, directory csiro/sunos/tweety, file tweety.doc.  It
explains how to get the distribution and install it, and the licensing
arrangements (executables are in the public domain, owned by CSIRO -
source can be obtained for a donation to the scientific work of CSIRO). 

CSIRO is the largest publicly funded scientific research organization in
the world.  It operates a wide range of research programs at sites
throughout Australia. 




-- 
Kent Fitch                           Ph: +61 6 276 6711
ITSB   CSIRO  Canberra  Australia    kent.fitch@its.csiro.au
"sonic klein man its me my shape burnt in the sky its me the memorie of me
racing thru the eye of the mer thru the eye of the sea thru the arm of the

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 06:36:53 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   [Q] TCP problem


Dear Netters,

  I wrote a pair of client/server programs in SUN. Usually it
worked fine, but when I gave a heady load test, it caused something
wrong. First I roughly described my programs, the server one
used socket function library to wait the client request. After
the client built connection, it kept the connection alive
until any mistake took place. When a mistake occured, the
programs closed the socket connection and then create new
one. After I tested them by a very heavy load, the server part
halted, but still alive, and the client one asked for another
connecction failed. I checked the process status, it showed as
follw:

USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
yellow     302  0.0  0.0  112    0 ?  IW<  09:25   0:05 recv

Could anyboby tell what it happen?  and how can I overcome it?

Fred Chen

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 06:49:47 GMT
From:      robert@olsen.ch (Robert Ward)
To:        comp.protocols.tcp-ip,comp.sys.sun.apps
Subject:   OOB data questions (SunOS specific)

I have a couple of questions (sorry if these are already answered in
a FAQ somewhere) relating to sending out-of-band (OOB) data via TCP/IP:

1.  In the Sun documentation ("An Advanced Socket-Based Interprocess
Communications Tutorial"), it states:

    Worse, there may be enough in-band data in the input buffer that
    normal flow control prevents the peer from sending the urgent
    data until the buffer is cleared.

This seems to contradict the (to my mind) purpose of OOB data which
is to be able to "jump over" the in-band data ?  This sentence from
Sun implies that the fire-engine is caught in the same traffic jam
(so to speak).  Is this really right ?  If so, what purpose is OOB
supposed to serve ?


2.  Can someone please explain *exactly* how to send and receive OOB
data.  Actually, sending is easy, you just use the send(2) call.  What
I can't figure out is how to receive OOB data without disrupting the
in-band channel at the same time.  I notice that in the rlogin and
telnet source code, reception of OOB causes all received in-band data
to be thrown away.  For the application I have, I want to keep the
in-band data and not have it disrupted in any way by the OOB data.
How can I do this ?

Thanks in advance,

	- Rob.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    J. Robert Ward,
    Olsen & Associates AG, Seefeldstrasse 233, CH-8008 Zuerich, Switzerland

Tel.:   +41 1 3864847/8        Fax: +41 1 4222282
Email:  robert@olsen.ch        Uucp:  uunet!olsen!robert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 06:54:46 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   FTP servers wanted (for testing)


I'm in the process of writing a ftp client.  Can someone give me
poitners to VMS and other non-unix servers that are out there that
support anonymous ftp?  I only know of one (tgv.com, which is a
multinet server).  Ideally, I'd like to find a UCX server, a TWG
server and maybe a CMU server.  Any TOPS-20s out there still?
Simtel-20 was the last one that I knew of that was on the air and
public (maybe this is a moot point).

Thanks a bunch...

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 15:35:20 -0500
From:      droppers@droppers.pbs.org (Seton Droppers)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Local name resolution backed up by remote server?


I thought I knew what I was doing, but then again...

We are arunning several systems and run named on two of them, one as a primary
name server and one as a secondary name server.  We need to have definitions
in /etc/resolv.conf.  I have a question about how to set up the resolv.conf
file for the systems that are our primary and secondary name servers:

Our original thought was to set up resolv.conf on those two systems so that
the first entry pointed to the localhost and the second entry pointed to
the other name server, as follows:

bettylou (Primary)		barkley (Secondary)
149.48.4.72			149.48.4.71
-----------------------------	---------------------------------
domain pbs.org			domain pbs.org
nameserver 127.0.0.1		nameserver 127.0.0.1
nameserver 149.48.4.71		nameserver 149.48.4.72
nameserver "outside"		nameserver "outside"

We thought this would direct queries to the nameserver on the local
machine, unless that named daemon failed, then it would look
elsewhere.  It has been mentioned that this is not really a good thing.

Since we are not experts in this I was wondering if anyone else had some
thoughts on this?
-- 
Seton Droppers -- "Anything that I say is my opinion and not my employer's."
Systems Manager, E-Mail Postmaster
Public Broadcasting Service, 1320 Braddock Place, Alexandria VA 22314-1698
E-Mail: Droppers@pbs.org   Voice: 703-739-5089   FAX: 703-739-0775

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 14:21:44
From:      tomas.liljebergh@hoe.se (Tomas Liljebergh)
To:        comp.protocols.tcp-ip
Subject:   Re: UNIX --> SAME PRINTER <-- Novell

In article <1994Jan24.163649.28026@pinet.aip.org> csl@pinet.aip.org (chris_lloyd) writes:
>Newsgroups: comp.protocols.tcp-ip
>Path: netserver.hoe.se!corax.udac.uu.se!sunic!EU.net!howland.reston.ans.net!cs.utexas.edu!uunet!psinntp!pinet!csl
>From: csl@pinet.aip.org (chris_lloyd)
>Subject: UNIX --> SAME PRINTER <-- Novell
>Message-ID: <1994Jan24.163649.28026@pinet.aip.org>
>Organization: pinet.aip.org
>Date: Mon, 24 Jan 1994 16:36:49 GMT
>Lines: 38






>I am looking for a robust solution (Software of
>Hardware) to allow laser printers to print from both
>Novell Print queues as well as Unix Print queues.
 
>We have currently standardized on Intel Netport Print
>Servers, but could change to another vendor if it
>provides a better solution.
 
>Environment -
 
>SunOS 4.1.3 using a variety of X-Terminals and
>Character based terminals.
 
>Novell 3.11 - Using mostly 386/486 based PCs running
>WordPerfect & Lotus.

Here at University of Orebero, Sweden

we are using AXIS-5 print servers that is alowing us to print from Unix,
PC using CAP, Mac, Novell and others.

The AXIS-5 is capabel of converting ASCII to POSTSCRIPT so we use
a POSTSCRIPT printer from APPLE to print everything on and it works
well.

AXIS is sold by AXIS COMMUNICATIONS INC,.
99 Rosewood Drive, Suit 170, Danvers, MA 01923, USA
Phone: (508) 777-7957. Fax: (508) 777-9905

Tomas Liljebergh

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 09:34:14 -0000
From:      pcolmer@acorn.co.uk (Philip Colmer)
To:        comp.protocols.tcp-ip
Subject:   Port numbers

My understanding of port numbering under TCP/IP is that there is a static
range, where port numbers are allocated and fixed, and a dynamic range, where
services can allocate between themselves for port numbers to use.

Is this correct?

How are the static numbers allocated?

How are the dynamic numbers allocated?

--Fil.

---------------------------------------------------------------------
Kryten: Sir, I beg you to reconsider.  If not for your sanity, you haven't
        even considered the moral implications of your decision.  You will
        be joining a society where you will be compelled to have sex with
        beautiful, brilliant women, twice daily, on demand.  Now, am I really
        the only one here who finds that just a little bit tacky?

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 11:14:44 GMT
From:      brama@ncratl.AtlantaGA.NCR.COM (Bhyravabho Rama)
To:        comp.protocols.tcp-ip
Subject:   Match PID to TCP ports

I am interested in finding out how can I associate a process id to a TCP/IP
IP address.port number. I am using a TCP/IP applicatin that uses a certain
port number.  Whenever a client connects on a port, a process is started
up called the "run_na".  Now a typical scenario includes about 100-120
clients.  Now I don't have access to the source for this executable and
what I want to be able to do is to match up a process id information
with the PCB structure displayed by the netstat -A command.  This way
I can tell what client is connected on what port.

My email address is Bhyravabho Rama@AtlantaGA.NCR.COM  
-- 

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 94 12:20:53 GMT
From:      simatic@aar.alcatel-alsthom.fr (Michel Simatic DOM)
To:        comp.protocols.tcp-ip
Subject:   When does a TCP connection break ?

Hi,

I am using a TCP connection (on Sun Sparc stations running SunOS 4.1
connected by an Ethernet) to detect when a distant process dies :
if the connection breaks, I assume that the distant process has died 
(or the network has broken).

I am wondering if this approach is valid. In particular, are
there cases where the connection breaks and the distant process
is actually still there (and so is the network) ? If it is the
case, what would be the right solution ? Are there any parameters 
to setup in TCP in order to avoid this phenomenon ? What do you think 
about trying to reconnect several times to the distant process and if 
that fails, say it *is* dead ?

Thanks in advance for your help.


======================================================              __
| Michel SIMATIC                                     |              \/
| Alcatel Alsthom Recherche                          |       +--------------+
| Route de Nozay, 91460 MARCOUSSIS, FRANCE           |       |A L C /\ T E L|
| Voice : +33 1 64 49 13 73   Fax: +33 1 64 49 17 89 |       +--------------+
| E-mail: simatic@aar.alcatel-alsthom.fr             |        A L S T  H O M
|                                                    |       ================
| Always look at the bright side of life !           |           RECHERCHE	
|                             Monty Python           |     
======================================================

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 13:20:42 GMT
From:      rhufsky@csesys.csesys.co.at (Robert Hufsky C.S.E Systems)
To:        comp.protocols.tcp-ip
Subject:   NFS vs. NetBIOS



We are evaluating an Installation of MS-Windows PCs (mostly IBM 486's)
running LAN Manager/NetBIOS in parallel with TCP/IP stacks.
We evaluated Sun PCNFS and Wollongong Pathway Access.

The LAN media is 4MB Token Ring, the servers are PS/2 Model 90 for the
LAN Manager side and an RS/6k 340 for the TCP/IP NFS side.

When comparing the LAN Manager performance with the NFS performance we
see a heavy difference.

LAN Manager has a read/write throughput which is factor 10 better than
NFS troughput.

When installing TCP/IP NFS on an OS/2 client the throughput is almost
equal to the LAN Manager throughput so the server shpuldnt be a problem.

Any general ideas would be welcome





--


Robert Hufsky				Email: rhufsky@csesys.csesys.co.at

C.S.E Systems				Phone: ++43 463 50645 27
St. Veiter Strasse 4			Fax:   ++43 463 50677
A-9020 Klagenfurt

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 15:00:25 GMT
From:      lannie@picard.infonet.net (Lannie Schafroth)
To:        comp.protocols.tcp-ip
Subject:   Telnet Lockups

I am running a Wyse 9000i Unix System V/386 Rel3.2.1A
Whenever anyone from our other systems Telnets to this
system there process locks up.  It just stops displaying
and never frees up.  I found a Telnet package called QVT
for windows that works for me.  I found it has the  max
segment size set to 512, and the TCP window size set to 
4096.  This works perfectly with the Wyse.  How do I change
the Wyse settings to a normal standard?  We have to be able
to telnet to this system from other sources.

Any help would be appreciated.  I am using Pathworks 5.0,
and I configured it the same as QVT and nothing.  I must
change the Wyse.

Lannie@ins.infonet.net
Iowa Network Services, Inc.
System Admin. Wyse 9000i


-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 94 15:01:25 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: WOW!! Aint that cool

In article <CK61Ay.rv@news2.cis.umn.edu> klett@sunrayce.solar.umn.edu writes:
>anyone know the site where I can get MSDOS/Windows TCP software to
>connect my PC to a UNIX machine so I can share the network printers
>and other such stuff? Mount NFS?


I just got a copy of SuperTCP/NFS for Windows (Frontier Technologies Inc) for
$99.00 at the FedUNIX show in Washington DC.  It has email (SMTP or POP), NFS
CLIENT (Server opt.) vt320 telnet, ftp, NNTP news reader ping etc in addition
to an LPD client (server again opt.). Works with NDIS, ODI, packet driver.  

Just a happy (at least so far) customer

 
>
>---
>--------------------------------------------------------------------
>	James P. Klett			klett@sunrayce.solar.umn.edu
>					jimbo@oingo.umn.edu   (SLIP)
>--------------------------------------------------------------------
>	Slip Slipping' away...		NeXT Mail Preferred
>--------------------------------------------------------------------
>

Cliff

-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
cliffb@cjbsys.bdb.com


-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 15:05:31 GMT
From:      jt@fuw.edu.pl (Jerzy Tarasiuk)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

>>>>> On 19 Jan 1994 12:48 MST, gavron@hearts.aces.com (Ehud Gavron) said:
EG> In article <2hjp6t$3cn@hercules.neu.sgi.com>, ove@yoyo.neu.sgi.com (Ove Hansen) writes...
EG> #I've noticed that transferring files over slow links (serial or WAN) 
EG> #using NFS is far slower than using for example ftp, even though the NFS
EG> 	NFS uses 8192-byte UDP packets with its own retransmission
EG> 	specifications.  FTP uses 512 byte (576 including header) 

I have read several answers to this article and seems no one thinks
that 8kB packet has much less chance to get to destination than 512B
if there is any noise on the line. Assume 90% of 512 bytes packets
get to destination, 8kB packet about 18% chance, result is need to
send 5 times more when using long packets - of course, assuming in
case of error entire 8kB block must be retransmitted by NFS and only
the packets which are erronous by FTP (I guess if a packet is frag-
mented, reception is OK when all fragments come without error since
error on any packet causes entire block lost).

I also thinked about timeouts in case of fragmenting: there is a
timeout for reassembly (in IP layer), and timeout for waiting for
packet (in NFS), if any of them is too short many blocks can be lost.

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 16:09:44 GMT
From:      antony@inmos.co.uk (Antony King)
To:        comp.protocols.tcp-ip
Subject:   PD source to determine which process using a port

This may or may not be the correct news group but I was wondering if
there exists source (for a Sun-4 running SunOS 4.1.x or Solaris 2.x)
for a PD utility which given a port number (and possibly a host name)
can display information about a process using the port, for example
the process id, the user and the command plus its arguments.

It would also be nice if this utility could also provide information
about the remote host and port which are connected to the local host
and port.

BTW I am rather naive concerning ports and sockets so don't be suprised
if the above request and/or requirements does not make sense or is not
technically possible.

[FYI: I am trying to locate such a utility so that I am able to determine
who is using a sub-system of an IMS B300 on our network. An IMS B300 is an
INMOS product which provides access to Transputer networks over TCP/IP via
sockets.]

-- 
Antony King     INMOS Ltd, Bristol, U.K. | EMail(UK) ukc!inmos!antony
-----------------------------------------|     or    antony@inmos.co.uk
I am not mad, wibble wibble, I love UNIX | Internet: antony@inmos.com
                                         | UUCP:(US) uunet!inmos.com!antony

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 16:26:22 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip
Subject:   DHCP source

HI this is probably in a FAQ somewhere, but can nayone tell me where to get 
the DHCP server source code?

Thanks in advance!

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 16:50:57 GMT
From:      GMARTIN@lecs.ericsson.se
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?


In article <CK0H3o.MKz@ra.nrl.navy.mil>, <atkinson@itd.nrl.navy.mil> 
writes:
> Newsgroups: comp.protocols.tcp-ip
> Path: 
cnn.exu.ericsson.se!convex!cs.utexas.edu!howland.reston.ans.net!news.ca
c.psu.edu!news.pop.psu.edu!ra!atkinson
> From: atkinson@itd.nrl.navy.mil (Ran Atkinson)
> Subject: Re: death to GOSIP?
> Message-ID: <CK0H3o.MKz@ra.nrl.navy.mil>
> Sender: usenet@ra.nrl.navy.mil
> Organization: Naval Research Laboratory, DC
> References: 
 <MS-C.759116600.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU>
> Distribution: usa
> Date: Sat, 22 Jan 1994 03:16:35 GMT
> Lines: 28
> 
> In article 
<MS-C.759116600.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> 
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
> >The January 17, 1994 Network World has an article that states that 
 the Federal
> >Internetworking Requirements Panel has recommended that GOSIP be 
 scrapped
> >immediately.  It also stated the painfully obvious; that many 
 agencies have
> >bought software that is ``GOSIP compliant'' but never actually used 
 it, using
> >TCP/IP software instead.
> >
> >I for one would not shed any tears at the death of GOSIP.  Are there 
 any
> >perspectives on how far this will go?  Is this perhaps one more nail 
 in the
> >coffin of OSI?  Am I engaging in wistful thinking?
> 
> I dunno.  I did read the draft report and what I got from it was that
> GOSIP would not go away, but instead would be expanded to include the
> Internet protocol suite as a fully acceptable alternative to the ISO
> OSI protocols.  If I understand correctly, the government would have
> to at least get one of (Internet or ISO OSI) to comply with the
> revised GOSIP statement.  It also seemed to be more pragmatic and 
 said
> that the government activities should focus on how best to move bits
> to achieve their mission.
> 
> In the small number of years I've been at NRL, no one has ever asked
> me whether I had a GOSIP compliant machine.  When I asked for some
> OSI addresses to do some experiments, I was told that OSI addresses
> were not available.  As near as I can tell, GOSIP was always a myth.
> 
> Ran
> atkinson@itd.nrl.navy.mil
> 
From other threads in this group, it appears that your theory about 
GOSIP myth is correct.  It seems that some people do not even know that 
GOSIP exists.  I see questions about how to get IP addresses, etc.  If 
GOSIP was to be workable the word needed to have been given to 
everyone.  

Your comment about GOSIP expanding really says that either GOSIP is 
dead or we will be stuck with another meaning less acromnym.  After all 
OSI is in the center of GOSIP for a reason.

-Greg-

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 17:00:04 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   UUCP over TCP/IP for HP700 series?

Has anyone got this to work? Basically I need to know the correct
entries for the Systems and Devices files, plus any other gotchas
like /etc/services.....

Is this even a supported combination?

Please respond by E-mail if possible, as I am too busy to scan :=(

Leo@elmail.co.uk

(no sig, no time, no bandwidth. Terminal overload, brain going down on signal 15)))



-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 17:20:07 GMT
From:      dennis@cauchy.math.nwu.edu (Dennis Director)
To:        comp.protocols.tcp-ip
Subject:   Mosaic starter, not accessing net..


I have just received a binary of Mosaic to run on Linux.
I am using a SLIP connection.  When I start Mosaic,
the initial URL document can not be accessed.
I can however, from another process, ping
www.ncsa.uiuc.edu.  What else is necessary?
Thanks for any help.


-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 15:44:28 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4
Subject:   Re: Setting TCP/streams buffers??+ dead lock conditions

In comp.protocols.tcp-ip, article <2huq90$aqt@crl2.crl.com>,
  cgi@crl.com (Paul Smith) writes:
> say medium, and I cannot control this.  One process sends a lot of
> messages exhausting the limit of streams.  The process which could
> relieve the streams ( because it wants to read the messages ) cannot
> because it was just about ready to send some messages and gets 'hung'
> indefinately in a t_snd ( see above ) waiting for STREAMS internal
> resources to become sufficient; which will never happen.
> 
Probably true.

> How should I configure the transport providers to minimize this STREAMS
> deadlock situation?

You either use smaller buffers in SO_SNDBUF/SO_RCVBUF calls or you increase
the amount of memory reserved for Streams. There are a lot of kernel
parameters, one for message headers and one for every imaginable size of
Streams messages; you want the former and almost all of the latter, esp.
the bigger ones.

> Is it normal for a STREAMS network protocol implementation to just
> hang indefinately if it can't get STREAMS resources, or does it
> suggest a lacking design ( could they use some avoidance
> technique like raising the priority on one of the connections? ).
> 
The deadlock can happen with only one connection.

The only thing that the kernel can -- and should -- do, is to return
an error when you send() on a nonblocking stream and resources are
unavailable.
That seems like a kernel bug. Complain to your vendor.

> There is a kernal call something like bufcall or something, I don't
> remember exactly what.  Anyway witness this brief piece of text from a
> book on creating sreams based device drivers
> 
There's nothing you can do with bufcall from a network-using application.
Even if the TCP code uses bufcall, if all Streams blocks are blocked in
your receive queue and you're locked in send(), no block is freed anyway.

-- 
If I love you, what business is it of yours?
	-- Johann von Goethe (1749-1832)
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 18:32:21 GMT
From:      vikas@bau.cba.uh.edu (Vikas Gupta)
To:        comp.protocols.tcp-ip
Subject:   Charon configuration question

Hi Everyone,

I was not sure if I was posting this in the right newsgroup. So please
excuse me if it is the wrong newsgroup for this question.

We are using Charon - CUTCP software from the Clarkson University 
for running a mixed environment consisting of Novell Netware LANS
and TCP/IP based mainframes of  the University of Houston.  

There is an option on setting up a translator for the print jobs which
are sent from the mainframe to the Novell Queues.  But I have not been
able to get this  configuration  working though I seem to be doing 
everything fine. If anyone is working with similar stuff, could you 
mail me the configuration file "charon.dat".
I appreciate your help.

Thanks.
Vikas


--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
$ _/        _/   _/_/_/_/    |\/\/\/|	     *     Vikas Gupta                #
$  _/      _/  _/            |  \  /|        *     Dept. Of Computer Science  #
$   _/    _/  _/     _/_/_/  C (o)(o)        *     University Of Houston      #

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 18:43:52 GMT
From:      rmcgee@wiley.csusb.edu (Rich McGee)
To:        comp.protocols.tcp-ip
Subject:   Noise Detect on TCP Lans?


We are having a problem here that no vendor seems able to solve.
We are currently using a UB (Yuck!) network over twisted pair with
XNS, DECNET and TCP/IP on the same line. Someplace, we are intorducing
a large amount of noise into the network, resulting in very sluggish
TCP/IP response. Our diagnostic software ("NetDetect") will
only talk about packets, jabber (there is none) and such.
It ignores noise. What can we do to solve our problems?
Any commercial products out there that detect noise levels?
Thanks!
-Rich McGee
Cal State San Bernardino
rich@wiley.csusb.edu


-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 18:47:10 GMT
From:      tp@mx1.mdis.co.uk (Tim Preston)
To:        comp.protocols.tcp-ip
Subject:   lpr Client


I am trying to implement a lpr client.

All works ok if I know the size of the file I wish to print.

If I do not know the size of the file, accorindg to the rfc
(rfc1179) I can send a 0 as the file size. This does not
appear to work. Has anyone had experience of this ?

Any suggestions


Thnaks

Tim.
--
---------------------------------------------------------------------
Tim Preston                                 tpreston@mdis.co.uk 
McDonnell Information Systems               Phone: +44 442 272084           
					    Fax:   +44 442 234443           
---------------------------------------------------------------------

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 20:10:18 GMT
From:      mberg@netcom.netcom.com (Mike Berg)
To:        comp.protocols.tcp-ip
Subject:   How do you choose a port number for an application?

We are planning to release a new TCP/IP product that uses the inetd
daemon to start new instances of its server. To properly install our
product, we would expect the user to add an entry in the /etc/services
file and the /etc/inetd file (in local and remote machines as
appropriate).

Although the user could theoretically choose any unused port number
over 1024, we would like to have a suggested default port number in
our install instructions. 

We do not want to collide with other products, so how can we choose
a number?  Is there some official group that assigns numbers for this
purpose?  If not, it there some list available of the port numbers that 
currently available software uses?

Thanks,
Mike Berg 

-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 19:31:56 CET
From:      Ray Hunter <RHUNTER@ESOC.BITNET>
To:        comp.protocols.tcp-ip
Subject:   Multiple subnets on 1 physical wire

I'm aware that it is common practice to allow multiple subnets
on a physical wire in order to maximise address space efficiency.

Now the question is:

is it mandatory for a host to support this when it is running
a full subnet mask (i.e. not using proxy-arp)

more specifically, does anyone know if IBMs channel attach FDDI
interface comply with this?

10 browny points for the first person who can quote me
chapter & verse of the relevant RFC.

(-: I;ve tried to RTFM but I couldn't find it ;-)

Thanks in advance

Ray Hunter
RHUNTER@ESOC.BITNET
Cray Systems on contract to the European Space Agency

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 04:56:12 -0500
From:      grimes@access1.digex.net (Seth Grimes)
To:        comp.sys.unisys,comp.protocols.tcp-ip
Subject:   Lpr needed for Unisys A Series TCP/IP

A colleague asked my to post the following inquiry:

Given that Unisys has neither released lpd/lpr for TCP/IP, nor 
admitted to having scheduled development for this "product", I would 
like to find out if there's anybody in the world who has developped / 
adapted lpd/ lpr for the A Series TCP/IP?  We are (at this stage) 
interested in any product, commercial, academic, or private.

Thanks for any and all help.

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 94 21:22:40 GMT
From:      alan@kether.intellint.com (Alan M. Friedman)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Need help w/ Versaterm SLIP, MacTCP, etc.

In Article <2h1ecg$de6@news.u.washington.edu>, msbat@u.washington.edu
(Autumn Blanchard) wrote:
>
>I need some help getting MacTCP and Versaterm Adminslip, and my 
>SLIP account working.  I just bought The Internet Start Kit for 
>Mac (TISK) and I'm having problems with my new SLIP account at NW 
>Nexus.
>
>....
>
>So next, I tested the SLIP connection with MacTCP Watcher 1.1.0 
>and these are the overall results:
>
>          IP ADDRESS TESTED (entered in MacTCP Watcher's Dialog Box)    
>TEST      198.137.231.151 (their computer)    198.137.231.???* (mine)
>----      --------------------------------    -----------------------
>ICMP PING    successful test                    no response
>UDP ECHO     no response                        successful test
>TCP ECHO     no response                        successful test
>DNS          no response                        no response
>                                         *??? means I entered the IP
>                                         address assigned by the server
>
>...
>
>Thanks in advance for any help,
>Autumn Blanchard (and Walter Clinton)
>msbat@u.washington.edu

    It sounds like your default gateway might not be set.  You should
have "198.137.231.151" (their computer) in the Gateway Address under
Routing Information in the MacTCP CDEV.  That would explain being able
ping addresses, but not getting domain name service or UDP/TCP response.

Hope This helps,
alan
_____________________________________________________________________________
 \_\_\_                                       | Alan M. Friedman
    \_  \_\_\_        Artificial Intelligence | Intelligent Interfaces, Inc.
     \_    \_  \_\_\_         and             | (301) 299-6631|(301) 983-2211
    \_\_\_  \_    \_    Neural Netification   | alan@kether.intellint.com
           \_\_\_  \_                         | AppleLink:    D5620
                  \_\_\_                      | Compuserve:   72120,564
_____________________________________________________________________________

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 23:01:57 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   >>time sync protocol ?

> Does NTP address the problem of synchronizing audio/video/data
> as is required for real-time conferencing?  Or are there other
> protocols which address this issue?

Not directly.  But the existence of accurate timestamps makes the
synchronization problem easier.  There's a paper by Julio Escobar,
Debra Deutsch and myself coming out in IEEE/ACM Transactions on Networking
that describes synchronization across multiple sites and voice/video/data
streams which makes use of the fact that NTP has already distributed
accurate time.  (I think the paper is due for the February '94 issue, but may
be in the December '93 issue, which should be mailed shortly).

Craig

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 23:26:19 GMT
From:      hsn@verity.com (Hugh Njemanze)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there an RPC package for MACs, WinSock?

Raj says:

>Fellow Netters,
>
>	Is there a package similar to the Sun Remote Procedure Call
>available on the Macs? I would appreciate it if someone could direct me
>to either a PD or a commercial package.
>
>	Any and all responses appreciated on this matter.

I have the exact same question, and also the same for Winsock.

Thanks, Hugh

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 00:19:44 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

In article <1994Jan25.140008.23137@exu.ericsson.se> GMARTIN@lecs.ericsson.se writes:
>
>Your comment about GOSIP expanding really says that either GOSIP is 
>dead or we will be stuck with another meaning less acromnym.  After all 
>OSI is in the center of GOSIP for a reason.


Naah....  it stands for Go Open Systems with IP ......!!!

-- 

Phil Royse     Comms Consultant  |
TUDOR HOUSE                      |
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 00:46:06 GMT
From:      kanemoto@io.nosc.mil (Nelson Kanemoto)
To:        comp.protocols.tcp-ip
Subject:   Question regarding email directory services


Can anyone recommend an email directory service/lookup for a 
tcp/ip, smtp- based WAN.  Our WAN environment has a growing number of LANs
with Unix, Mac and PC computers.  The Unix WSs run AsterixMail via sendmail, 
the Macs MS Mail and the PCs use WP's mail package. The Macs and PCs have
their email linked to the Unix machines via smtp-gateways.  Users and
organizations are grouped by LANs and each organization would like to
maintain their own directory of users.

Appreciate any help :-)
Nelson
kanemoto@nosc.mil

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 01:10:58 GMT
From:      garryh@seeding.apple.com (Garry Hornbuckle)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Job Opening Apple N&C Prod Mgr

All,

I have an immediate need to hire an additional Product Manager, to work
with me in setting Apple's product plans and directions for Macintosh
networking. 

The ideal person will know networking - especially AppleTalk and TCP/IP -
inside and out. And you'll know the networking industry, especially the key
players and vendors that already help make Macintosh networking so cool.
You should be comfortable explaining technology to a wide variety of
audiences, from corporate excutives to MacWorld audiences, and you should
know your way around a spreadsheet - for looking at the business side of
things.

But most importantly of all, you should have a passion and vision for what
the user experience of networking can be / should be. If it's "information
at your fingertips", or "knowledge navigator", or "the information
superhigway toaster", you've got to be able to guide Apple's efforts in the
right direction.

Prior experience as a product manager is a big plus, but I'll teach the
right person the business side of things if we find the right energy,
passion, and vision. Prior experience as a developer can also be a plus.

The position is based at Apple's R&D headquarters, in Cupertino CA. Salary,
etc, is competitive. And even though I'm doing this renegade posting to the
net (i.e., this is not a formal "HR" kind of job posting) I feel compelled
to say that Apple offers an excellent work environment for all shapes,
kinds, colors, styles, etc. of people.

Please - serious inquiries only. This is an immediate need, so "graduating
next spring" won't work this round (sorry). If you are interested in
finding out more, please email me with a resume (preferrably) or at least a
voice # so that we can schedule so time to talk.

Thanks,
Garry

-- 
Garry Hornbuckle     Product Manager, Communications & Collaboration
                     AppleSoft OS Platforms Group

         Applelink:  HORNBUCKLE1
            e-mail:  garryh@seeding.apple.com 
--------------------------------------------------------------------

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 02:09:06 GMT
From:      heathh@cco.caltech.edu (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr Client

tp@mx1.mdis.co.uk (Tim Preston) writes:

>I am trying to implement a lpr client.
 
>All works ok if I know the size of the file I wish to print.
 
>If I do not know the size of the file, accorindg to the rfc
>(rfc1179) I can send a 0 as the file size. This does not
>appear to work. Has anyone had experience of this ?

	I have implented a lpr client, and I can tell you the following
discouraging things:

	The RFC was (poorly) written based on an existing implementaion
of the lpr/lpd protocol.  Whether the "0=unknown file length" option
ever worked is a matter of some question.
	
	BSD-based lpds will reject jobs submitted with length=0.  Whether
this is a bug or not depends on your philosophy, but they are not quite
RFC-compliant.

	Did you notice that the RFC provides no way to delimit end of file?
If you find an implementation that accepts files of unspecified length,
let me know how you indicate end-of-file to them.


	The issue of variable length files is an important one to implementors
of lpr-only clients.  In these setups, an lpr client reading from a pipe
must spool the print data to disk and then submit it, en masse, once it
has all been piped and the file size is known.  Obviously, this leads
to some resource problems.

Heath


-- 
--
From the Home for Amnesiac Computer Scientists....
  heathh@cco.caltech.edu


-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 94 10:31:10
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

> Your comment about GOSIP expanding really says that either GOSIP is 
> dead or we will be stuck with another meaning less acromnym.  After all 
> OSI is in the center of GOSIP for a reason.

The report in question stated quite clearly that the name would have to be
changed also... I urge everybody to read this report, it is well worth the
effort. I *especially* hope that those European governments that have
published their own "GOSIP"s read it.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 07:59:54 GMT
From:      jeg@gronja.kymmene.fi
To:        comp.protocols.tcp-ip
Subject:   Who is blocking my way to software.watson.ibm.com

I'm trying to contact software.watson.ibm.com, but so far I have failed.
Same thing with two other destination. With traceroute I can see which 
router my packets stops. What I should do ? I have talked with my local 
Internet-access provider, but they seem to be helpless (or uninterested). 
Here is what traceroute tells.

$ traceroute software.watson.ibm.com 
traceroute to software.watson.ibm.com (129.34.139.5) 30 hops max, 40 byte packets
 1  Datanet-router.kymmene.fi (XXX.XXX.XXX.XXX)  3 ms  3 ms  8 ms
 2  193.208.157.254 (193.208.157.254)  188 ms  33 ms  29 ms
 3  131.177.30.28 (131.177.30.28)  40 ms (ttl=250!)  39 ms (ttl=250!)  39 ms (ttl=250!)
 4  stockholm-ebs3.ebone.net (192.130.130.13)  73 ms (ttl=249!)  73 ms (ttl=249!)  73 ms (ttl=249!)
 5  Stockholm-EBS1.Ebone.NET (192.121.154.21)  75 ms (ttl=248!)  92 ms (ttl=248!)  78 ms (ttl=248!)
 6  icm-dc-1.icp.net (192.121.154.234)  196 ms (ttl=247!)  205 ms (ttl=247!)  185 ms (ttl=247!)
 7  icm-fix-e-S0-T1.icp.net (192.157.65.17)  186 ms (ttl=246!)  186 ms (ttl=246!)  216 ms (ttl=246!)
 8  * * *
 9  * * *
10  * * *

Thanks for any help.


Jan-Erik Gron           E-mail: kymmene.kh.gronja@elvi.vtkk.fi
Kymmene Corporation     Fax:    +358-51-402 2241
Finland                 Phone:  +358-51-402 2314

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 15:20:44
From:      scottb@iastate.edu (B. Scott Bilas)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,alt.winsock
Subject:   Re: Minimal Telnet

In article <2i6jvq$p6j@elna.ethz.ch> pkarrer@bernina.ethz.ch (Peter Karrer) writes:

-I have the following requirement for a "behind the scenes" Telnet interaction:
-* Login to a host (issue username and password)
-* Run a command
-* Capture the command's output (one line written to stdout)
-* Logout.
[...]
-Any other ideas?  A Winsock telnet implementation with sufficiently powerful
-scripting capabilities would be fine, but I haven't seen such a product.

QVTNet has scripting, I believe.  I've never used QVT scripts, though, so I 
don't know just how powerful it is.

-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-
Scott Bilas <scottb@iastate.edu>|"Bomb, this is Lieutenant Doolittle! You
   Terris Engineering Company   | are  NOT to detonate  in the  bomb bay!
"Bandwidth,superhighway,system" | Disarm  yourself!  This  is an  ORDER!"

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 10:50:56 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <JT.94Jan25160531@albert5.fuw.edu.pl> jt@zfja-gate.fuw.edu.pl (Jerzy Tarasiuk) writes:
>I have read several answers to this article and seems no one thinks
>that 8kB packet has much less chance to get to destination than 512B
>if there is any noise on the line. Assume 90% of 512 bytes packets
>get to destination....

Better not assume that.  A 10% packet loss of 1500 byte Ethernet fragments
is good for a 90% lost NFS throughput with the common default timeouts.
Those who are so enamored of NFS over TCP are right that NFS was designed
for local area networks where the error rates are insignificant.

> ...
>I also thinked about timeouts in case of fragmenting: there is a
>timeout for reassembly (in IP layer), and timeout for waiting for
>packet (in NFS), if any of them is too short many blocks can be lost.

The common 0.7 second default timeout for NFS is a long way for "too
short."  It is a factor of 2, 3, or even 7 too long for computers of this
day and age, instead of 1984.  Today, if you don't get an answer from the
NFS server in 0.2 seconds, either the server is grossly overloaded or you
are never going to get that answer.

To check assumptions or guesses about error rates, use the `nfsstat` and
`netstat` commands on your favorite system to look for NFS retransmissions
and IP "fragments dropped after timeout" as well as Ethernet errors.


Vernon Schryver,  vjs@sgi.com

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 11:37:11 GMT
From:      mgic <mgic@mixcom.mixcom.com>
To:        comp.protocols.tcp-ip
Subject:   Wanted: SLIP software for (Dell's) Sys V r4


I'm trying to find SLIP software for Sys V r4. Archie finds lots of software
for BSD/Suns, but not Sys V r4.

I want software that:

	- will automatically disconnect from a tty when the modem hangs up
	- looks up the caller's IP address in a table
	- logs connections (time on, time off, elapsed time)

I'll *buy* software that does this. Any idea where I can get software?

Yes, I know Dell provided some SLIP software, but it does not handle
on-demand dial-up. In other words, when the modem disconnects, the SLIP
driver does not automatically disconnect from the tty - it must be
manually disconnected by root.

Dean
-- 

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 23:15:27 -0600
From:      oliver@cs.utexas.edu (Oliver Yehung Hsu)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip books

Another good book on TCP/IP is "TCP/IP Network Adminstration" by Craig Hunt
(ISBN 0-937175-82-X).  This book is part of the O'Reilly Nutshell Series.


-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 12:02:16 +0100
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip,comp.sys.sun.apps
Subject:   Re: OOB data questions (SunOS specific)

In comp.protocols.tcp-ip, article <CK6Az1.7vx@olsen.ch>,
  robert@olsen.ch (Robert Ward) writes:
> 1.  In the Sun documentation ("An Advanced Socket-Based Interprocess
> Communications Tutorial"), it states:
> 
>     Worse, there may be enough in-band data in the input buffer that
>     normal flow control prevents the peer from sending the urgent
>     data until the buffer is cleared.
> 
There are no OOB data in TCP/IP, no matter what the BSD socket interface
calls them. TCP has an "urgent pointer", which tells the application that
"important" data are arriving. The definition of important and the exact
semantics of the urgent pointer are up to the application.

If you want true out-of-band data, open another TCP connection.

-- 
Grosch's Law:
2  Twenty percent of the components account for eighty percent of
   the cost, and so forth.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 23:54:45 -0600
From:      oliver@cs.utexas.edu (Oliver Yehung Hsu)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP

M J HART (mhart@rowan.coventry.ac.uk) wrote:

: I have to right an assignment on TCP/IP and know nothing about this protocol,
: i need any information on the history of this protocol and the ussaly sort of
: pros and cons of this protocol over the ISO model
 
: I would be really greatfull if anybody can help me via Email.
: -- 
: ************************* Barclays Bank: An institution where you can borrow
: *      M A T T          * money if you present sufficient evidence that you 
: * mhart@uk.ac.cov.rowan * don't need it!!!!!!!!
: *************************

Another good book is "TCP/IP Network Adminstration" by Craig Hunt 
(ISBN 0-937175-82-X).  This book is part of the O'Reilly Nutshell series.

Oliver


-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 00:03:38 -0600
From:      oliver@cs.utexas.edu (Oliver Yehung Hsu)
To:        comp.protocols.tcp-ip
Subject:   Re: How to FTP from an application

rajeev.dolas (rajeev@cbnewsf.cb.att.com) wrote:

: Hello all,
 
: 	I need to FTP some files from a server over a WAN within my 
: 	application.  The question is : What is the best way of achieving
: 	this task?


The way I've always done it is through a simple system() call.  I've never
encountered the problem you experienced w/ p2open.  Using the system() call,
will allow users to interactively login & specify what file to transfer.

You may also want to consider use of the .netrc file, which will allow you to
automate ftp logins & transfers.

Oliver Hsu

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 14:27:28 GMT
From:      snelling@fys.ruu.nl (snelling)
To:        comp.protocols.tcp-ip
Subject:   WFW 3.11 and a 286 as a file server

Hello,

I was wondering if somebody already tried the MSDOS package
from microsoft (mswgcn*.exe) to make a xt or at(286) file server for the
WfW network.
I tried it and everything installed ok but if i use 'net' it can not find the
workgroup and all the shared drives. Is there a manual available?


-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 14:54:11 GMT
From:      ebrill@usr.com (Ed Brill)
To:        comp.protocols.tcp-ip
Subject:   fingerd to respond to all fingers

Our Internet mail gateway is set up to relay through a UNIX mailer on a 
machine with no local users.  What I'd like to do is set up a generic, default 
response to any "finger user@usr.com" responses that spits back a canned 
message.  This would cut down on the (almost daily) messages "How do I e-mail 
your support department?  What is so-and-so's e-mail address?"

Any ideas or voluntary assistance would be most appreciated.

--Ed


Ed Brill  KA9TAW     E-Mail/Internet Administrator  Sales:   salesinfo@usr.com
ebrill@usr.com       U.S. Robotics, Inc.            Support: support@usr.com
postmaster@usr.com   Skokie, Illinois USA           Phone:   +1-708-982-5010

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 94 15:04:25 GMT
From:      dotytr@nscultrix2.network.com (Ted Doty)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <JT.94Jan25160531@albert5.fuw.edu.pl> jt@zfja-gate.fuw.edu.pl (Jerzy Tarasiuk) writes:
>>>>>> On 19 Jan 1994 12:48 MST, gavron@hearts.aces.com (Ehud Gavron) said:
>EG> In article <2hjp6t$3cn@hercules.neu.sgi.com>, ove@yoyo.neu.sgi.com (Ove Hansen) writes...
>EG> #I've noticed that transferring files over slow links (serial or WAN) 
>EG> #using NFS is far slower than using for example ftp, even though the NFS
>EG> 	NFS uses 8192-byte UDP packets with its own retransmission
>EG> 	specifications.  FTP uses 512 byte (576 including header) 
>
>I have read several answers to this article and seems no one thinks
>that 8kB packet has much less chance to get to destination than 512B
>if there is any noise on the line. Assume 90% of 512 bytes packets
>get to destination, 8kB packet about 18% chance, result is need to
>send 5 times more when using long packets - of course, assuming in
>case of error entire 8kB block must be retransmitted by NFS and only
>the packets which are erronous by FTP (I guess if a packet is frag-
>mented, reception is OK when all fragments come without error since
>error on any packet causes entire block lost).
>
A I remember it, most cases of packet loss in WANs are due to congestion
in the routers.  If this is the case for your lines (your mileage may
vary), than UDP is a big loss and TCP is a big win, assuming slow start.
Dave Clark gives an extremely good seminar at Interop on protocol
performance; I think this issue was discussed in some depth.

More specifically, your point about UDP sending 5 times underlines the
fact that under congestion, UDP makes things worse, not better.  A TCP
with slow start and congestion control algorithms will throttle itself
to protect the lines.

- Ted

--------------------------------------------------------------------------
Ted Doty, Network Systems Corporation | phone:      +1 301 596-2270
8965 Guilford Road, Suite 250         | fax:        +1 410 381-3320
Columbia, MD, 21046 USA               | voice mail: (800) 233-1485
--------------------------------------------------------------------------
These opinions are my own, not necessarially those of Network Systems.

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 15:22:44 GMT
From:      lemke@mitl.MITL.Research.Panasonic.COM (Kennedy Lemke)
To:        comp.protocols.tcp-ip
Subject:   SLIP help on Annex needed

Hello--

I'm trying to set up slip for both dial-in and dedicated line
on an Annex terminal server running version 8.0 of the OS.

SLIP clients dial in and start their slip session from the CLI
by issuing the slip command.  IP addresses are assigned dynamically
on a per-username basis.  This all seems to be working fine, except
that when the slip connection is finally established, IP doesn't
work.  None of ping, telnet, ftp produce any results.

Symptoms: client side attaches to cli, types "slip" and the annex
displays the correct IP addresses based on the acp_dialups file.
Attempted TCP/IP/ICMP accesses from both sides directly to the
other side of the slip link show modem activity, but neither side
responds to the other.  netstat -in on the client side shows
packets being received in response to traffic requests, but
neither side responds to the other.  We are using multitech
modems.

We've tried this using Sun, Mac, and PC (running mach) clients,
and all have similar results.  I suspect I'm just missing one
small bit of information.

Things we've tried:

	--The manual suggests setting the "mode" on the port to
	  "cli" but when we do this, two bad things happen: (1) the
	  port logs cli timeouts to acp_logfile every 30 seconds;
	  (2) when we dial the number, we don't get the cli prompt.
	  So I've set mode to "adaptive" which returns the cli
	  prompt on dialin, but slip doesn't work.

	--Routing: I'm hoping to get by without having to purchase
	  the $195 active RIP package.  Problem doesn't *seem* to
	  be RIP-related because traffic won't even go point-to-point.
	  I don't have any information in the "gateways" section
	  of the annex.config file because it looks like a passive
	  route is established as a result of the "slip" command.
	  Will adding routing information to the config file help?

	--I'm using the same flow control settings for the modems that
	  we use for terminal-based dialup, which I thing should work,
	  correct?

Surely somebody has run across this same problem.  Can you please
email me with suggestions/solutions?  Thank you.

				Kennedy Lemke
    ,    ,     ___  ______	
   /|   /|     /      /     /	Computer Systems Manager
  / |  / |    /      /     /	Postmaster && News administrator
 /  | /  |   /      /     /	Matsushita Information Technology Laboratory
/   |/   | _/_     /     /____	Panasonic Technologies, Inc.
				2 Research Way
Work Phone: (609) 734-7329	Princeton, New Jersey  08540-6628
Fax:        (609) 987-8827	Email: lemke@Research.Panasonic.COM

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 94 15:26:20 GMT
From:      dane@cheryl.incg.com
To:        comp.protocols.tcp-ip
Subject:   STREAMS implemented protocols


I have questions on 2 different topics, both having to do with
networking.

1)
I am looking for some possible information about the TCP.  I am
programming on SCO unix V3.0 and I am using the SYSV TLI to
access the TCP/IP for communication between processes ( both remote
and local).  This particular version of the SCO operating system also
provides a protocol stack for sending IPX/SPX transmissions over the
etherenet device concurrently, also (in fact only) accessable through
the TLI.  I had written a small sample program that simulated the
actions which might occur between a client and server ( send a
request, get a response ).  I noticed that when using the SPX
connections the speed was nearly 10 times more than for TCP.  My
particular example happened to send 2 packets back to back for the
response and I hypothesized that there was some kind of timer in 
my TCP implementation that was waiting to 'coalesce' packets for
better utilization of the network bandwidth.  I suspected this because
I noticed an incredible speedup ( almost to the level of SPX ) when I
sent packets of 1024 bytes.  Our documentation for TLI sadly said that
no option management was available for TCP; however after consulting
tech support from SCO I discovered a TCP_NODELAY option.  The comment
in the header file said 'don't wait to coalesce packets'.  Great! I
thought, this should help; but the performance increase was very
little.  My questions are : Are there other well known things like
TCP_NODELAY that all of the well-written TCP applications use that
don't seem to have any speed problems?  Is my OS implementation of TCP
just slow?  Is the TLI adding some unneeded overhead ( as oppossed to using the
sockets interface maybe? If I use the BSD sockets interface and set
the TCP_NODELAY option I don't have any speed problems). 


2)
My other questions have to do with STREAMS implementations of
networking protocols ( I am not attempting to implement one).  I do not
know any great detail about this practice but I have a question about
how to deal with what seems to be a deadlock situation given my
current understanding.  According to my OS documentation streams are
available for processes from the kernel at 3 different priority levels.
Low and medium priority requests are subject to the restrictions of a
kernel parameter which will refuse them if the total number of streams
in use has exceeded a certain limit.  High priority requests are
always filled if the physical kernel resources are available.  The
default cutoffs are 80% 90% 100% for low,med and high.  My
documentation for the TLI says that t_snd will block indefinitely
reguardless of the O_NDELAY flag if STREAMS internal resources are
insufficient to complete the operation.  I have on several occassions
locked up all network traffic on my machine with what I hypothesize is
the following situation:

First, it seems like my OS will let me send messages to another
process until it has exhausted all available STREAMS and then finally
report that flow control is present for the connection.  Is this
normal?  Is there some way to adjust the point at which flow control
is reported? I notice that in the Berkely Sockets interface there are
options for SO_SNDBUF and SO_RCVBUF.  Are those the options I need?  
I believe that the TLI always requests its streams at the same level,
say medium, and I cannot control this.  One process sends a lot of
messages exhausting the limit of streams.  The process which could
relieve the streams ( because it wants to read the messages ) cannot
because it was just about ready to send some messages and gets 'hung'
indefinately in a t_snd ( see above ) waiting for STREAMS internal
resources to become sufficient; which will never happen.

How should I configure the transport providers to minimize this STREAMS
deadlock situation?
Is it normal for a STREAMS network protocol implementation to just
hang indefinately if it can't get STREAMS resources, or does it
suggest a lacking design ( could they use some avoidance
technique like raising the priority on one of the connections? ).

Please also mail replies to me at dane@incg.com, as I do not receive
this news group.

Thanks
--
-- 
// Email: dane@incg.com         Organization:   Integrated North Coast
// Name: Dane Bills
//
// Error of opinion is tolerable; so long as reason is left 
// free to combat it.


-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 94 16:29:54 GMT
From:      conbvs@melupl (Bill VerSteeg (Contract))
To:        comp.protocols.tcp-ip
Subject:   Novell and WinSock ?

I have been looking through the Novell documentation, and
I can't tell if they support WinSock or not.

SO, can someone tell me if Novell ships a winsock.dll?

Please send reply to bvs@ver.com- the name resolver
on this client's machine is hosed. 

-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 17:00:27 GMT
From:      wls@magrathea.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr Client

In article <2i4jc2$5fc@gap.cco.caltech.edu>, heathh@cco.caltech.edu (Heath Ian Hunnicutt) writes:
> 	BSD-based lpds will reject jobs submitted with length=0.  Whether
> this is a bug or not depends on your philosophy, but they are not quite
> RFC-compliant.

Actually, it makes more sense to say that the RFC isn't BSD-compliant.  :-)
The RFC is descriptive only, and came along *LONG* after the lpd protocol
was in widespread use.  It was apparently based on the screwiest available
implementation - I've never seen some of the things documented there.  Of
course, I probably will now, since people are writing to that spec.

--
Bill Stapleton
     wls@magrathea.csd.uwm.edu
     uwmcsd4!wls

-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1994 22:54:49 +1100
From:      rjtqiaa@werple.apana.org.au (Robert Tudor)
To:        comp.protocols.tcp-ip
Subject:   PC to UNIX Connection

I'm having a problem running a PC connection to UNIX.

I am using JSB Multiview Desktop on a 486DX50 PC running Windows 3.1
and DOS 6. Using a TCP/IP connection supplied as part of the package.
The PC is connected to an EISA Bussed ALTOS 4500 (Intel 486) with
8Mb of RAM under SCO UNIX Release 3.2V2.0 and Version 2.1aC0
with Kernel Id 91/11/08 and running the Multiview Desktop Host Support
module.

The connection works fine without the host support module activated, but
as soon as I activate the host support module throughput on the connection
drops drastically.  Output from the host to the PC seems to run at reasonable
speeds input from the PC to the host drops to about 300 bits per second which
makes the connection totally unworkable.

This configuration worked fine on an Altos 15000 running Release 3.2.4.

I have installed the upgraded psuedo-tty support as recommended but to no avail.

Any one experienced this problem or got any ideas?

Thanks in advance

Bob Tudor



-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 17:55:50 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: SLIP software for (Dell's) Sys V r4

In article <1994Jan26.113711.19318@mixcom.mixcom.com> mgic <mgic@mixcom.mixcom.com> writes:
> ...
 
>                     ...  some SLIP software, but it does not handle
>on-demand dial-up. In other words, when the modem disconnects, the SLIP
>driver does not automatically disconnect from the tty - it must be
>manually disconnected by root.

"On-demand dial-up" or "demand-dialing" is commonly thought to be 
something else entirely.  What you have described is no more than what
some call "modem control," having the computer pay attention to DCD and
drop the link when it goes away.  The failure to hang up the phone when
the modem says carrier has died is often caused by misconfiguration of
the modem or computer, or bad (ie. 3-wire) cables.  I would expect any
commercial grade SLIP implemenation to pay attention to DCD, to have
"modem control."

There are two forms or degrees of "on-demand dial-up".  In the simplest,
which I prefer to call "camping," one computer pays attention to DCD
(i.e. has "modem control") and whenever the modem says the phone is hung
up, tries to redial and restore the link.  This is fairly easy to implement
and trivial to install.  It can tie up phone lines for a long time.

What is commonly called "demand-dialing" is having either or both
("symmetric demand-dialing") computer call the other only when when traffic
is available and to turn off the modem and phone line when there is no
network traffic.  This is more interesting to implement (I know of only
one symmetric demand-dialing SLIP implementation, but there may be others).
Because of routing hassles, it often requires more knowledge to install.


Vernon Schryver    vjs@rhyolite.com

-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 18:11:34 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Noise Detect on TCP Lans?

Rich McGee (rmcgee@wiley.csusb.edu) wrote:

: We are having a problem here that no vendor seems able to solve.
: We are currently using a UB (Yuck!) network over twisted pair with
: XNS, DECNET and TCP/IP on the same line. Someplace, we are intorducing
: a large amount of noise into the network, resulting in very sluggish
: TCP/IP response. Our diagnostic software ("NetDetect") will
: only talk about packets, jabber (there is none) and such.
: It ignores noise. What can we do to solve our problems?
: Any commercial products out there that detect noise levels?

Sounds like you need an electrical engineer to take a look at it.

-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 19:09:37 GMT
From:      hurley@robadome.com (Jim Hurley)
To:        comp.protocols.tcp-ip
Subject:   BSD kernel tsleep and wakeup calls in sockets

I am porting the Berkeley socket kernel code to a different
OS environment. An associate and I have noticed that the
networking code made many calls to "wakeup()" at certain times
when it would be unnecessary - that is, the socket application
would not be blocked or sleeping. We have handled this in our port
but were wondering why the kernel would make such calls.

On looking through the source for wakeup() we deduced that in order
for the kernel to know the process was asleep it would have to hash into
the sleep queue and perform practically all the steps wakeup() did anyway.
Since wakeup() does nothing if no processes are suspended this is OK, but
in our case we can't do that (we have a counting semaphore OS).

At any rate, in more modern kernels I was wondering if this is done differently,
because the number of processes hashed into the sleep queue may make these
calls significant real-time hits. 

---
Jim Hurley       E-mail: hurley@robadome.com   GEnie: J.HURLEY1 
ROLM - A Siemens Company
PBX SW Development - Callbridge Applications     (408)-492-2228




-----------[000523][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 20:31:54 GMT
From:      pkarrer@bernina.ethz.ch (Peter Karrer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,alt.winsock
Subject:   Minimal Telnet

I have the following requirement for a "behind the scenes" Telnet interaction:
* Login to a host (issue username and password)
* Run a command
* Capture the command's output (one line written to stdout)
* Logout.

This should happen under the control of a program, invisible to the user
(except being prompted for username/password). Environment is Windows 3.1
(Winsock). (The remote host doesn't have a rexecd.)

Do I have to take care of Telnet's subtelties for this task, or can I just
happily do the necessary send()s and recv()s?  That is, ignore negotiation
and full-duplex issues.

Most probably it isn't so; at least responding to negotiation attempts from
the other side seems necessary.  I was thinking about porting the Telnet
client from the Comer/Stevens book to Winsock; I have the source code,
but it is very UNIXish and porting wouldn't be trivial (for me).

Any other ideas?  A Winsock telnet implementation with sufficiently powerful
scripting capabilities would be fine, but I haven't seen such a product.

-- 
Peter Karrer                                   pkarrer@bernina.ethz.ch

-----------[000524][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 21:37:44 GMT
From:      mxer@kauri.vuw.ac.nz (Frank Jansen)
To:        comp.protocols.tcp-ip
Subject:   X network capacity

Greetings,
          Does anyone have or know the wherabouts of a program to measure the
load placed by X on a servers network capacity ? We have a TCP/IP based network
on which there are a number of servers. We'd like to run a program on a unix
system, SGI, to measure how much of the network capacity is being used by X on a
network chunk connected to the server. Thanks in advance.

-- 
Frank Jansen, mxer@kauri.vuw.ac.nz ,           Phone: +64 4 4965416
Information Technology Services,        *   *  Fax:   +64 4 4715386
Victoria University of Wellington,        |  
P.O. Box 600, Wellington, New Zealand.  \___/  Callsign: ZL2TTS

-----------[000525][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 21:48:24 GMT
From:      caj9556@c57.ucs.usl.edu.ucs.usl.edu (Jones Christopher A,,,,9556)
To:        comp.protocols.tcp-ip
Subject:   Re: FAQ??

In article oH9@yuma.ACNS.ColoState.EDU, vogety@CS.ColoState.EDU (ramanagopal vogety) writes:
> 
> Does anyone maintain a FAQ for this newsgroup?
> 
> -Gopal

I second the motion.... please send email.

Chris Jones
caj9556@usl.edu



-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 21:52:46 GMT
From:      tom@ltoc-ils.ltoc.lockheed.com (Thomas R. Stephenson)
To:        comp.protocols.tcp-ip
Subject:   WINTEL

Has anybody been successful in getting WINTEL from NCSA to run using 
winsockets.  I keep getting an error.

Thomas R. Stephenson O/42-10 B/575 Phone: (408) 743-2971
Lockheed Technical Operations Co.  Fax:   (408) 742-3890
1309 Moffett Park Drive, Sunnyvale, CA   
Net: tstephenson@lmsc.lockheed.com


-----------[000527][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 22:13:16 GMT
From:      stan.huyge@ClemsonSC.NCR.COM (Stan Huyge)
To:        comp.protocols.tcp-ip
Subject:   Specification for uuencoded files

If someone knows where to find the specification for uuencoding files, I would 
appreciate it if you could post or mail a response.

Thanks,
Stan

stan.huyge@clemsonsc.ncr.com

-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 09:22:04 -0600
From:      Joe.Van.Demark@f31.n282.z1.tdkt.mn.org (Joe Van Demark)
To:        comp.protocols.tcp-ip
Subject:   TLI tcp/ip on IBM RS/6000

 I'm attempting to program a client server application using TLI on a IBM      
RS/6000, AIX 3.2. I've found the TLI library under /lib/tlilib.a but am       
unable to locate the file identifying the transport provider for TCP/IP.        
     
 according to R. Stevens in UNIX NETWORK PROGRAMMING: you establish a 
 transport endpoint via the call t_open specifiying the transport provider
 as the first parameter i.e.

    t_open( "/dev/tcp", ..... ); as in the example on p. 363

 Unfortunately this dev does not exit. 

 Has anyone done any TLI programming on the IBM RS/6000 and found the   
 appropriate dev/file identifying the transport provider, or maybe it isn't
 installed though the tli library is there.

 Any help or direction would be appreciated. Thanks in advance

 
 e-mail VNDJ02@NSPRSCS.IBMMAIL.COM

 * Origin: Dark Knight's Table (1:282/31)

-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 23:28:43 GMT
From:      rturner@aqm.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD kernel tsleep and wakeup calls in sock

In article ce@mack.eng.sc.rolm.com, hurley@robadome.com (Jim Hurley) writes:
>I am porting the Berkeley socket kernel code to a different
>OS environment. An associate and I have noticed that the
>networking code made many calls to "wakeup()" at certain times
>when it would be unnecessary - that is, the socket application
>would not be blocked or sleeping. We have handled this in our port
>but were wondering why the kernel would make such calls.

/*
   I do not have BSD source in front of me, but I was wondering if there
   is a PCB-based state bitmask that might contain a 'wakeup-pending'
   bit in it.  If there is, then the code you are porting might post
   this state to a process, should it call sleep() later...(?)

   If the wakeup() call just 'returns' if the process is NOT asleep, then
   of course, the call would be redundant; barring any other side effects
   of calling wakeup().

   Randy
*/

>
>On looking through the source for wakeup() we deduced that in order
>for the kernel to know the process was asleep it would have to hash into
>the sleep queue and perform practically all the steps wakeup() did anyway.
>Since wakeup() does nothing if no processes are suspended this is OK, but
>in our case we can't do that (we have a counting semaphore OS).
>
>At any rate, in more modern kernels I was wondering if this is done differently,
>because the number of processes hashed into the sleep queue may make these
>calls significant real-time hits. 
>
>---
>Jim Hurley       E-mail: hurley@robadome.com   GEnie: J.HURLEY1 
>ROLM - A Siemens Company
>PBX SW Development - Callbridge Applications     (408)-492-2228
>
>
>





-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 23:31:19 GMT
From:      kusogari@XENIX.shef.ac.uk (Earl H. Kinmonth)
To:        comp.dcom.telecom.tech,comp.protocols.ibm,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.os2.networking,comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject:   x25/x29 with tcp/ip over ethernet

What software is available to provide x25/x29 (pad) type connections
over ethernet preferably in conjunction with tcp/ip?

The University of Sheffield has a package called Rainbow that does this,
but it does not seem to work with NE2000 cards and ODI drivers.

Please mail a copy of your reply to

cck@kuso.shef.ac.uk

-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 01:41:56 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr Client

In article <2i4jc2$5fc@gap.cco.caltech.edu> heathh@cco.caltech.edu (Heath Ian Hunnicutt) writes:
>	The RFC was (poorly) written based on an existing implementaion
>of the lpr/lpd protocol.  Whether the "0=unknown file length" option
>ever worked is a matter of some question.

The 0 == unknown file length was specificly added to the protocol to
accomidate PC programs that just want to throw bits at LPT1:.  It
wasn't in the original BSD implementation, nor is compatible with the
BSD implementation of the protocol.

The RFC was written several years after lpr/lpd were in widespread use
and corrected a number of small, minor (and not so minor) problems
with the original protocol.  The 0 length file is one of the few
things that weren't backward compatible....

Bottom line:
	The RFC describes a nice protocol for printing that is almost,
but not quite, the same as is in wide spread use under the same name.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000532][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 15:15:22 -0600
From:      a-steiner@nwu.edu (Albert Steiner)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: INPUT WANTED: InterSLIP vs. VersaTerm SLIP vs. MacSLIP

In article <greene-250194104301@darkstar.cs.umass.edu>, greene@cs.umass.edu
(John Greene) wrote:

We have had great results with Macslip.
One problem we needed to solve was to set our terminal server to buffer 24
buffers instead of 3.  MacSlip sets its window for about 20 buffers.  If
you don't have that buffered at the terminal server, it throws away a lot
of packets because there is no place to put them, then the mac times out
waiting for a packet, then the mac starts up the transfer again getting a
lot more retransmits.

Talk to your terminal server administrator.

> 
> Hi --
> 
>   We are having some problems with SLIP on our macs here.  People who
> are using unix machines w/ SLIP report no problems, but the same errors
> are consistantly being reported w/ the mac.  File transfers (with Fetch)
> hang unless you ping the slip node from a telnet window, throughput is
> godawfulslow, Mailstrom sometimes bombs, etc.  We are currently using
> VersaTerm because when we got interslip we only had mactcp 1.1.1, now
> that we have 2.04, I'm considering trying InterSLIP again.
>   I guess I want to hear from folks who have a successful SLIP environ-
> ment on the mac.  If you do, please e-mail me so we can exchange notes.
> Thanks in advance.
> 
> -- 
> 
> Take care,
> 
> -jg              greene@cs.umass.edu - RCF Macintosh Specialist
>       Department of Computer Science - University of Massachusetts
>            [work ip]  128.119.41.182 - (413) 545-5733  [work phone]
>            [home ip]  128.119.43.33  - (413) 253-0744  [home phone]
>                     yeP! Keyboardist - Newton Enthusiast
 
-- 
Albert Steiner          708-491-4056  FAX 708-491-3824
Academic Computing and Network Services, Northwestern University
2129 North Campus Drive, Evanston, IL 60208-2850  a-steiner@nwu.edu

-----------[000533][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 06:08:44 GMT
From:      chadhinton@delphi.com (Chad Hinton)
To:        comp.protocols.tcp-ip
Subject:   Re: X network capacity

>Greetings,
>          Does anyone have or know the wherabouts of a program to measure
 the
>load placed by X on a servers network capacity ? We have a TCP/IP based
 network
>on which there are a number of servers. We'd like to run a program on a
 unix
>system, SGI, to measure how much of the network capacity is being used by X
 on a
>network chunk connected to the server. Thanks in advance.
> 
>--  
>Frank Jansen, mxer@kauri.vuw.ac.nz ,           Phone: +64 4 4965416
>Information Technology Services,        *   *  Fax:   +64 4 4715386
>Victoria University of Wellington,        |   
>P.O. Box 600, Wellington, New Zealand.  \___/  Callsign: ZL2TTS
> 

I believe Network Generals Sniffer protocol analyzer has this capability.
It's pricey but good.

Chad Hinton
Sr. Network Engineer
J.B. Hunt Transport, Inc.
chadhinton@delphi.com    'Any opinions expressed are expressly my own.' 


-----------[000534][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 14:48:51 -0500
From:      xxronr@lerc.nasa.gov (Ron Rivett)
To:        comp.protocols.tcp-ip,comp.sys.misc,comp.unix.misc,comp.unix.admin
Subject:   MAC to-from Unix printing


I am interested in obtaining any feedback on the products listed below.
The "MAC <--> Unix" printing requirement is a component of a Campus-wide,
network based printing project. 

We need a software product that will meet the following needs:

1)  It will run on a Unix platform (mostly Sun systems).

2)  It "understands" or supports the Apple EtherTalk protocols.

3)  It will allow Apple MACs to route print requests to print queues on the 
    Unix system  (i.e. the Unix system and its print queues  appear as
    a large quantity of Apple EtherTalk printers attached to the network).
    The printers "on" the Unix system will not be physically attached to 
    the Unix server, but will actually be connected to a TCP/IP based network, 
    and the Unix server will handle the queues and communicate with the 
    printers over the TCP/IP network.

4)  The Unix server system can route print requests out through the EtherTalk
    protocols to actual Apple EtherTalk printers, or even MAC printers 
    connected to MACs. This also assumes that any other host can send 
    print requests to the Unix server, which will then route the print
    request to the Apple printer. 

5)  DOES NOT require any special type of 'gateways'.


6)  Can support hundreds of printers and 1000+ users.   

       --------------------------------------------------------------

    MAC-to-Unix print
    =================            |-----------> TCP/IP network attached printer
                                 |
                                 |-----------> TCP/IP network attached printer
                                 |
    MAC -----------> Unix server |-----------> TCP/IP network attached printer
            ^                    |
            |                    |-----------> TCP/IP network attached printer
            |                    |
            |                    |-----------> TCP/IP network attached printer
            |                          ^
            |                          | 
         
         Apple EtherTalk           TCP/IP
         protocols                 protocols


       --------------------------------------------------------------


     Unix-to-MAC/EtherTalk print
     ===========================

                  
        Apple EtherTalk protocols         TCP/IP protocols
                    /                      /
                   /                      /
                  /                  |   /
     Apple       /                   |<----- IBM MVS mainframe with TCP/IP
     EtherTalk <------               |          and lpr/lpd command
     printer         |               |
                     |               |<------- Convex (Unix) minisupercomputer
     Apple           |               | 
     EtherTalk <------------- Unix   |<---------- Unix workstation
     printer         |     |  server |
                     |     |         |<--------- DOS PC with TCP/IP & lpr 
     Apple           |     |         |
     EtherTalk <-----|     |         |<------- Cray (Unix) supercomputer
     printer               |
                           |
                           |
                           |
     Apple   <---- Apple <--   <--- this mode is a "maybe"
     printer        MAC


------------------------------------------------------------------------------
			Pacer software

	1900 West Park Drive			7911 Herschel Ave.
	Suite 280				Suite 402
	Westborough, MA   01581-3909		La Jolla, CA  92037
	(508) 898-3300				(619) 454-0565

	product: PacerPrint
------------------------------------------------------------------------------
	Xinet
	2560 Ninth Street
	Suite 312
	Berkeley, CA 94710
	(510) 845-0555

	xinet@xinet.com
	sales@xinet.com

	product: K-Spool
------------------------------------------------------------------------------
	ipt - Information Presentation Technologies, Inc.
	555 Chorro Street
	San Luis Obispo, CA  93405
	(805) 541-3000
	info@iptech.com	

	product: uShare or Partner   with the Print Spooler option
------------------------------------------------------------------------------
	Alisa Systems
	221 E. Walnut St.
	Pasadena, CA 91101
        (800) 99-ALISA 
	(818) 792-9074

        product: ???
------------------------------------------------------------------------------




==============================================================================
Ronald R. Rivett                            voice: (216) 433-8281
Sverdrup Technology                 
NASA Lewis Research Center          NASA LeRC FAX: (216) 433-8000 
21000 Brook Park Road                      E-mail: rrivett@lerc.nasa.gov 
Cleveland, Ohio 44135                             
Mail Stop 142-2               
			"Who Watches the Watchers ?"
==============================================================================




-----------[000535][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 12:24:59
From:      ace@ics.forth.gr (Andreas C. Enotiadis)
To:        comp.protocols.tcp-ip
Subject:   Re: KERMIT file transfers via telnet...anyone???

In article <2i0pch$3r5@hubcap.clemson.edu> davidc@hubcap.clemson.edu (David S Condrey) writes:
>Path: news.forth.gr!EU.net!howland.reston.ans.net!europa.eng.gtefsd.com!emory!hubcap.clemson.edu!hubcap.clemson.edu!not-for-mail
>From: davidc@hubcap.clemson.edu (David S Condrey)
>Newsgroups: comp.protocols.tcp-ip
>Subject: KERMIT file transfers via telnet...anyone???
>Date: 24 Jan 1994 10:27:13 -0500
>Organization: Clemson University
>Lines: 17
>Message-ID: <2i0pch$3r5@hubcap.clemson.edu>


>Hi folks. I have a situation here where PC users using kermit for
>terminal emulation are dialing up to a terminal server which then starts
>a line mode telnet session with our MVS system. 

..Deleted
>Any ideas?  Thanks.
>-David
Seems to me your problem is the line mode telnet. I've used this kind of 
configuration quite often on various hosts but NOT in line mode. In fact I can 
do kermit transfers from compuserve using  a tortuous route that goes
telnet->hermes.merit.edu-pad->cserve using PC-NFS telnet which supports kermit 
transfers.
Andreas
--------------------------------------------------------------------------
Andreas C. Enotiadis
Internetwork Ltd
"Just screwing around - for a living"
ace@ics.forth.gr
ace@iesl.forth.gr
ace@praxis.forth.gr
Snail-Mail : 1 Louki Akrita Str, 15237 Athens, Greece
--------------------------------------------------------------------------

-----------[000536][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 16:57:53 -0500
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Questio on voice over TCP/IP

In article <CJIyw6.H7w@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil writes:

   In article <CJHIHr.GsI@sernews.raleigh.ibm.com> allensd@vnet.ibm.com writes:

   >   I think you really hit it on the head here.  TCP/IP was never really meant
   >   to carry isochronous traffic, hence any implementation of a isochronous
   >   application (e.g. voice, video..) will be a 'workaround' that involves
   >   a bit of buffering, and praying!

   I gather that you haven't been tracking the IETF/IRTF work on resource
   reservation mechanisms.  I'd suggest you look at the Internet Draft on
   RSVP (draft-braden-rsvp-* I think) as a starting point.

It seems to me that isochronous and IP work just fine together
IFF you are running at a high enough bit rate to keep the latency
down, and you can guarantee enough router cpu time on all possible routes.

Can someone give me a concrete reason why IP wouldn't work under
those constraints?  It seems like there's very little difference
between ATM and IP at that point (except of course that IP doesn't
have a fixed route ala ATM).

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000537][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 17:02:57 -0500
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   death to GOSIP?

In article <2hrsrl@sol.tis.com> mjr@tis.com writes:

   >Is this perhaps one more nail in the coffin of OSI?

           I think it's already past that point. The coffin has been
   nailed shut. This is just one more shovel-load of dirt into the
   hole. :)

           Just ignore the feeble scratching noises from inside
   the pine box down there and keep shovelling.

But wait, that may be /mtr down there!  :)

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000538][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 13:05:09 GMT
From:      hans@lu.se (Hans Rosenlund)
To:        comp.protocols.tcp-ip
Subject:   Gateway Ethernet cards

I have some computers with Gateway ethernet cards for IBM-PS/2 in a Novell 
network. Our new connection to the wide world demands TCP/IP protocol. When 
I configure these cards with the GEMCTCP they automatically get the 
interrupt address 0x60, which is in conflict with other routines.

Does anyone have a solution on how to configure to, e g  0x70? Or is it 
impossible?

-----------[000539][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 94 14:48:41 GMT
From:      pbrans@netxcom.netx.com (Pat Brans)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

In article <MS-C.759116600.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>The January 17, 1994 Network World has an article that states that the Federal
>Internetworking Requirements Panel has recommended that GOSIP be scrapped
>immediately.  It also stated the painfully obvious; that many agencies have
>bought software that is ``GOSIP compliant'' but never actually used it, using
>TCP/IP software instead.
>
>I for one would not shed any tears at the death of GOSIP.  Are there any
>perspectives on how far this will go?  Is this perhaps one more nail in the
>coffin of OSI?  Am I engaging in wistful thinking?

I didn't read the document the panel put out, but I spoke with someone who
did.  My understanding was that the panel recommends that TCP/IP be *part* 
of GOSIP.  In other words, they're saying that you can use TCP/IP and still
comply with GOSIP.  

This really doesn't say anything about the upper layer OSI protocols.  They
should all be able to run with TCP as a transport layer, providing a 
connection-oriented transport service like X.25 does.  

-----------[000540][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 23:46:57 -0500
From:      jl@panix.com (Jean-Louis Ecochard)
To:        comp.protocols.tcp-ip
Subject:   TCP IP Protoco verification Suite ?

 am looking for a suite or a series of programs that I would run to verify the
completeness of a TCP/IP implementation. I am interested in test most of the
protocols and services as well as performance. The network will be FDDI.
Thanks

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ O ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jean-Louis Ecochard                    /_\                Voice   (212) 866-4908
Network Research Group, Corp.         (_v_)               Internet  jl@panix.com

-----------[000541][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 15:44:16 GMT
From:      tmt@tonto.osf.org (Tom Talpey)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

In article <CK8Gsx.3FA@calcite.rhyolite.com>, vjs@calcite.rhyolite.com (Vernon Schryver) writes:
> The common 0.7 second default timeout for NFS is a long way for "too
> short."  It is a factor of 2, 3, or even 7 too long for computers of this
> day and age, instead of 1984.  Today, if you don't get an answer from the
> NFS server in 0.2 seconds, either the server is grossly overloaded or you
> are never going to get that answer.

Bunk. Try timing some non-idempotent operations like mkdir, rmdir, or
serious fileblock manglers like ftruncate. Even in this day and age they
can take seconds. All NFS clients should have Jacobson adaptive timers
in my opinion. NFS servers would be the targets of a lot less blame if
they did.

Tom Talpey.
tmt@osf.org

-----------[000542][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 94 15:52:32 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP

In article <758919146snx@crynwr.com>, nelson@crynwr.com (Russell Nelson) writes:
|> In article <2hfpfeINN7ah@early-bird.think.com> barmar@think.com writes:
|> 
|>    Thus, both of them have problems when the resources are near their limits.
|>    The TCP/IP people decided that signal quality could be sacrificed, while
|>    the phone company decided that connection completion could be sacrificed.
|>    But in both cases, the user is inconvenienced.
|> 
|> I think that's an astute observation.  That seems to be a pervading telco
|> assumption -- if it's not perfect it's not worth doing.

Look at it another way:  they want to give the customer hard numbers on what the
capacity of the system is and what the error rates are.  Why?  Because they sign
contracts with financial penalties for not making those numbers.

 
|>    Just as TCP/IP doesn't currently have a way for the user to request a high
|>    fidelity voice connection (yes, there are header fields for it, but they
|>    don't usually do anything useful in current nets),
|> 
|> Yes, you can't request a high fidelity connection, but you *can*
|> reject a low fidelity connection.  You just can't ask to have it
|> automatically restored when the fidelity goes back up again.

One problem with this:  the fidelity at connection establishment time says
nothing about fidelity some time period later.  If the entire network were voice
connections, this probably works quite well but you throw in ad hoc data traffic
and you can have trouble.  If I can't throw in more capacity quickly, how do I
reduce the misery level?  In a circuit switch or bandwidth reservation
environment, if I DO have to wait around for a connection, at least I don't
typically have the added aggravation of having the connection interfered with
once I make it.

I agree that if a few people use the packetized voice stuff as is, that by and
large they will get by unmolested.  But would I be willing to support an entire
corporate internet in this fashion?  I just don't know if it scales well.

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000543][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 17:02:37 GMT
From:      sfoo@hk.super.net (Mr. Samuel Foo)
To:        comp.protocols.tcp-ip
Subject:   Netbios on TCP/IP

If I use the PC/TCP NetBIOS emulator to run NetBIOS applications, do I need 
a server (Unix) that also implements NetBIOS (for name registration) ? 

Anybody has experience configurating these setup ?

Thanks
Samuel

-----------[000544][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 17:53:31 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: Local name resolution backed up by remote server?

Seton Droppers (droppers@droppers.pbs.org) wrote:

: I thought I knew what I was doing, but then again...
 
: We are arunning several systems and run named on two of them, one as a primary
: name server and one as a secondary name server.  We need to have definitions
: in /etc/resolv.conf.  I have a question about how to set up the resolv.conf
: file for the systems that are our primary and secondary name servers:

I have a feeling that the resolv library does not look at /etc/resolv.conf unless
it cannot find a local bind server.

-----------[000545][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 17:54:39 GMT
From:      wrk@ab.com (Wm. R. King)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)

Does anyone know  if there is a patch kit available for Solaris 1 (4.1.3) to support
IP multicasting?

Bill King
wrk@icd.ab.com


-----------[000546][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 18:38:14 GMT
From:      system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: Local name resolution backed up by remote server?

In article <CKAv18.KLJ@aston.ac.uk> evansmp@mb48026.aston.ac.uk (Mark Evans) writes:
>I have a feeling that the resolv library does not look at /etc/resolv.conf unless
>it cannot find a local bind server.

It definitely looks at /etc/resolv.conf all the time; we were running
a local named that was not working and I could make mail work properly
by just directing /etc/resolv.conf to point to a non-HP-UX named.
-- 
Some days you're the bird,                         |  Mike Peterson, SysAdmin
 other days you're the statue.                     |  U/Toronto Chemistry
E-mail: system@alchemy.chem.utoronto.ca  Tel: (416)978-7094  Fax: (416)978-8775

-----------[000547][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 18:46:18 GMT
From:      system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: Local name resolution backed up by remote server?

In article <2i3vq8$8dc@droppers.pbs.org> droppers@droppers.pbs.org (Seton Droppers) writes:
>Our original thought was to set up resolv.conf on those two systems so that
>the first entry pointed to the localhost and the second entry pointed to
>the other name server, as follows:
>
>bettylou (Primary)		barkley (Secondary)
>149.48.4.72			149.48.4.71
>-----------------------------	---------------------------------
>domain pbs.org			domain pbs.org
>nameserver 127.0.0.1		nameserver 127.0.0.1
>nameserver 149.48.4.71		nameserver 149.48.4.72
>nameserver "outside"		nameserver "outside"
>
>We thought this would direct queries to the nameserver on the local
>machine, unless that named daemon failed, then it would look
>elsewhere.  It has been mentioned that this is not really a good thing.
>
>Since we are not experts in this I was wondering if anyone else had some
>thoughts on this?

I'm not an expert at any of this either, but your setup is exactly what
we have been doing for a long time, and were recommended to do by our
central network people.  The only problem with this is actually getting
bettylou and barkley to boot successfully if they are HP systems also
running NFS (exportfs specifically) - you need to start syslogd and
named in /etc/netlinkrc before running /etc/netnfsrc, not after, and
avoid restarting syslogd in /etc/rc.

I presume all your other systems have:

domain pbs.org
nameserver 149.48.4.72
nameserver 149.48.4.71
nameserver "outside"

That's what we have done for all our Unix/PCs/MACs.
-- 
Some days you're the bird,                         |  Mike Peterson, SysAdmin
 other days you're the statue.                     |  U/Toronto Chemistry
E-mail: system@alchemy.chem.utoronto.ca  Tel: (416)978-7094  Fax: (416)978-8775

-----------[000548][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1994 09:17:49 -0800
From:      akriger@halcyon.com (Andrew G. Kriger)
To:        comp.protocols.tcp-ip
Subject:   Programmer Question


howdy,
	i'm a novice programmer who's trying to understand how to write
applications which can be used over the internet (i assume by the tcp/ip
protocols).
	for example, a program which will send a word to another user -
sendword <word> <user@address>.  this is a simple app idea from which i am
trying to draw the concepts involved in greater apps (e.g. mailers, gopher,
talk, etc.).
	however, i have not been able to find any info which would help me
learn how to write such programs.  if anyone out there can explain any of this
to me, point me in the right direction, or suggest sources to which i should
turn, please email.

thanks

-- 
Andrew Kriger		 There exists no separation between gods and men;
akriger@halcyon.com	 one blends softly casual into the other. 
							 -- Frank Herbert

-----------[000549][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 21:22:23 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple subnets on 1 physical wire

In article <94025.193156RHUNTER@ESOC.BITNET> Ray Hunter <RHUNTER@ESOC.BITNET> writes:
>I'm aware that it is common practice to allow multiple subnets
>on a physical wire in order to maximise address space efficiency.
>
>Now the question is:
>
>is it mandatory for a host to support this when it is running
>a full subnet mask (i.e. not using proxy-arp)
>
>more specifically, does anyone know if IBMs channel attach FDDI
>interface comply with this?
>
>10 browny points for the first person who can quote me
>chapter & verse of the relevant RFC.
>
>(-: I;ve tried to RTFM but I couldn't find it ;-)

This is generally more a question for a router than a host.  Normally,
hosts only have a single IP address and are only logically connected to
the subnet that their (sub)net mask specifies.  Communication to other
(sub)nets assumes the aid of a router, even if other subnets exist on
the same wire.  If a host has multiple IP addresses configured for it,
it is by definition a "multihomed" host.  Being multihomed is not a
requirement for a host.  Now many hosts (especially BSD Unix derived)
can be configured to route directly to other subnets on the same wire
even when they don't have an address on that subnet.  In this case, they
are essentially specifying themselves (their local interface) as the
router.  But this behavior (as far as I know) is not required of a host.

Your best bet is careful reading of RFC1122.

Art


-----------[000550][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 21:44:41 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)

In article <1994Jan27.175439.29382@icd.ab.com> wrk@icd.ab.com writes:
> Does anyone know if there is a patch kit available for Solaris 1 (4.1.3)
> to support IP multicasting?

gregorio.stanford.edu in the directory vmtp-ip.  Both source code mods
and object files for those without sources.

	Rich Stevens

-----------[000551][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1994 21:54:19 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: When does a TCP connection break ?

In article <1994Jan25.122053.24067@aar.alcatel-alsthom.fr> simatic@aar.alcatel-alsthom.fr (Michel Simatic DOM) writes:
>I am using a TCP connection (on Sun Sparc stations running SunOS 4.1
>connected by an Ethernet) to detect when a distant process dies :
>if the connection breaks, I assume that the distant process has died 
>(or the network has broken).
>
>I am wondering if this approach is valid. In particular, are
>there cases where the connection breaks and the distant process
>is actually still there (and so is the network) ? 

Assuming the process doesn't close the socket for some other reason, the
connection should stay up as long as the network is working and the process
is alive.  A network failure normally won't even break the connection,
unless it lasts a long time (a couple of hours) and you have keepalives
enabled.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

-----------[000552][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 1994 22:00:53 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)

In article <1994Jan27.175439.29382@icd.ab.com> wrk@icd.ab.com writes:
>Does anyone know  if there is a patch kit available for Solaris 1 (4.1.3) 
>to support IP multicasting?

gregorio.stanford.edu has patches for a number of workstation
operating systems in the "vmtp-ip" directory.  These aren't
vendor-supplied and are NOT for kernel novices.  It is easy to break
your kernel badly if you don't know what you are doing.  These aren't
supported by anyone as far as I know.




-----------[000553][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1994 00:31:14 GMT
From:      rmacklem@uoguelph.ca (Richard A Macklem)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: Why slower? NFS over slow links compared with rcp, ftp, mail

: A I remember it, most cases of packet loss in WANs are due to congestion
: in the routers.  If this is the case for your lines (your mileage may
: vary), than UDP is a big loss and TCP is a big win, assuming slow start.
: Dave Clark gives an extremely good seminar at Interop on protocol
: performance; I think this issue was discussed in some depth.

It is worth noting that it is possible to do some rather crude congestion
avoidance when running Sun RPC over UDP transport. See:

Bill Nowicki, Transport Issues in the Network File System, In "Computer
Communication Review", pg. 16-20, March 1989.

I have also implemented some stuff that went out on the 4.4 tape and there
is a little on how well it seemed to work in:

Lessons Learned Tuning the 4.3BSD Reno Implementation of the NFS Protocol,
In "Proc. of the Winter 1991 USENIX Conference", pg. 53-64, Dallas, TX,
January 1991.

All in all, it functions moderately well (although probably not as well as
a good TCP implementation). I am not sure, but I believe that some recent
versions of SunOS and/or Solaris has this implemented in it. Also, OSF/1
has some variant of this. (Tom, are you out there and can you say more on
this?)

Anyhow, have fun with it, rick


-----------[000554][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 94 02:08:19 GMT
From:      jimbo@oingo.umn.edu
To:        comp.protocols.tcp-ip
Subject:   Re: tcp from PC to UNIX

In article <2i207s$hcd@fido.asd.sgi.com> wvr@chestnut.asd.sgi.com (Walter Van  
Riel) writes:
> >>anyone know the site where I can get MSDOS/Windows TCP software to
> >>connect my PC to a UNIX machine so I can share the network printers
> >>and other such stuff?
> ---
> Check into into Chameleon/NFS - it allows you mount Unix file systems and
> supports tcp/ip - I used it, and it worked fairly well.  It is provided
> by Netmanage (I think the company is located in the San Francisco Bay 
> Area).  Also, a package called PC-X View provides X Windows to run on 
> your PC (Windows) and required Chameleon NFS.

	Thanks Walter, but what I'm looking for is the FTP site. I can't
afford a professional package, so am looking for a free version. If
anyone knows, please let me know.
Thanks,
---
--------------------------------------------------------------------
	James P. Klett			klett@sunrayce.solar.umn.edu
					jimbo@oingo.umn.edu   (SLIP)
--------------------------------------------------------------------
	Slip Slipping' away...		NeXT Mail Preferred
--------------------------------------------------------------------

-----------[000555][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 03:41:28 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP questions

In article <2i99gj$9j8@olivaw.apanix.apana.org.au> hart@apanix.apana.org.au (Leigh Hart) writes:
>mksho@uno.edu writes:
>
>>Well, I read all the FAQ's I could find, and they were not really very
>>useful.  Here is my question:
 
>>At my school, 19200 bps serial connections to a terminal server are available
>>(no SLIP).  There are many unix machines one can connect to.  Is it possible
>>to have one of these machines function as a SLIP server for connections
>>from the terminal server?  I know I will need administrative help for this
>>(groan..)  I was talking to some administrative, bureacratic, non-computer
>>type person in charge of computing services (don't you hate them?) and 
>>he said 'costs of setting up SLIP would be prohibitive' and from what I
>>know, on a small scale at least, he is full of sh*t.  
>
>In short, no you cannot use a host on the other side of a terminal server
>as a SLIP host.  The network pty's just don't support SLIP line discipline.
>
>Your best bet lies with hoping that your admins can turn on SLIP on
>your terminal server, but I have to admit, this is not really a
>secure thing to do in a school environment.  It's as bad as allowing
>any student to plug into the ethernet and go for it.
>
>>Would PPP be a better idea from a security standpoint?  Also I believe that
>>these connections are non-error corrected, non-compressed.
>
>as far as I know ppp isn't any more secure than slip, but I don't know that
>much about it so I could be wrong.  The error correction is handled by
>the TCP/IP protocol.  A 14.4k modem can also be useful to prevent 
>full retransmission of packets by enabling error correction on the modems.
>
>Compression is also an issue of the modem, if your server doesn't support 
>CSLIP (compressed SLIP) then it's definately all up to the modem.
>
>Cheers
>
>Leigh
>-- 
>                                 Leigh Hart
>                               C/- PO Box 758
>                          North Adelaide  SA  5006
> hart@eppie.apana.org.au  hart@apanix.apana.org.au  hart@cleese.apana.org.au

	Actually it can be done. The far end of I slip link that we were
	using was set up exactly like what was requested.

	It really depends on the OS and pty implementation.

	It is achievable under SunOS 4.1.X.

	Mark.

-----------[000556][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1994 06:16:13 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp from PC to UNIX

jimbo@oingo.umn.edu wrote:
: > Area).  Also, a package called PC-X View provides X Windows to run on 
: > your PC (Windows) and required Chameleon NFS.
 
: 	Thanks Walter, but what I'm looking for is the FTP site. I can't
: afford a professional package, so am looking for a free version. If
: anyone knows, please let me know.

See the newsgroup 'alt.winsock' for a general set of tools - there
are various freely redistributable packages out there, including
the very good 'Trumpet' software, which should do most of what you
need (or at least get you well on your way).

--Ed

-----------[000557][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 06:51:36 GMT
From:      aruna@iitb.ernet.in (Aruna T. )
To:        comp.protocols.tcp-ip
Subject:   Checksum problem .....

Hi, 

I have lifted the algorithm for calculating the checksum from
the  book mentioned below. Someone told me it requires a
patch. Could someone let me know if this algorithm is correct
or if it really requires a patch. If so could u let me know where
to add the patch too..

Thanks

Aruna

/* Book : Unix Network programming  - W.Richard Stevens , page 454-455 */

      /* Check sum routine for Internet Protocol family headers  */

int
in_cksum (ptr,nbytes)
register u_short *ptr;
register int nbytes;
 {
   register long sum;
   u_short oddbyte;
   register u_short answer;
	
	sum = o;
	while (nbytes > 1)
        { 
          sum += *ptr++;
 	nbytes -= 2;
	}
if (nbytes == 1)

{ 
 oddbyte = 0;
 *((u_char *) &oddbyte ) = *(u_char *)ptr;
  sum += oddbyte;
}

sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16)
answer = ~sum;

return(answer);

}


-----------[000558][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1994 07:41:43 +0100
From:      janss002@telecom.ptt.nl (Richard Jansen)
To:        comp.os.msdos.mail-news,comp.protocols.tcp-ip,comp.protocol.tcp-ip.ibmpc,alt.winsock
Subject:   WinTrumpet NNTP problems....

Hi,

can anybody give any pointers to solving the following problem:

I have a copy of the Trumpet WINSOCK dll and WinTrumpet. I have been trying of and on
to install and configure everything, but I couldn't get WinTrumpet to work.

The first problem is that the "TCP manager" application with Trumpet Winsock keeps
saying: "Cannot load TCP". Seems to me that this is to be regarded as an error message.

The other day I added the -disable_nw parameter to the WinTrumpet command line, and...
it started scanning news groups. I figured that changing that parameter was the trick to get
WinTrumpet to work on my LAN workplace (NOVELL).

But apart from that single moment, now I can't get WinTrumpet started again. When trying to
connect to my NNTP-server (of which it can find the IP address, based on its name) it returns
with the eror message: Cannot open NNTP.

Does anybody hava a clue as to what I can do to solve the problem???

Tanx,
Richie
R.H.P.Janssen@telecom.ptt.nl


-----------[000559][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 94 15:43:03 CST
From:      cmkd345@utxvms.cc.utexas.edu
To:        comp.protocols.tcp-ip
Subject:   prob w/SE's NCSA on sys7 from sys6

Netters:

	I am having a difficult time with getting NCSA telnet to run on a mac
SE running system 7.01.  Currently it runs Telnet/byu 2.5 without any problem
(when running with system 6.08). ( We now would like to use the SE as a server
and so we need to run system 7.)  The system consists of:an SE w/an ethernet
card, an internal HD (containing system 6.08) and a SyQuest drive running
system 6.08 (now).  We have set up this SyQuest drive as the boot disk are able
to boot system 7, but whenever we try to use NCSA, we get these errors:
Error opening TCP drivers, possibly no dynamic addressing
and
Could not initialize hardware level network driver.

	We would appreciate any help/suggestions you could provide.

	Please E-mail me directly.  I will summarize on the net if there is
interest.

	Thanks in advance.

John


-----------[000560][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 94 16:12:52 CST
From:      cmkd345@utxvms.cc.utexas.edu
To:        comp.protocols.tcp-ip
Subject:   test test test

test


-----------[000561][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 16:21:29
From:      ace@ics.forth.gr (Andreas C. Enotiadis)
To:        comp.protocols.tcp-ip
Subject:   Re: WOW!! Aint that cool

In article <CK61Ay.rv@news2.cis.umn.edu> jimbo@oingo.umn.edu writes:
>Newsgroups: comp.protocols.tcp-ip
>Path: news.forth.gr!EU.net!howland.reston.ans.net!darwin.sura.net!news-feed-1.peachnet.edu!umn.edu!news
>From: jimbo@oingo.umn.edu
>Subject: WOW!! Aint that cool
>Message-ID: <CK61Ay.rv@news2.cis.umn.edu>
>Sender: news@news2.cis.umn.edu (Usenet News Administration)
>Nntp-Posting-Host: dialup-2-157.gw.umn.edu
>Reply-To: klett@sunrayce.solar.umn.edu
>Organization: University of Minnesota, Twin Cities
>Date: Tue, 25 Jan 1994 03:13:37 GMT
>Lines: 12


>anyone know the site where I can get MSDOS/Windows TCP software to
>connect my PC to a UNIX machine so I can share the network printers
>and other such stuff? Mount NFS?

Well, up to TCP-IP for windows and mounting / sharing printers you can (and 
should) use Peter Tattam's Trumpet winsock package available in most Windows 
sites (I get mine from ftp.psychol.utas.edu.au).
As for printers WINLPR and WINLPD (available at sunsite) will do most of what 
you should need.
NFS in PD may be trouble. I've seen an impementation over WATTCP but it was a 
major hack! I'm working on a port at the moment for winsock but it'll take ma 
a long time yet...
Regards
Andreas
--------------------------------------------------------------------------
Andreas C. Enotiadis
Internetwork Ltd
"Just screwing around - for a living"
ace@ics.forth.gr
ace@iesl.forth.gr
ace@praxis.forth.gr
Snail-Mail : 1 Louki Akrita Str, 15237 Athens, Greece
--------------------------------------------------------------------------

-----------[000562][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 16:51:40
From:      ace@ics.forth.gr (Andreas C. Enotiadis)
To:        comp.protocols.tcp-ip
Subject:   Latest Mac KA9Q?

Guys,
Can anyone point me to an ftp site that has the latest version of Phil Karn's 
KA9Q TCP for the Mac. The version I have dates 1989 or something
Thanks in advance
Andreas
--------------------------------------------------------------------------
Andreas C. Enotiadis
Internetwork Ltd
"Just screwing around - for a living"
ace@ics.forth.gr
ace@iesl.forth.gr
ace@praxis.forth.gr
Snail-Mail : 1 Louki Akrita Str, 15237 Athens, Greece
--------------------------------------------------------------------------

-----------[000563][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 13:09:14 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

In article <1477@netxcom.netx.com> pbrans@netxcom.netx.com (Pat Brans) writes:
>From: pbrans@netxcom.netx.com (Pat Brans)
>Subject: Re: death to GOSIP?
>Date: 27 Jan 94 14:48:41 GMT
 
>In article <MS-C.759116600.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>>The January 17, 1994 Network World has an article that states that the Federal
>>Internetworking Requirements Panel has recommended that GOSIP be scrapped
>>immediately.  It also stated the painfully obvious; that many agencies have
>>bought software that is ``GOSIP compliant'' but never actually used it, using
>>TCP/IP software instead.
>>
>>I for one would not shed any tears at the death of GOSIP.  Are there any
>>perspectives on how far this will go?  Is this perhaps one more nail in the
>>coffin of OSI?  Am I engaging in wistful thinking?
 
>I didn't read the document the panel put out, but I spoke with someone who
>did.  My understanding was that the panel recommends that TCP/IP be *part* 
>of GOSIP.  In other words, they're saying that you can use TCP/IP and still
>comply with GOSIP.  
 
>This really doesn't say anything about the upper layer OSI protocols.  They
>should all be able to run with TCP as a transport layer, providing a 
>connection-oriented transport service like X.25 does.  


Do I detect a sense that OSI, having failed as a transport layer, is now 
trying to fail as a set of application layers ;-)

Regards.
 
Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000564][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 13:11:15 GMT
From:      a722756@pan.mc.ti.com (W. Donald Rolph III)
To:        comp.sys.hp.hpux,comp.protocols.tcp-ip
Subject:   Re: Local name resolution backed up by remote server?

In article <2i3vq8$8dc@droppers.pbs.org> droppers@droppers.pbs.org (Seton Droppers) writes:
>From: droppers@droppers.pbs.org (Seton Droppers)
>Subject: Local name resolution backed up by remote server?
>Date: 25 Jan 1994 15:35:20 -0500


>I thought I knew what I was doing, but then again...
 
>We are arunning several systems and run named on two of them, one as a primary
>name server and one as a secondary name server.  We need to have definitions
>in /etc/resolv.conf.  I have a question about how to set up the resolv.conf
>file for the systems that are our primary and secondary name servers:
 
>Our original thought was to set up resolv.conf on those two systems so that
>the first entry pointed to the localhost and the second entry pointed to
>the other name server, as follows:
 
>bettylou (Primary)              barkley (Secondary)
>149.48.4.72                     149.48.4.71
>-----------------------------   ---------------------------------
>domain pbs.org                  domain pbs.org
>nameserver 127.0.0.1            nameserver 127.0.0.1
>nameserver 149.48.4.71          nameserver 149.48.4.72
>nameserver "outside"            nameserver "outside"
 
>We thought this would direct queries to the nameserver on the local
>machine, unless that named daemon failed, then it would look
>elsewhere.  It has been mentioned that this is not really a good thing.
 
>Since we are not experts in this I was wondering if anyone else had some
>thoughts on this?
>-- 
>Seton Droppers -- "Anything that I say is my opinion and not my employer's."
>Systems Manager, E-Mail Postmaster
>Public Broadcasting Service, 1320 Braddock Place, Alexandria VA 22314-1698
>E-Mail: Droppers@pbs.org   Voice: 703-739-5089   FAX: 703-739-0775


This is approximately how we do it - it seems to work for us, although if your 
local machine is down (127.0.0.1) what need will there be to access the remote 
machine!!

Regards.
 
Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263

-----------[000565][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 13:17:26 GMT
From:      hans@lth-ark3.ark3.lth.se (Hans Rosenlund)
To:        comp.protocols.tcp-ip
Subject:   Winsock

Where can I find a good introduction to the Winsock concept?

-----------[000566][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 13:40:43 GMT
From:      asw2s@uvacs.cs.Virginia.EDU (Alex S. Waterman)
To:        comp.protocols.tcp-ip
Subject:   SunOS support for TCP with Large Windows?

Does anyone out there know if there exists modifications to the SunOS
(non Solaris) kernel to increase the TCP window size above 51K?  I
have heard there is an object-only version available, where can this
be picked up?  

 Thanks in advance,
    - Alex Waterman


-----------[000567][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 94 14:32:00 GMT
From:      root@idca.tds.philips.nl (0000-Admin0000)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   How do I set up a system with two ip address on one connection

I have a machine using one ethernet connection.
On this same ethernet there are other machines using a different domain.

How do I configure my machine in such a way that I can connect to the other
machines in the other domain.
I have tried to use the alias option of ifconfig but this is probably ment for
different ip addresses in the same domain.

Could you please E-mail your response as a am no regular reader of this
newsgroup.

-----------[000568][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Jan 1994 15:23:00 GMT
From:      west@mgmt3.ncsl.nist.gov (Jim West)
To:        comp.protocols.tcp-ip
Subject:   FIRP Report (Was Re: death to GOSIP?)

In article <1477@netxcom.netx.com> pbrans@netxcom.netx.com (Pat Brans) writes:
>In article <MS-C.759116600.1103527590.mrc@Tomobiki-Cho.CAC.Washington.EDU> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>>The January 17, 1994 Network World has an article that states that the Federal
>>Internetworking Requirements Panel has recommended that GOSIP be scrapped
>>immediately.  It also stated the painfully obvious; that many agencies have
>>bought software that is ``GOSIP compliant'' but never actually used it, using
>>TCP/IP software instead.
>>
>>I for one would not shed any tears at the death of GOSIP.  Are there any
>>perspectives on how far this will go?  Is this perhaps one more nail in the
>>coffin of OSI?  Am I engaging in wistful thinking?
>
>I didn't read the document the panel put out, but I spoke with someone who
>did.  My understanding was that the panel recommends that TCP/IP be *part* 
>of GOSIP.  In other words, they're saying that you can use TCP/IP and still
>comply with GOSIP.  
>

After reading the FIRP report I'm not sure what it will mean to "comply with GOSIP"
when the panels recomendations are implemented.

I have included an ASCII version of the FIRP report (it's possible to read, but the
PostScript version looks nicer).  This document is available via anonymous ftp at:

osi.ncsl.nist.gov: /pub/firp/report.*

It is also supplied by a mail server.  Send mail to "mail_server@osi" with the message
"help" and that will get you started.  (The queue is processed on the quarter hour).

Jim

---------------------<  Cut Here for FIRP Report >----------------------------------------



  











Draft Report of the Federal

Internetworking Requirements Panel













Prepared for the National Institute 

of Standards and Technology



14 January 1994 TABLE OF CONTENTS

SECTION                                            Page

Preface                                             iii

Executive Summary                                    iv

1.0     Introduction                                  1

    1.1 GOSIP                                         2
    1.2 IPS                                           2
    1.3 Background                                    2
    1.4 Current Situation                             4
    1.5 Summary                                       5
    1.6 Panel Process and Report                      6

2.0 Requirements                                      7

    2.1 Functional Modes                              7
    2.2 Characteristics                               8
    2.3 Affinity Groups                               9
    2.4 Leading Edge and Core Services               10
    2.5 Vision of Federal Internetworking            11
    2.6 Conclusions                                  12

3.0     International Interoperability and Trade     13

    3.1 Formal International Standards               13
    3.2 International Public Infrastructure          13
    3.3 Multinational Commercial Products            14
    3.4 International Obligations                    15
    3.5 International Trade and National Competitiveness 15
    3.6 Conclusions                                  16

4.0     Standards Process                            17

    4.1 Goals of Standards                           17
    4.2 Development and Use of Standards             17
    4.3 The Specific Question of IETF Standards      19
    4.4 Federal Internetworking Standards Selection  20
    4.5 Testing                                      21
    4.6 Conclusions                                  22

5.0     Technical Issues                             24

    5.1 Functional Comparison of IPS and OSI         24
    5.2 Security                                     26
    5.3 Technical Sufficiency                        27
    5.4 Technology Trends                            28
    5.5 Technology Resourcing                        28
    5.6 Technical Infrastructure                     29
    5.7 Conclusions                                  29


SECTION                                            Page

6.0     Economic Considerations                      31

    6.1 Market Leader                                31
    6.2 Native Protocols                             31
    6.3 Product Development                          32
    6.4 Cost                                         32
    6.5 Summary                                      33
    6.6 Conclusions                                  33

7.0     Recommendations                              34

List of References                                   36

Appendix:  Charter for Panel on Federal Internetworking
Requirements                                         37

Glossary                                             40
 PREFACE


The Federal Internetworking Requirements Panel (FIRP) was
established by the National Institute of Standards and
Technology (NIST) to reassess federal requirements for open
systems networks and to recommend policy on the Government's
use of networking standards.  The Panel was created at the
request of the Office of Management and Budget in
collaboration with the Federal Networking Council and the
Federal Information Resources Management Policy Council. 
The Panel's membership and charter is contained in an
appendix to this report.

Early in its deliberations, the Panel determined that the
problems with the current situation were widely recognized,
and that the most constructive strategy was to develop a
revised approach to achieving Federal internetworking
objectives as a basis for discussion.  This report is
provided as a draft to stimulate discussion in the Federal
Government, Government services users, Government systems
suppliers, and the worldwide internetworking community.  The
Panel is asking for public comment to be provided,
preferably in electronic form, but paper and facsimile will
also be accepted.  A 30-day period is formally provided for
development and receipt of comments.  That period closes on
February 18, 1994.

Following the close of the public comment period, the Panel
will reconvene to consider the comments.  If it is clear
within the Panel, on the basis of the comments received, as
to the direction that Federal internetworking policy,
process, and infrastructure should take, the Panel will
recommend those actions to NIST and OMB following the public
comment period.  However, if some issues deserve more
extended public debate, that debate will be entertained
before making the necessary decisions for recommendation.

Comments should be limited to five pages and sent by
electronic mail to:
 
firp-comments@osi.ncsl.nist.gov 

or to:    Chief, Systems and Network Architecture Division
     Attn: Draft of FIRP Report
     National Institute of Standards and Technology
     Technology Building, Room B217
     Gaithersburg, MD 20899

FAX: (301) 590-0932.
 EXECUTIVE SUMMARY


The Federal Internetworking Requirements Panel (FIRP) was
established by the National Institute of Standards and
Technology (NIST) to reassess Federal requirements for open
systems networks and to recommend policy on the Government's
use of networking standards.  The Panel was chartered to
recommend actions which the Federal Government can take to
address the short- and long-term issues of interworking and
convergence of networking protocols - particularly the
Internet Protocol Suite (IPS) and Open Systems
Interconnection (OSI) protocol suite and, when appropriate,
proprietary protocols.  The Panel was created at the request
of the Office of Management and Budget in collaboration with
the Federal Networking Council and the Federal Information
Resources Management Policy Council.  The Panel's membership
and charter is contained in an appendix to this report.

Background

To meet requirements for data internetworking, the Federal
Government in 1988 adopted Federal Information Processing
Standard (FIPS) 146, Government Open Systems Interconnection
Profile (GOSIP).  The objective of GOSIP is to achieve
interconnection and interoperability of computers and
systems that are acquired from different manufacturers in an
open systems environment.  Beginning in 1990, GOSIP has been
required by Federal Government agencies when acquiring
computer networking products and services and communications
systems or services that provide equivalent functionality to
the protocols defined in GOSIP.  Standards are added to
GOSIP as requirements grow and products become available
based on new  standards.  The current GOSIP Version 2 (FIPS
146-1) became effective in October 1992.  The GOSIP
standards were expected to displace the  IPS and proprietary
protocols because they were a result of the  international
standards process and were expected to be implemented 
worldwide.

The Problem

In practice, most GOSIP products have been much slower in
coming to market than expected and have not been widely
deployed to date, while IPS standards have become commodity
products that are widely used in LANs and private networks. 
More importantly, a substantial infrastructure, the
worldwide Internet, has continued to develop which supports
the IPS standards, while very little comparable
infrastructure has been developed for GOSIP.  Although there
are finally a significant number of OSI products available,
some are proving to be more costly and less integrated than
equivalent IPS products.  As a result of promoting GOSIP
through procurement mandate, some agencies have acquired
GOSIP-compliant hardware and software that is often not used
or installed.  In the meantime, agencies have continued to
use proprietary solutions or have moved to adopt portions of
the IPS.

Although the growth of IPS relative to the GOSIP protocols
was the initial motivation for this policy review, other
factors may be equally significant.  These factors include:
the continuing use of proprietary local area networks, the
widespread deployment of proprietary electronic mail
systems, the transition to client-server data processing
architectures, and the continued dominance of proprietary
communications architectures for mainframe based transaction
processing.

In light of this reality, the Panel determined that it was
necessary to review the entire strategy of meeting Federal
Government internetworking requirements, rather than focus
on the single issue of IPS versus GOSIP protocols.  It must
be emphasized that, in considering requirements, the Panel
did not focus solely on data internetworking, since the
trend is for data to be one component of multimedia
information that may include voice, video, and image
components.  What is required is an effort to both take
advantage of the capabilities now available and rapidly move
developing capabilities into operational use.  Many of the
problems described above stem from too much faith that
government-wide procurement standards could achieve the goal
of federal internetworking without a clear concern for
mission objectives or cost realism.  

Conclusions

The Panel believes that the federal internetworking
standards process should focus on providing leadership to
elucidate and then attain a common vision of how the Federal
Government should be interconnected within itself and with
the public.  Then agencies should be held accountable for
meeting their mission objectives in as compatible a way as
practicable with that vision.  Agencies should be given
guidance in achieving interoperablity goals via statements
of preferred direction, but the guidance should not be tied
to specific low-level technologies that are rapidly
evolving.

The Panel concluded that no single protocol suite meets the
full range of government requirements for data
internetworking.  Both the IPS and OSI have strengths and
weaknesses, as do proprietary protocols.  While a single
standard would be preferable, the reality is that there are
multiple solutions in networking as in other areas of
information technology.  Each community within the
Government should pursue the solution to meeting their
mission requirements as a primary goal without a specific
technical solution being imposed on them.  In addition, they
will need to consider interoperability with other agencies
and the public, existing infrastructure, and cost.  These
goals are facilitated by standards, but standards alone are
not sufficient.  The Federal Government needs to be
supported by available products and infrastructure. 
Agencies need a process that provides current guidance to
assist them in deciding how to best meet their requirements,
rather than the specification of technical solutions. 

Recommendations

The vision that the Panel sees for federal internetworking
is that it becomes a seamless component of the National
Information Infrastructure, providing a full range of
integrated communications connectivity among federal
agencies and from federal agencies to the public sector. 
The Panel believes that the following recommendations are
key to attaining this vision.

Recommendation 1.  The role of oversight and integration
across federal agency internetworking activities should be
strengthened within the Office of Management and Budget.

This should include horizontal integration for all
internetworking services from advanced research and
development to leading edge to core/commodity services. 
Particular emphasis should be placed on the areas of
oversight, plans and resourcing, standards, technology, and
policy.  The Panel recommends that an annual report be
published that provides a single integrated internetworking
strategy and evolution on internetworking within the federal
government and with the public.

Recommendation 2.  The roles and responsibilities for
fostering standards and assessing technological change
should be refocused and strengthened by the Department of
Commerce.

This should include expansion of activities across all
internetworking stages from advanced research and
development to leading edge to core/commodity services. 
Particular emphasis should be placed on technology
forecasting, expanded and fully coordinated participation in
other standards forums including consortia, encouraging
convergence towards a single standard, where appropriate,
and more pragmatic testing and interoperability assurance.

Recommendation 3.  The roles and responsibilities for
infrastructure development and operations to support all
internetworking services from advanced research and
development to leading edge to core/commodity services
should be clearly defined and formally assigned through the
Information Infrastructure Task Force.

These roles and responsibilities should include
infrastructure administration such as registration services
and directory maintenance, help desks, and provisions for
and coordination among emergency response activities.

Recommendation 4.  The roles and responsibilities of
affinity groups should be defined, including how they are
created and coordinated by the Government Information
Technology Services working group.  

Because affinity groups are the context within which
interoperability is important, active participation of
affinity groups in the development of infrastructure to
support interoperability is required.  As a first step,
those groups associated with implementing the National
Performance Review recommendations requiring substantial
information technology services should be included in this
structure.

Recommendation 5.  In accordance with OMB Circular A-119,
Revised, October 1993, voluntary standards should be adopted
and used by Federal agencies, and international standards
should be considered in the interests of promoting trade. 
The current GOSIP policy should be  modified by the
Department of Commerce to reflect the wider range of
international voluntary standards for internetworking.

Federal internetworking should be based on the following
hierarchy of standards: first, open international voluntary
standards; second, national voluntary or consortia
standards; and third, proprietary standards with
multinational commercial prevalence.  The Federal Government
should recognize Internet Engineering Task Force (IETF)
standards as open international voluntary standards.  Since
no single protocol suite meets the full range of Government
requirements, the current GOSIP policy, FIPS 146-1, should
be modified to recognize both OSI and IPS protocols
including RFC 1006 and hybrid stacks as acceptable
internetworking standards.  Specific consortia and
proprietary standards may be recognized in exceptional cases
if agreed to by a specific affinity group and clearly in the
Government's interests.  The name of GOSIP should be
modified to reflect the wider range of internetworking
protocols.

The process for identifying profiles to be included in GOSIP
should be modified to include marketplace and infrastructure
factors and the needs of affinity groups.  The applicability
statement in GOSIP should be revised such that agencies
should give first preference to profiles defined in the
revised policy when acquiring internetworking products and
services.  Federal preferred standards profiles should be
identified by NIST, based on the hierarchy of standards,
taking into account technical, marketplace and
infrastructure factors, in consultation with the affinity
groups most affected.  The ultimate aim is to converge the
Government to a single interconnected, interoperable
standards based internetworking environment.  


 1.0  INTRODUCTION


The Panel was chartered to study issues and recommend
actions which the Federal Government can take to address the
short- and long-term issues of interworking and convergence
of networking protocols - particularly the Internet Protocol
Suite (IPS) and Open Systems Interconnection (OSI) protocol
suite and, when appropriate, proprietary protocols.  The
overall Federal objective in this area is to achieve
interoperability -- within agencies, between agencies, and
with outside organizations and the general public.  The goal
of Federal agencies is to use interoperability as an
enabling infrastructure that will help them provide basic,
common, relatively seamless sets of services to their users
and improve the cost-effectiveness and reliability of their
networking activities.

To meet requirements for data internetworking, the Federal
Government began working on the Government Open Systems
Interconnection Profile (GOSIP) in 1986.  GOSIP was to
provide a common set of standards for Federal
interoperability and a process for adding to those
standards, as requirements grew.  The GOSIP standards were
expected to displace the IPS because they were a result of
the international standards process and were expected to be
implemented worldwide.  GOSIP standards had at least the
functionality of their IPS equivalents available at that
time.
     
In practice, most GOSIP standards have not been widely
implemented to date, while the IPS standards have been. 
Probably more importantly, a substantial infrastructure has
continued to develop which supports the IPS standards, while
very little comparable infrastructure has been developed for
GOSIP.  This reality, whatever the reason for it, has caused
a review of the current policy on data internetworking.

Although the growth of the IPS relative to the GOSIP
protocols was the cause of this policy review, other factors
in the development of internetworking may be equally
significant.  These factors include:  the continuing
development of proprietary networking standards,
particularly for local area networks (LANs); the development
and widespread deployment of proprietary electronic mail
systems, using graphical user interfaces on proprietary
LANs; the transition to client-server data processing
architectures; and major increases in the reliability and
speed of both local and long distance digital transmission. 
In addition to these new factors, there is no real evidence
of the imminent replacement of mainframe based transaction
processing using proprietary communications architectures
with anything from either GOSIP or IPS.  

Many organizations within the Government and industry have
evolved over the past twenty years to support a wide variety
of computing capabilities and, correspondingly, networking
services and protocols.  Organizations continue to carry out
their missions using a mixture of mainframe technology (with
its centralized paradigm and terminal to host connections),
minicomputers and workstations (with their peer-to-peer
paradigm and LAN technology), and personal computers (with
their client-server paradigm and proprietary workgroup LAN
operating systems).  Typically, large and medium sized
organizations use all of these technologies.  In addition,
technology investment decision-making has often become
increasingly common at lower and lower levels within
organizations, with departments or groups often making
independent decisions.  These local decisions can be driven
by narrow application requirements or by personal
preference, with internetworking being a secondary
consideration, if that.  

The result has frequently been a inter-mixture of
disconnected or loosely connected capabilities.  Typically,
organizations have attempted to stitch these various
technologies together after the fact, where possible, to
provide connectivity between different groups within the
organization.  The net result is often functionally
disparate islands of technology connected through mechanisms
and gateways that are unreliable, difficult to use, not
understood by the vast majority of end users, and expensive
to maintain.  

1.1  GOSIP

Currently, Federal Information Processing Standard (FIPS)
146-1, the Government Open Systems Interconnection Profile
(GOSIP), defines the official approach to federal
internetworking policy for data communications:  "GOSIP
shall be used by Federal Government agencies when acquiring
computer networking products and services and communications
systems or services that provide equivalent functionality to
the protocols defined in the GOSIP.  The objective of GOSIP
is to achieve interconnection and interoperability of
computers and systems that are acquired from different
manufacturers in an open systems environment" (NIST, 1991).

GOSIP is based on the Open Systems Interconnection (OSI)
protocol suite, which is a joint standardization program of
the International Organization for Standardization (ISO) and
the International Telecommunications Union (ITU).  The ISO
and ITU standards are developed and approved by formal,
widely accepted international processes, either by
developing standards within ISO/ITU technical committees or
by fast-tracking standards developed by other international
and national bodies. The original GOSIP Version 1 became
effective in August 1990.  The current Version 2, which
became mandatory in October 1992, includes more services: 
Virtual Terminal (VT), Integrated Services Digital Network
(ISDN), Office Document Architecture (ODA), and the End
System to Intermediate System (ES-IS) routing protocol. 
GOSIP Version 3, based on the forthcoming Industry-
Government Open Systems Specification (IGOSS) Version 1, has
a relatively complete set of internetworking specifications,
including Directory Services, 1988 Message Handling Systems,
and Intermediate System to Intermediate System (IS-IS)
routing protocol.

1.2  IPS

The IPS is an open protocol suite based on the Internet
Protocol (IP) and Transmission Control Protocol (TCP), which
were developed within the U.S. military-funded research
establishment and have since grown to become the basis of
the worldwide Internet.  Standardization of the IPS is
carried out by the Internet Engineering Task Force (IETF). 
The IETF process puts its emphasis and owes its success to
the policy of "rough consensus and running code," which
means that IETF members develop multiple, interoperable
implementations of draft protocol specifications before they
are declared as full Internet Standards.  The IPS, although
neither required nor precluded by GOSIP, is widely used by
federal agencies.  Today there is significantly more actual
interoperation within and between federal agencies using IPS
than using OSI standards, as well as between Federal
agencies and the public.

1.3 Background

When GOSIP was originally conceived in the mid-1980s, OSI
products were beginning to appear, vendors were developing
(and promising to develop) more products, and Governments
and industries around the world were establishing plans and
programs to adopt the OSI standards as the basis of their
interworking.

IPS products, on the other hand, were limited in the mid-
1980s, and several major vendors of computer and networking
equipment were still in a "wait and see" mode.  The IPS
standardization process was still largely informal.  In
February 1986, the Internet was primarily centered on the
U.S. defense and research community with 328 registered
networks, of which only 16 were non-U.S. (Postel, 1993) 

By 1994, events have largely overtaken policy.  First, OSI
products have turned out to be much slower in coming to
market than expected.  Although there are finally a
significant number of products available, some (such as file
transfer and virtual terminal) are proving to be less
integrated than equivalent IPS products.  In other areas
(such as message handling and directory services), OSI
products have become competitive with alternative offerings. 
A worldwide public carrier X.400 infrastructure has been put
in place over an X.25 infrastructure, providing X.400
reachability between almost all public service providers. 
Although the number of public carrier X.400 users worldwide
is unknown, as an example, Compuserve has approximately
500,000 users.

At the same time, the Internet has matured more rapidly and
to a much greater extent than even its proponents expected. 
The Internet is the system of interconnected computer
networks that share the protocol suite and the name and
address spaces that are specified by the Internet
Architecture Board (IAB) of the Internet Society (Postel,
October 1993; Reynolds, 1992).  As of December 1993, the
Internet has grown into a huge international infrastructure
of over 21,000 connected networks, of which over 9,000 are
non-U.S., supporting an estimated 20 million users worldwide
(Widmeyer, 1993).  Compared with 1986, the Internet now
connects 70 times more networks, with 45 percent of them
non-U.S. as compared with about 5 percent in 1986.  Also,
there is today a significant commercial use of the Internet,
whereas in 1986, commercial use was not permitted.  The
Internet now has a much more formalized standardization
process than in 1986.  Products that comply with IPS
standards have now become commodities that are widely used
in LANs and in private networks, in addition to their use on
the Internet.  At the same time, the Internet has become
capable of supporting multiple protocols, including OSI, in
parallel with IPS.  In fact, the Internet now hosts the
world's largest X.500 directory services pilot.

As the Internet infrastructure has grown up worldwide, its
basis of success has also become more apparent.  The
Internet is not centrally controlled or managed by any
single entity but is composed of a large number of networks
run by a variety of organizations, including governmental,
academic, research, and commercial organizations, ranging
from user organizations to network providers.  These
organizations all cooperate informally to provide the
interconnection service and to provide access for their own
hosts and subnetworks attached to the network.  Most of the
hosts connect to the Internet using widely available
commercial hardware and software, which comply with the IPS
just by having to interoperate day-in and day-out in the
open marketplace, and not because of any required Government
test or mandate.  The need to support this huge
infrastructure and be able to transfer information over it
drives the continuing development of new protocols, which in
turn are deployed on the Internet, causing it to expand even
more, and repeating the cycle as the new technology becomes
widely available in products.  The Internet has truly
reached "critical mass," in the sense that a large and
diverse set of organizations and even individuals must have
Internet connectivity to do their jobs and are critically
dependent on this infrastructure to obtain information.

Finally, with respect  to the U.S. Federal Government and
GOSIP:  some federal agencies, even while acquiring GOSIP-
compliant technology, have played and continue to play a
major role as users and developers of the Internet. 
Although the Government's share of funding for physical
facilities of the Internet is declining dramatically,
Federal Networking Council (FNC) agencies continue to
support some of the vital infrastructural "glue" such as:
administrative support for IETF meetings and the Internet
Architecture Board (IAB), various registration services,
and basic information services including the "Network
Information Center (NIC) of first and last resort."  FNC
agencies also participate actively in the IETF
standardization process, with a substantial number of
active IETF participants being employed by, or supported
by, the Federal Government. Federal agencies, contractors,
and grantees, together, purchase massive amounts of IPS
compliant hardware and software, far more than GOSIP.  This
is even more true in the commercial and private sector.

1.4  Current Situation 

Organizations face many challenges in developing and
implementing an enterprise-wide networking strategy that
achieves economies of scale and provides an evolvable
infrastructure for future applications that will support
multimedia solutions.  In decentralized organizations, it is
often difficult to achieve the necessary level of consensus
within the organization on what this infrastructure should
be, or that the infrastructure should exist at all.  Even
when consensus on technology is reached, there can be
difficulties in developing an appropriate investment
strategy.  Frequently, different groups within an
organization are responsible for developing and operating
the network infrastructure and the applications that use the
network.  Various applications can require different network
protocols.  Furthermore, within a given type of application,
such as e-mail, there can be many different packages running
simultaneously within the network.  The net result of these
many layers of technical and organizational dependencies is
that organizations can experience some degree of deadlock
when they undertake enterprise-wide technology evolution,
leading to the need for freedom in the transition process to
tailor their approach to fit both the existing baseline and
the target architecture.

Several agencies have implemented portions of GOSIP, mostly
in the X.400 electronic mail area, with limited interagency
interoperability.  A lot of effort has been expended, but
the bottom line is that today, even in electronic mail,
interoperability across the Government is still only a goal. 
In limited communities, such as the federal research
community, e-mail interoperability is more widespread and
treated as a utility using IPS.

During an era of declining budgets, there has been
increasing pressure on Information Technology (IT)
investment programs to clearly demonstrate added value and
cost savings when acquiring new services.  GOSIP has been
promoted through procurement mandate, rather than through
emphasis on how agencies can better accomplish their
missions.  This policy  has led some agencies to deviate
from GOSIP or pay it only lip service, acquiring GOSIP-
compliant hardware and software that is often not used or
installed.  Products based on GOSIP versions 1 and 2 do not
contain sufficient functionality.  They are often poorly
integrated since they are not subjected to the day-to-day
rigors of widespread operational deployment.  In the
meantime, agencies have continued to use proprietary
solutions or have moved to adopt portions of the IPS.  By
contrast, because of  competition in the large marketplace,
the IPS and proprietary suites are low cost and well
integrated.  To the extent that they meet mission needs,
they are almost always "pretty simple" and "pretty good."

This current approach on the data networking side of paying
only lip service to GOSIP has sent very mixed messages to
vendors  causing them to question the Government's
intentions on GOSIP.  Together with slow acceptance in the
commercial sector and the overall economic downturn over the
past two years, this caused a number of vendors to slow
their investment in developing some OSI products.  In spite
of this, over the past 12-18 months, a number of the key
services in GOSIP version 3 have become available in the
marketplace, specifically Directory Services, 1988 Message
Handling Systems, and the dynamic Intermediate System to
Intermediate System (IS-IS) routing protocol.  Today 1988
X.400 messaging products are available from many vendors,
several X.500 directory service products are available and
IS-IS is available from virtually all routing vendors.  The
costs for the messaging products are now competitive with
both proprietary and Internet offerings.

The focus on "full stack" GOSIP at a time when the products
were not widely available and deployed in large scale has
undermined the use of just parts of the OSI protocol suite,
even when potentially valuable parts of the OSI protocol
family could be used over existing network and transport
infrastructure.  For example, X.500 Directory Services
running over TCP/IP is not part of GOSIP Version 2, even
though its use is reasonably widespread and could fulfill
the needs for a Government-wide Directory.  

1.5  Summary

The internetworking requirements of Federal agencies arise
from their goal of meeting their mission needs while
furthering overall Government interoperability objectives:
intra-agency, inter-agency, and between Government and
outside organizations.  The challenge faced by the agencies
is how to evolve their current, highly heterogeneous
environments to an interoperable infrastructure that:

   - meets their mission needs (often variable within a
     single organization)
   
   - is affordable over its life cycle (relative to what
     they are now doing, or what is available in the
     marketplace, or what funds are available)
   
   - reliably provides the desired levels of service to all
     users
   
   - can evolve as new technology evolves in a manner that
     is cost effective and nondisruptive for users.

In light of the broadness of this challenge, it is
appropriate to review the entire strategy of meeting Federal
Government internetworking requirements, rather than focus
on the single issue of IPS "versus" GOSIP protocols or on a
data-only requirement/solution set.  What is required is to
come up with a recommended approach for Federal
internetworking that will both take advantage of
internetworking capabilities that are available in the
marketplace today while remaining open to the use of future
capabilities that are currently under development.

Many of the problems described above stem from too much
faith that government-wide procurement standards could
achieve the goal of federal internetworking without a clear
concern for mission objectives or cost realism.  The Panel
believes that the previous  approach to federal
interoperability fails to enlist the vitality and cost-
consciousness that can come only from agencies focusing on
their missions, and that standards-setting from the top
should be aimed not at procurement mandates but at
government-wide interoperability objectives.

The Panel believes that the federal internetworking
standards process should focus on providing leadership to
elucidate and then attain a common vision of how the Federal
Government should be interconnected within itself and with
the public.  Then the agencies should be held accountable
for meeting their mission objectives while furthering the
overall Government-wide interoperability vision.  Agencies
should be given guidance in achieving interoperability goals
via statements of "preferred" direction, but the guidance
should not be tied to specific low-level technologies that
are rapidly evolving.  Agencies should have the freedom to
take advantage of newer technologies and to acquire
commercially available networking hardware and software that
accomplishes their mission objectives, in a way that is
compatible with pursuit of the overall goal of
interoperability within the government and with outside
organizations.

1.6  Panel Process and Report

In its deliberations, the Panel reexamined the federal
policies for information technology acquisition, with a view
aimed at:

   - Refocusing on federal internetworking requirements and
     objectives that led to GOSIP in the first place.
   
   - Fixing the parts of the GOSIP process that are not
     working, in light of the internetworking situation
     worldwide, as it has evolved over the past eight years
     since GOSIP was conceived.
   
   - Providing leadership and guidance towards the primary
     goal of achieving Government-wide interoperability over
     a shared infrastructure, and not on mandatory use or
     acquisition of a specific technology or set of
     products.
   
   - Allowing agencies the freedom to manage their IT
     resources and acquire products which best meet their
     needs, but be held accountable to Government goals of
     interoperability and infrastructure utilization in how
     they conduct their business.
   
The Panel divided its work into the general areas of
Requirements, International Interoperability and Trade,
Standards Process, Technical Issues, and Economic
Considerations.  This report reflects that structure of its
deliberations.

In this report, the Panel points out what it thinks are
better directions for federal internetworking in the areas
of policy, process, and infrastructure, based on the Panel's
perceptions and analyses of worldwide and U. S. federal
internetworking current realities and future trends.  The
Panel now seeks public comment, aimed at helping reach
agreement on leadership actions that should be recommended
for implementation. 2.0  REQUIREMENTS

Federal agencies have a wide range of internetworking
requirements today and will have an even wider range of
requirements in the future, as technology advances and the
recommendations of the National Performance Review (NPR)
(Gore, 1993) begin to be implemented.  These requirements
can be categorized in a number of different ways.  These
include functional modes of communications, such as
conversational, messaging, transaction processing and
information retrieval; characteristics, such as
connectivity, interoperability and security; and communities
of interest or affinity groups, distinguished by geographic
proximity, shared interests or missions, or service
providers and their customers.  In considering requirements,
the Panel did not focus solely on data internetworking,
since the trend is for data to be one component of
multimedia information that may include voice, video, and
image components.  Information should not be available just
one way, but in a whole range of ways, and not just to
Government employees, but to citizens being served by
Government and to industry transacting business with the
Government.  An expanded discussion of federal
internetworking requirements is contained in (GSA, 1994).

2.1  Functional Modes

Functional modes of internetworking are differentiated by a
number of specific technical communications features.  These
features include latency, acceptability of variability in
delay, the number of endpoints for an information stream,
the need for simultaneous availability of endpoints, and the
expected duration of the information exchange.  The
following functional modes are identified.

Conversational.  The conversational mode is characterized by
a multiway (usually two way) unstructured exchange of
information at roughly the pace of normal human
conversation.  Telephone calls are the classic example of
this mode, and represent a high level of development in all
of the characteristics required of a communications mode.
Multimedia multipoint conferencing is the requirement which
will most challenge technology, or constitute the
"technology driver" for this mode of communications.

Messaging.  The messaging mode, also known as store-and-
forward, is characterized by an exchange of information in
which one participant sends information to other
participants with the expectation of some delay larger than
that in a normal conversation in the delivery of the
information.  E-mail is a contemporary example of this mode. 
The technology driver for this mode is multimedia messaging. 
Users would like to be able to leave messages which include
voice, image, data, and video components.

Information Retrieval.  The information retrieval mode is
characterized by a structured request for information from
one party to a designated source of information.  The
classic example of this mode is directory assistance in the
telephone system.  The technology drivers for information
retrieval are multimedia input requests (voice, data, or
graphical user interface) into an up-to-date distributed
information base which can provide multimedia responses.  

Broadcasting.  Broadcasting is characterized by the
widespread dissemination of information without a specific
request by the recipients.  This communication is normally
one-way.  Broadcast radio and television are a classic
example of this mode.  Broadcast has been used when there is
no requirement to guarantee that all possible recipients
have received the information.  The technology driver for
this mode is wideband transmission and cable systems which
permit a wide range of information to be in "flow-by" mode
for users, like the stock prices or weather reports, which
the user's equipment can capture based on a stored profile. 
A variant of broadcast is multicast, where a number of
recipients, but not all recipients, accessible by a
particular communications system are sent information.  

Transactional.  The transactional mode is characterized by a
structured request for either information or action by the
requester, and a response containing the requested
information or confirmation of the action. Examples are
airline reservation systems and electronic funds transfer. 
The key characteristic of transactional mode is the concept
of "indivisible, guaranteed action" that ties together all
the pieces of the transaction into a single logical event. 
Electronic commerce depends on a combination of the
transactional and messaging mode.  In both the government
and industry, transactional mode communications have been
almost entirely supported by dedicated networks running
proprietary protocols.  An example of a technology driver is
multimedia updates to electronic catalogs.

Composite.  The composite mode involves communications
consisting of a mixture of the above modes of communication. 
All modes would permit a range of media (voice, graphics,
data, including highly formatted data such as documents and
spreadsheets, and video) to be employed in the process.  A
single integrated workstation would support the entire
composite mode requirements of the Government employee, and
citizens could use whatever range of capabilities their
personal communications equipment could support.  Calendar
and workflow software are examples which are beginning to be
in widespread use.  Examples of technology drivers are
multimedia conferencing and virtual reality.

2.2  Characteristics

The following characteristics apply to some extent to all
communications modes.

Affordability.  Internetworking is affordable if it can be
provided at acceptable cost.  The cost has to be balanced
against the perceived benefit and convenience.

Connectivity.  A necessary but not sufficient requirement
for internetworking is that the physical communications
media of the internetworked components are "connected."  The
Federal Government also requires connectivity under other
than normal conditions, for example, during emergencies,
disasters, and war.  Extensions beyond commercially provided
services will continue to be needed for these requirements.

Interoperability.  Interoperability is the ability for two
systems to work together across a network.  The degree to
which useful work can be done in the internetworked
environment versus the user's home network environment
determines the degree of interoperability.  

Accountability.  Accountability is the ability to ensure
that communication has taken place and was in the
government's interest.  In the internetworking context, this
means that the responsibility for completion was transferred
and is identifiable, the performance was met, the
communication costs were appropriate and identifiable, and
the use of the communication facility was in the
government's interest.
Cost Allocability.  Once costs have been accounted for, they
must usually be allocated on some basis to the participants
in the communication in accordance with OMB Circular A-130.

Security.  There are security requirements for
confidentiality; system and information integrity; sender
and recipient identification, authentication, and access
control; and sender and recipient non-repudiation.  The
requirements for security contrast with requirements for
accessibility.

Reliability/Availability/Maintainability.  Reliability,
availability, and maintainability (RAM) concerns are caused
by the vagaries of physical systems in a physical world,
such as parts failure.  Data networks for mission critical
purposes tend to be dedicated, with limited interconnection
and built in redundancy as needed, rather than relying on
the redundancy of the underlying telecommunications
networks.

Manageability.  Manageability includes status, fault,
configuration and performance management.  While in many
cases individual networks have excellent management tools
for all three categories, few internetworks do.  While rapid
progress is being made in this area, many of the tools and
techniques remain primitive.  Changes in configuration,
features, and security parameters can still be complex
operations, and self-configuration of components remains
rare.

Useability.  The useability of a system is a measure of how
easily the users of a system can accomplish their work.  The
level of useability has a direct impact on the life cycle
cost of the system and especially on the cost of training. 
Factors which impact the useability of a communications mode
include the human and programming interfaces, directory
support, and administrative support.  

Accessibility.  Accessibility is the ability of all users
with the need and the authorization to communicate to
actually be able to communicate to fill their needs.  These
users may be federal employees who need information to
perform their jobs, citizens who need information about
government services or need to acquire those services,
industry providers of service to the government, businesses
regulated by the government, or businesses requiring
federally generated information for their operations.  A
number of specific NPR recommendations are directly
applicable to accessibility improvements.  These include
implementation of electronic commerce, establishment of
trade and environmental data systems, and intergovernmental
tax filing.

2.3  Affinity Groups

The Panel recognizes that government agencies have common
Information Technology (IT) requirements for sharing
information and would greatly benefit from having access to
a Government Information Infrastructure (GII).  The
government agencies, or functional interest groups therein,
that share information electronically and have common IT
requirements have become known as affinity groups.  The NPR
describes the affinities that exist between related
government agencies.  Over time, as affinities become more
evident, the affinity group member views of interoperability
requirements will quite naturally begin to converge.  A
primary benefit of identifying and fostering such affinity
groups of agencies with similar requirements is that, as the
common requirements of affinity group members begin to
converge, the agencies can then usually come to consensus as
to how to meet the requirements in a common way.  Most
agencies want to pursue the use of commercial standards and
minimize unique implementations within the standards.  With
the affinity groups identified and already working together,
common solutions to internetworking requirements can be
undertaken by all the agencies in the group.  The
alternative scenario is most undesirable, wherein individual
agencies pursue solutions independently, with the risk of
striking off down a slightly different path or a nonstandard
path that eventually leads to a sole-source or dead-end
situation and hence an expensive interoperability "island".

To ensure that affinity group solutions also promote
government-wide interoperability, there is the need for
coordination across affinity groups.  This coordination in
turn will lead naturally to evolving convergence of views
regarding the requirements for the Government Information
Infrastructure (GII)  Because the public needs electronic
access to government agency services, the GII should allow
the public access to government electronic services using
the National Information Infrastructure (NII).  For public
access services, it may be important to provide a basic
level of services inexpensively while a higher level of
services may be available at a higher cost.  

Affinity groups have a shared need or mission that can be
furthered by internetworking of IT among members of the
group, although IT standards and networking are not their
primary focus.  Affinity groups may be defined in various
ways:  by a common data system; by a common clientele; by
the common state agencies that they interact with; or a
common service delivery.  They could be self-defining, or
they could be established by OMB or the FIRMPoC.  In
addition to Federal agencies, affinity groups may possibly
include state governments and the private sector.  

The Federal Networking Council is an example of an affinity
group dealing with advanced networking services for the
research community.  The NPR Accompanying Report, titled
Reengineering Through Information Technology (Office of the
Vice President, 1994), includes seven recommendations for
creating an electronic government based on integrated
service delivery through affinity groups.  The seven areas
are: integrated electronic benefit transfer; integrated
electronic access to government information and services;
national law enforcement/public safety network;
intergovernmental tax filing, reporting, and payments
processing; international trade data system; national
environmental data index; and government-wide electronic
mail.

Because affinity groups are the context within which
interoperability is important, active participation of
affinity groups in the development of infrastructure to
support interoperability is required.  A structure to
coordinate affinity groups is required.  As a first step,
those groups associated with implementing the NPR
recommendations requiring substantial Information Technology
services should be included in this structure.  This task
falls under the responsibility of the Government Information
Technology Services (GITS) working group.

2.4  Leading Edge and Core Services

One consequence of the rapid rate of change of network
technology is that yesterday's experimental system is
today's beta-test and tomorrow's production system.  When
Government requires deployment of leading-edge network
technology, this mandates the specification of technology
well before it is commonly available; i.e., the
specification of an experimental network.

Experimental networks are always risky and usually
expensive.  Hence, industry may be reluctant to deploy such
networks if the risk/benefit is too high.  But if industrial
and Government interests in future networking technology are
aligned, Government can play an important role: by partially
funding such programs - participating at the margin - it can
reduce the financial risk to industrial organizations and
make it attractive to them to participate. From the
Government's standpoint, its investment is highly leveraged
by the degree of industrial participation and a "win-win"
situation obtains in which industrial technology is advanced
more rapidly and, at the same time, Government acquires the
use of a network that is not a victim of instant
obsolescence. 

There is a window that, with time, slides along the
technology axis of networks, in the direction of higher
performance.  At the leading edge of the window are found
the most advanced, highly experimental networking
methodologies, practiced by only a few of the most
technologically aggressive companies and often as industry-
Government-academic partnerships.  Standards tend to be
informal, in flux, and to track the changing technology.  At
the trailing edge of the window is the current state of
commercial off-the-shelf (COTS) network technology,
characterized - at least in the U.S. - by multiple private
commercial suppliers, vigorous competition, and
proliferation of network services offered as commodities, as
competitors seek to differentiate their network offerings to
achieve market share.  Standards, both proprietary, as well
as industry-wide, proliferate but mutate slowly, reflecting
the relative maturity of the technology. 

As a consumer, Government purchases core networking products
competitively, on the open market.  At the same time,
Government is a partner with industry in pressing the
technology forward.  Agencies should distinguish between
core services (e.g., electronic mail, file transfer, fax)
and leading edge services (e.g., bandwidth on demand,
interactive video, multimedia e-mail).  Standards are
important for core services which should be based on
commodity products.  Agencies requiring leading edge
services should be able to acquire the required technology,
but also accept the risks associated with deployment prior
to stable standards and commodity products.

2.5  Vision of Federal Internetworking

The foundation for a vision of federal internetworking is
laid out in The National Information Infrastructure (NII)
Agenda for Action (Information Infrastructure Task Force,
1993) and in the NPR Accompanying Report, Reengineering
Through Information Technology  (Office of the Vice
President, 1994).  The vision of an electronic government
requires computer hardware, software, and telecommunications
equipment to make information flow smoothly across the
nation's information highways.  It will position the
Government as a leader in IT utilization, rather than
lagging behind the commercial sector, as it generally does
now.  It also requires policies, procedures, and standards
to support the development and operations of services that
use the physical technology components. An effective
information infrastructure requires high levels of
interoperation and integration among diverse users. 

The Panel's vision is that the Government Information
Infrastructure (GII) to support internetworking evolves as a
seamless part of the National Information Infrastructure
(NII).  The infrastructure must support mission needs within
an agency, interoperability between agencies, and 
electronic access to the government from the public as well
as from business and industrial partners and contractors. 
The GII should build on the current baseline which includes,
but is not limited to, FTS2000 for basic intercity
telecommunications, and the Internet for the government
research community and its interaction with  researchers and
educators.  The GII, as a portion of the NII, must satisfy
the needs of affinity groups while leveraging commercial
infrastructure.  The Panel envisions the GII as a virtual
internetwork, built on the networking infrastructure
primarily deployed by industry, with components supporting
the specific needs of affinity groups.  The GII will
potentially require both core and leading edge services and
provide access to the public through commercial, on-line
information service providers, generally in the core
services area.

In order to attain this vision, the Panel believes that
there must be increased leadership and integration across
federal agency internetworking activities.  Mandating
acquisition standards is not sufficient.  There must be an
integrated internetworking strategy that takes into account
affinity group needs, standards, infrastructure, marketplace
assessment, technology maturity, and budgetary
considerations.  The Panel recommends that this leadership
should come from OMB, supported by NIST, to include an
annual guidance document for federal internetworking.

The OMB role should include horizontal integration for all
internetworking services from advanced research and
development to leading edge to core/commodity services. 
Particular emphasis should be placed on the areas of
oversight; plans and resourcing; standards; technology; and
policy.  The Panel believes that the annual document is key
to providing a single, integrated internetworking strategy
and evolution both within Government and to the public. 
Specific areas to be addressed in this include: the current
assignment of federal internetworking requirements to
specific networks, i.e., advanced research and development,
leading edge or core/commodity services; transition
strategies; relevant policy (e.g., interface requirements,
acquisition guidance, budgetary guidance, etc.); and a
technology forecast (to include assessments of the current
market for both government and commercial; projections of
commercial vendors' technology evolution strategies;
economic evaluations based on the installed base and the
maturity of given technologies; risk assessments associated
with given technology implementation ; and
international/trade implications).

2.6  Conclusions 

The primary focus of federal internetworking should be on
meeting agency mission requirements.

The processes and structures supporting federal
internetworking must identify requirements for interagency
services, infrastructure, and technology insertion, and must
enable internetworking services to evolve with changes in
agency requirements.

The National Performance Review mandates increased
interagency communications, and between government and the
public, as an essential part of every agency's mission. 
Affinity groups should be identified, beginning with those
in the National Performance Review, and empowered to build
interoperability while maximizing use of existing network
infrastructure to the extent that it is practical.

Because there are differences in maturity of the
technologies that could satisfy the wide range of federal
internetworking requirements, the process and structure must
ensure timely and coordinated deployment of evolving
technologies from advanced research, through pilot
networking, to commodity services. 3.0  INTERNATIONAL INTEROPERABILITY AND TRADE

Federal  agencies have requirements for international
interoperability with other nations that are usually
satisfied by the use of voluntary international standards
and the international public infrastructure.  In addition,
products and services to satisfy agencies' internetworking
needs are obtained from the international commercial open
market.  There are international inter-relationships between
standards, public infrastructure, obligations, the
marketplace, and trade and national competitiveness.

3.1  Formal International Standards

Agencies have traditionally been encouraged - in fact,
mandated by FIPS - to base their interoperability
architectures on formal international standards, such as
those from ITU and ISO.  These standards are agreed to
according to due process and established procedures, and
they have the formal recognition of governments worldwide. 
IPS standards are also frequently identified as
"international" standards.  The question of the formality of
the "international" standards status is seen as
problematical by governments worldwide, who are not widely
disposed to adopt any self-styled "international"
constituency standards.  

To gain the approval of governments, most "international"
standards organizations either seek the formal route of
obtaining peer-to-peer liaison status with the widely
recognized international standards organizations, or they
submit their standards through existing third party routes
such as through a national body (e.g., IEEE LAN standards
take this route) or through another liaison organization. 
The subject of Internet Society liaison to ISO/IEC Joint
Technical Committee 1 (JTC1), as well as the general subject
of JTC1 recognition and utilization of standards developed
by non-ISO/ITU bodies, is currently under active discussion
within JTC1.  See also Section 4.3.

3.2  International Public Infrastructure

In providing for international interoperability, the
international public communications infrastructure offers
the most leverage.  Simply by virtue of market pragmatics,
any user who is connected to the worldwide public networks
through commercial off-the-shelf hardware and software
systems has a practical basis for a degree of
interoperability with other users.  Two users who
interconnect to the worldwide X.25 network, the worldwide
telephone network, or the worldwide Internet, have a degree
of interoperability based on their end-systems hardware and
software interfaces and protocols.  Agencies should be able
to establish international interoperability across any of
these networks that meet their needs.

For newer technology networks, such as Integrated Services
Digital Network (ISDN), Frame Relay, Synchronous Digital
Hierarchy (SDH), Broadband ISDN (BISDN) or Asynchronous
Transfer Mode (ATM), the end-to-end interoperability and
infrastructure is not currently as well established as the
older networks, but instead, is a matter of intense
interoperability agreement development in industry
consortia, in ITU, and in user groups such as the North
American ISDN Users' Forum (NIUF).  The Federal Government
should participate in these groups as needed to assess their
potential for meeting their needs and for achieving
international interoperability.  Until the international
interoperability is established and the international
infrastructure is in place, use of these newer technologies
to meet agency mission needs will have to be balanced
against risk, cost, and the effects of limited availability.

Perhaps the most dominant international interoperability
user group is the Internet community.  It has international
scope for its open process of developing and promoting
Internet drafts, proposed standards, and recommended
standards, and of fielding public domain interoperable
implementations.  Moreover, Internet standards and even
proposed standards are often quickly available
internationally as services on the Internet (e.g., the rapid
growth of Gopher, Wide Area Information Servers (WAIS), and
World Wide Web, or the rapid deployment of IP multicasting
in the Multicast Backbone (MBone)).  Agencies should have
the freedom to select the IPS for international
interoperability with other agencies by connecting to the
international Internet infrastructure and by acquiring
products based on these interoperable implementations.

3.3  Multinational Commercial Products

Another widely used approach for achieving international
interoperability is to exploit the increasingly
multinational commercial character of the computer and
communications marketplace.  Proprietary but highly popular
product implementations, such as Postscript and WordPerfect
have become the "common-use standard" for many commercial
organizations.  Governments should also be able to buy these
products when "international standard" solutions are not
widely available in the marketplace.

Open markets provide the highest quality, most cost-
effective multivendor international interoperability, as
long as buyers hold the vendors accountable for their
claims.  Well known multinational vendors such as Sun, HP,
DEC, IBM, Novell, Microsoft, Intel, Cisco, 3Com, Synoptics,
and many more, have products that have acquired significant
market share because of their functionality, cost
effectiveness, and open interfaces.

A related area for consideration concerns multinational
consortia such as X/Open, ATM Forum, and Open Software
Foundation (OSF).  These organizations are increasingly
becoming responsible for defining and promoting
internationally interoperable enterprise solutions. 
Consortia (discussed more fully under Standards Process)
frequently can develop quick, industry-wide consensus for
emerging technologies.  The consortium approach needs to be
recognized as an acceptable process when aimed properly at
promoting the rapid development of open products from
multiple vendors and the rapid deployment of international
infrastructure.  Governments and large users should be
vigilant to join consortia as appropriate to keep them
focused on open global market building to meet user needs
and keep them from degenerating into noninteroperable market
islands or regional differences.

As an example, an agency should be permitted to specify the
OSF Distributed Computing Environment (DCE) as a solution to
its international interoperability needs, especially if it
can be established that there are multiple interoperable
solutions in the marketplace that satisfy the agency mission
and its international partner agencies.  For example, NASA
may decide to adopt "DCE over ATM" for interoperation among
its earth science data archives, claiming international
interoperability with NOAA, Japan, and European partners who
will also have multiple multinational implementations of DCE
and ATM available to them.  If the agency believes that
mission and infrastructure interests are best served by
selecting newer technologies in the open marketplace, older
technology should not be imposed.


3.4  International Obligations

The ITU is a formal treaty organization, organized and run
under the auspices of the United Nations.  The ITU
Telecommunication Standardization Sector (ITU-T) produces
Recommendations, some of which are endorsed as standards by
member countries.  The United States is represented in the
ITU by the Department of State, and for X.400, the
Department represents the Administration in the U. S. 

In NATO, the overall strategy for improving interoperability
of data systems is based on the use of civil international
standards to the maximum extent possible, i.e., on OSI.  Now
being developed, the NATO Open Systems Interconnection
Profile (NOSIP) is patterned after national GOSIP programs,
to facilitate the identification, specification, acceptance
and procurement of military communications and information
systems.  NOSIP describes internetworking approaches based
on both connection-oriented and connectionless mode network
services.  The NATO Communications and Information Systems
Agency (NACISA) has recently recommended that the scope of
NOSIP be expanded to include TCP/IP, but this recommendation
has not yet been accepted.  With the growth of LAN complexes
at NATO sites and the need to interconnect these sites,
there is an ever expanding use of IP router implementations. 
Within NATO, interoperability experiments/developments
dealing with OSI applications like X.400 and X.500 use
TCP/IP to provide the underlying transport service.

The Federal Government is using both OSI and IPS to satisfy
international communications requirements.  Major research
agencies such as NSF, ARPA, DoE, and NASA, make extensive
use of the Internet in support of worldwide scientific
research and collaboration.  NASA, NOAA, and DoE have
extensive requirements for worldwide exchange of earth
observation and environmental information with their
counterpart agencies in other countries.  Some Internet
links between the U.S. and foreign networks are for mission-
specific purposes, while others are part of the
infrastructure or are provided under cooperative agreements
with carriers.  The Internet and the IPS is pervasive in the
international research community, with OSI use limited to
X.400, X.500, and a Connectionless Network Service (CLNS)
pilot.  However, other non-research agencies that do not use
the Internet are using a full OSI stack to support OSI
applications for international communications.

3.5  International Trade and National Competitiveness

The U.S. Government fosters international free trade as a
matter of public policy, to allow U.S. industries to compete
effectively on an internationally level playing field.  U.S.
buyers are best served when they can choose freely among the
highest quality and best value products available in the
open world marketplace.  However, achieving agency
international interoperability involves some difficult
international trade issues.

The Office of U.S. Trade Representative (USTR) is
responsible for obtaining, through bilateral and
multilateral negotiations, such as the General Agreement on
Tariffs and Trade, the most level playing field possible for
U.S. products including computer and communications
products.  The USTR is able to use the market success of
U.S.-based multinational computer and communications
companies as an example of the benefits of free trade. 
Agencies will then have to abide by the agreements
negotiated by the USTR such as agreements that require some
uniformity in the use of international standards to qualify
products so as to eliminate nontariff barriers to trade.

U.S.-based multinational companies in the computer and
communications fields are aggressively seeking to expand
their worldwide market shares.  U.S. agencies should be able
to take advantage of and assist this national
competitiveness by acquiring products and services that
promote U.S.-based multinational solutions.  Foreign
companies are also searching for ways to lead the
marketplace.  If U.S. internetworking technologies have a
prominent role in the international interoperability
solution marketplace, then it is advantageous for U.S.
agencies to use these same solutions to interconnect with
domestic and international partner agencies, thus further
growing the market.  This is simple international
competitiveness on an open playing field, exactly equivalent
to the Japanese selling their cars based on quality and
value and the French selling their wines based on quality
and value.  Agencies should be allowed to use the best
available international open solutions to achieve their
mission interoperability needs, also based on quality and
value in the competitive marketplace.

[NOTE:  Public comment is specifically requested on this
Trade section.  What are the trade implications and issues
for US government agencies acquisition of internationally
interoperable solutions for meeting agency mission needs?]

3.6  Conclusions 

The best overall approach for the Federal Government to
achieve international interoperability is to rely on
agencies to "do the right thing" in their selection of
mission-optimal choices from the variety of international
interoperability means described above.  Agency choices
should be based on broad policy leadership and guidance from
OMB and NIST, as well as from affinity groups.  Agencies and
interagency coordinating committees (i.e., affinity groups)
should work with their counterparts in other countries to
establish worldwide interoperable solutions between partner
government agencies, as appropriate to meet their mission
needs.  The multinational computer and communications
product marketplace and the international public
infrastructure should have an equal place alongside the
international standards for providing legitimate means for
agencies to achieve their interoperability goals.  

Successful international internetworking products and
services should be recognized by their viability in the
international marketplace, not necessarily by their
instantiation as formal international standards.

The Panel acknowledges the importance of basing federal
internetworking on internationally available internetworking
technology and solutions.

The government should participate in industry consortia and
formal standards organizations, as appropriate, to ensure
that user needs are met and to prevent the development of
undesirable islands of noninteroperability. 4.0  STANDARDS PROCESS

4.1  Goals of Standards

Standards by themselves are not a goal but are a means for
achieving goals.  Standards should facilitate the following
goals for federal internetworking.

Fulfilling Federal Mission Needs.  Satisfying legislated
mission needs and other agency mission needs is the highest
priority of federal internetworking.  For example, the NPR
identifies seven needs for electronic government networking,
including integrated electronic access to government
information and services and a national law enforcement and
public safety network.

Enabling Interoperability.  The coming electronic government
and electronic society requires that government agency
systems have built-in interoperability, independent of
specific mission need.  For example, the NPR identifies the
need for government-wide electronic mail.  Interoperability
of government and private sector systems is key to providing
service to the citizen.

Providing For Software And Hardware Portability.  Known
informally as "plug and play," portability enables software
and hardware developed in one environment to be applied
easily in other environments for other uses.  Software and
hardware portability reduces the time, effort, and cost
needed to apply existing solutions to new problems.

Lowering Cost.  Standard solutions which are widely
applicable are almost always lower in cost because of
competition and volume.  Solutions bought in large numbers
provide an attractive marketplace, resulting in effective
competition.  Standard products which are widely available
in the marketplace are good for everybody:  users, vendors,
and taxpayers.

4.2  Development and Use of Standards

The federal internetworking goals stated above are not
simply facilitated by the use of standards; they would be
literally inconceivable without them.  Standards specify the
network interfaces and the dynamic interactions
("protocols") between heterogeneous systems.  The Panel
discussed how the standards for federal internetworking
should be selected, and the Panel consulted OMB Circular No.
A-119, revised, October, 1993, "Federal Participation in the
Development and Use of Voluntary Standards," (OMB, 1993)
which provides federal policy guidance in this area. 
Voluntary standards are established generally by private
sector bodies, both domestic and international.  A-119
states that voluntary standards are preferred for federal
use, and  that international standards should be considered
in the interests of promoting trade.

Maximum attainment of the goals above requires that the
first choice must be given to the use of open,
international, voluntary standards.  This means requiring
standards for publicly specified internetworking interfaces
and protocols that are developed with the voluntary
participation of people from all interested countries, and
which may not necessarily be mandated by treaty or legal
agreement but are simply available for adoption by users and
vendors in the open competitive marketplace.  When the
standards process is working properly, the agreement on
open, international, voluntary standards leads quickly to
the widespread availability of low-cost products, thereby
helping to assure that public sector internetworking based
on competitive acquisition of standard products will produce
the lowest-cost satisfactory result.

After open, international, voluntary standards, the second
choice for federal use would be national voluntary standards
and consortia standards.  National and consortia standards
often precede or supplement international standards.  Many
consortia (but not all) produce "implementation agreements"
and specifications" (not standards) that are based in large
part on standards produced by formal standards organizations
such as ISO and ITU.  The phrase "consortia standards" will
be used to include consortia implementation agreements. 
Properly established and directed, consortia focused on
particular technologies can achieve rapid agreement on
standards required to assure interoperability of
implementations of those technologies.  Good examples are
the ATM Forum's User-Network Interface (UNI), X Window,
X/Open Portability Guide (XPG), and Open Software Foundation
(OSF) Distributed Computing Environment (DCE).  To assure
that the consortia are focused on meeting user needs in the
open marketplace rather than on establishing cartels,
federal agencies, acting as large user organizations in
their own right and in the public interest as well, should
become members of appropriate consortia.  The activities of
multiple agencies should, however, be integrated to assure
optimization of resources applied.

The third choice for federal use, representing the best
tactical alternatives when more strategic options are
unavailable, are proprietary "standards" available in the
marketplace.  These are good products in common use that
offer real value to users as determined in the open
competitive marketplace.  Examples are IBM's SNA and CICS
for transaction processing, Macintosh products, Microsoft
Windows user interfaces, Adobe PostScript files, and
WordPerfect documents.  Smaller affinity groups often adopt
such proprietary standards.  These are not strategic
government-wide interoperability choices, 
but rather pragmatic alternatives available to agencies in
the absence of products that conform to open international
voluntary standards and consortia standards.  When agencies
select proprietary standards, the agencies must be vigilant
to assure that agency criteria for interoperability,
portability, and scalability, as well as federal competition
objectives, 
are also met.

When proprietary standards are selected, there may be
options available that lessen the impact of supporting
multiprotocol network infrastructures, and maximize use of
existing infrastructure by running the vendor's proprietary
application stack on top of an open network layer.  An
example is Novell's Netware being able to run proprietary
application stacks on top of an IP lower layer
infrastructure.  While these products do not achieve the
type of multi-vendor interoperability at the application
level, they do lessen the network manager's burden in having
to manage multiple lower layer protocols, and mitigate the
creation of unnecessarily separate network infrastructure,
thereby reducing cost and improving service.  So to the
extent that use of proprietary network layers can be
lessened even if proprietary applications are used, this
strategy should seriously be considered.

While a single standard for a given function is the ideal,
in reality multiple standards and proprietary solutions
often compete as a result of innovation, competition between
standards organizations, and competition for market share. 
The Federal Government, as primarily a user rather than a
developer of IT, seeks the benefits of innovation and market
competition, while minimizing the number of competing
standards or proprietary solutions that hinder
interoperability.  In the case of existing multiple
standards that each offer useful functionality, such as IPS
and OSI, coexistence and interoperability techniques can be
used, such as RFC 1006, which defines the use of OSI
applications over TCP/IP (Rose, 1987).

As existing standards evolve, the Federal Government should
work towards convergence of similar standards through its
participation in various standards organizations.  For
example, the replacement for IP should converge with the
replacement for the OSI connectionless network protocol
(CLNP).  In the longer term, convergence of existing
standards and avoidance of competing standards for emerging
areas of technology (e.g., protocols for high-performance
networks), would be helped by "converging" multiple
standardization processes for a given area of technology
into a single international standards forum, whether ISO,
ITU, IETF, or one of the consortia.  For example, ISO, ITU,
and IETF could together decide that IETF would be the home
for standards in the area of internetworking.

4.3  The Specific Question of IETF Standards

Standardization of the IPS is carried out by the Internet
Engineering Task Force (IETF).  The IETF is managed by the
Internet Engineering Steering Group (IESG) whose operation
is overseen by the Internet Architecture Board (IAB) and
whose procedures are approved by the Internet Society
(ISOC).  The Internet Standards process is defined in RFC
1310 and is currently undergoing revision (Chapin, 1992).

The Panel believes that for the U.S. Federal Government,
IETF standards should qualify as "open, international,
voluntary standards" and, therefore, should qualify for use
on an equal basis with standards from internationally
recognized standards organizations.  The Panel recognizes
that questions have been raised both nationally and
internationally as to the "legitimacy" of the IETF claim to
being an "open, international, voluntary standards
organization" because of the absence of formal international
recognition.

In response to a specific Panel request, NIST prepared notes
for discussion of this issue (Hogan, 1993).  Written
procedures that provide for due process, openness,
consensus, and balance are generally required in voluntary
standards activities and reduce the risk of antitrust
liability.  IETF has a written and enforced due process, and
their meetings are most assuredly open to any and all
participants.  However, the IETF means of assuring consensus
may be open to legal challenge, since the IETF does not
practice formal voting.   Also, the absence of formal voting
makes it more difficult for IETF to show that balance has in
fact been achieved (meaning that vendors, users, and the
needs of the public have all been taken into account).  The
IETF standards approval process may truly be a new paradigm,
but the old legal system has a way of challenging new
paradigms, especially when real commercial value is
involved.  The Panel believes that the IETF process
satisfies the government's needs as a user of voluntary
standards, as defined in A-119, but that more formal
documentation of consensus and formal international
recognition would enhance acceptance by vendors and other
governments.  The Panel recognizes that the IETF is working
on steps to document better their consensus process, and
that possible relationships with ISO/IEC JTC1 are under
discussion.

In its notes for discussion, NIST also identified several
options available to the IETF to promote their standards as
"open, international, voluntary" standards, other than by
"proving their legitimacy" according to the above objective
criteria.  First of all, the Panel recognizes that the IETF
has a perfect right to simply continue working on its
standards as it always has, and let the users, vendors, and
ultimately the marketplace determine their success.  The
marketplace seems to have come out decisively in the
affirmative on this issue for many IETF standards:  they are
available, they are effective, and the price is right. 
Second, the NIST analysis identifies several paths through
which IETF standards could be submitted for formal
recognition, and the Panel has no doubt that IETF and the
other standards organizations could work out mutually
constructive relationships for this purpose.

Ultimately, it is up to the IETF and its parent
organizations to decide what it wants to do in this area. 
In the meantime, agencies and affinity groups of the Federal
Government should adopt the standards selection process
described in the following section.

4.4  Federal Internetworking Standards Selection

Given that there are preferable first-second-third choices
of standards for federal internetworking, as described
above, the Panel is of the opinion that the choices must be
made by the experts from the agencies involved, with
"preferred" guidance in the form of government-wide
recommendations for strategic internetworking areas.  The
rationale for this approach, and an outline of how it would
work, is as follows.

The only internetworking strategies that demonstrably work
are strategies chosen by the people who know what is
available in the marketplace and what it takes to make
internetworking actually succeed.  Federal engineering
managers, with the assistance of vendor and contractor
teams, are making internetworking work in agency after
agency.  For example, NASA for space science and
administrative support; Department of Energy for energy
science and R&D, including security needs; Treasury and the
entitlement agencies for federal payments.

The Panel has adopted the term "affinity groups" to refer to
groupings of related agency needs such as federal science
networking or federal payments networking.  The affinity
groups, and specifically the mid-level networking engineers
from those agencies, together with their contractors, know
what it takes to create open, interoperable internetworking
based on standards.  The internetworking standards and
solutions may vary in different affinity groups, due to the
varying maturity of appropriate technology, the availability
of specialized standards and products, and the existing
infrastructure and degree of cohesion of the affinity
community.

Federal agency user forums or affinity groups, which the NPR
recommends establishing under the Government Information
Technology Services (GITS) working group, need to be given
the task of identifying appropriate sets of standards to
serve as the basis of the federal internetworking solutions
for that affinity group.  Affinity groups are discussed in
Section 2.3.  Government-wide strategic needs and public
policy needs must also be identified explicitly, and taken
specifically into account, but the choice should be focused
on meeting each affinity need in the best interest of the
agencies involved and their public constituencies. 
Government-wide needs such as electronic mail and electronic
commerce need to be led by the infrastructure agencies such
as General Services Administration or by designated lead
agencies acting in a government-wide role.  The OMB should
set the policy goals but should not dictate affinity group
objectives or technical solutions.

NIST and NTIA also have important roles to play, because
these agencies represent the Government interest in
international standards and information policy.  NIST should
play a strategic role in helping to develop and recommend
preferred "profiles," which are selections of standards for
use by affinity groups to meet government-wide strategic
objectives.  These profiles of recommended standards in
various areas should not be viewed as mandates, because the
Panel firmly believes that only the public sector
internetworking objectives should be mandatory, not the
means for achieving the objectives.  The standards to use in
achieving the objectives should be determined by the network
engineers from the agencies and affinity groups involved,
acting in the best interest of the government, with the
support of vendors and contractors chosen from the open
competitive marketplace, and taking into account the
guidance of "preferred" or recommended strategic standards
as identified by NIST with the consensus of the affected 
agencies.

As affinity groups assume greater authority for standards
identification and implementation, they will assume
increased responsibility for the Federal standards process,
particularly in the creation of standards profiles. 
Profiles are collections of standards and publicly available
specifications developed by a functional group (i.e. medical
imaging, electronic commerce) to meet a given need.  NIST
should establish a process whereby affinity groups
participate in the development of such profiles and assist
affinity groups in negotiating their objectives.  The
purpose is to encourage use of voluntary industry standards
and consortia specifications but not exclude the use of
proprietary "common use" solutions that are appropriately
justified.

Federal preferred standards profiles, as identified by NIST,
should be based on "best of breed" comparisons, taking into
account both technical and marketplace factors in
consultation with the affinity groups most affected.  The
ultimate aim is to converge the government to a single
interconnected, interoperable standards-based
internetworking environment.  This was the first objective
of GOSIP, "To achieve interconnection and interoperability
of computers and systems that are acquired from different
manufacturers in an open systems environment."  [NIST, 1991] 
The Panel believes this is still the key overall objective
of federal internetworking.  Two other objectives of GOSIP
are unchanged and will be better met by this revised
approach:  "To reduce the costs of computer network systems
by increasing alternative sources of supply;" and "to
facilitate the use of advanced technology by the Federal
Government."  The fourth and final objective of GOSIP, which
referred specifically to OSI standards, should be broadened: 
Federal preferred profiles should be supportive of open
international voluntary standardization processes,
international public sector information technology
harmonization processes, and U.S. international trade
policies.  The current GOSIP policy should be modified to
reflect this revised approach to achieving these four
objectives.  In addition, the name of GOSIP should be
modified to connote selection from a broader range of
allowable internetworking protocols, e.g. Government Open
Systems Profile (GOSP) or Government Profile for
InterNetworking (GPIN).

NTIA has responsibilities in the formulation of national
telecommunications policy, developing telecommunications
standards, and the testing of telecommunications systems. 
As the primary focus of these responsibilities, NTIA serves
as the President's principal advisor on telecommunications
and information policy.  NTIA is actively engaged in
supporting the development of the NII through basic research
and policy formulation.

The Panel also believes that all standards and profiles used
in federal networking need to be widely available in
electronic and paper form at low or no cost.  Consistent
with the policy espoused in OMB Circular A-130, these fees
should cover the cost of dissemination of the standard, not
the cost of its development.  Interoperable implementations
of the standards and profiles must also be available,
preferably with at least one reference implementation in the
public domain.  Standardization on technology which has yet
to reach implementation and limited deployment stages has
generally been less than successful.  License fees paid for
use of the technology should be reasonable and
nondiscriminatory.  

In addition, the Department of Commerce should emphasize
technology forecasting, to provide guidance on when
capabilities may be expected to transition from advanced
research to pilot networks and to commodity services.  Such
technology assessments are essential for providing agencies
assistance in evaluating the risks associated with acquiring
leading edge services.

4.5  Testing

Product conformance and interoperability is a major
consideration.  Adopting standards always involves the
consideration of how to test that the standards are in fact
met in delivered products.  The Panel believes that NIST
should continue to play a role in helping to identify
standards testing approaches.  However, the Panel is
concerned that testing should be pragmatic (focused on
demonstrating real interoperability), rather than
theoretical (focused on conformance to specifications). 
Interoperability testing may consist of multivendor
interoperability testing or interoperability testing against
a reference implementation  Regardless of the ranking of a
given standard in the context of the standards hierarchy,
validation, conformance, and interoperability testing should
follow the same paradigm.

Conformance testing can be a very valuable tool to the
developer, but can be difficult and expensive to develop and
execute definitively with rapidly evolving and integrated
products.  Instead, pragmatic tests that prove real world
interoperability are required, to decrease the overall costs
of testing and decrease the time to deliver tested products
to market.  On the other hand, once multivendor
interoperability testing becomes the agreed criteria,
agencies should insist on it, both through formal proof that
products have indeed been tested against other products and
reference implementations, as well as penalty clauses in
system contracts for products that later prove not to be
interoperable as advertised.  NIST must help here by
determining how to identify good, pragmatic interoperability
tests and the appropriate procurement language to use them. 
Agency procurements should give preference to products which
have demonstrated interoperability in accordance with the
NIST program.

For conformance or interoperability testing, test suites and
approved means of testing must be available early,
preferably at the same time as the standard or profile. 
Pragmatic testing criteria should be defined for all
standards, including IPS and proprietary protocols.  The
cost of required testing must be proportionate to the value,
and registers of all tested 
products should be available in a publicly accessible on-
line database.

Recently, there have been a number of multi-vendor
interoperability testing groups formed, often sponsored by
an independent organization, and with significant end user
participation (e.g., the FDDI interoperability test lab at
the University of New Hampshire, the OSPF interoperability
group).  These groups focus on testing multiple vendors'
implementations against each other, looking for bugs and
areas of less than desirable robustness, etc.  The Panel
views these sorts of efforts as a step in the right
direction by the vendor community.  These types of practical
testing efforts can improve the quality of real world
implementations fielded by commercial vendors, especially
when large end user organizations can also participate and
bring test scenarios to the table.

4.6  Conclusions 

Federal internetworking should be based on the following
   hierarchy of standards:

   - first, open international voluntary standards;

   - second, national voluntary or consortia standards;

   - third, proprietary or common-use "standards" with a
     preference towards those that enjoy multinational
     commercial prevalence.

The Federal Government should recognize IETF standards as
open international voluntary standards.

The current GOSIP policy, FIPS 146-1, should be modified to:

   - recognize both OSI and IPS protocols including RFC 1006
     and hybrid stacks as acceptable internetworking
     standards.  Specific consortia and proprietary
     standards may be recognized in exceptional cases if
     agreed to by a specific affinity group and clearly in
     the Government's interests.

   - modify the name of GOSIP to reflect the wider range of
     internet protocols (e.g., GOSP or GPIN);

   - change the applicability statement such that agencies
     should give first preference to profiles defined in the
     revised policy when acquiring internetworking products
     and services; affinity groups should give preference to
     profiles that promote interoperability and
     infrastructure.

Federal preferred standards profiles should be identified by
NIST, based on the hierarchy of standards, taking into
account technical, marketplace and infrastructure factors,
in consultation with the affinity groups most affected.  The
ultimate aim is to converge the Government to a single
interconnected, interoperable standards-based
internetworking environment.

Government and government-funded participants in standards
development organizations should:

   - give appropriate consideration to standards consortia
     when determining priorities for participation;

   - where appropriate, act as a force for convergence towards a single
     protocol for a given functional area; 

   - identify pragmatic testing approaches that help ensure
   interoperability.
 5.0  TECHNICAL ISSUES

5.1  Functional Comparison of IPS and OSI

A document prepared by NIST provides a comparison of the
functionality of the IPS and the OSI protocol suite (NIST,
1993).  That document identifies technical differences
between the two suites while emphasizing that in many cases,
the two suites can be viewed as complementary.  The Panel
accepts that document as an even-handed assessment of the
two suites.  The following is a summary of the NIST report.

Lower Layers.  In the case of the lower layers (network and
transport), there are many similarities between the two
suites as a result of cross-fertilization in their
development.  The OSI internet protocol, CLNP, and transport
protocols drew heavily from the design and experiences of
the IPS Internet Protocol (IP) and Transmission Control
Protocol (TCP).  The design of recent routing protocols in
both the IPS and OSI suites have been influenced by each
other.  The IPS is currently facing the routing and
addressing problem in the Internet.  IP is running out of
address space as a result of the tremendous growth of the
Internet combined with the limitations of the 32 bit IP
address.  There is an explosion of routing information
because IP addresses are treated as flat identifiers for the
purpose of routing.  The IPS will have to evolve to using a
new internetworking protocol that alleviates these problems. 
In contrast, the OSI internetworking protocols do not have
these limitations.

Almost all vendors of host computers, networking components,
and distributed applications software offer support of IPS
protocols.  Most multi-protocol routers also support CLNP
and its associated routing protocols (with the exception of
the Inter-Domain Routing Protocol (IDRP), due to its recent
emergence).  Many computer system vendors support TP4/CLNP
lower layers, although support by LAN operating systems is
less widespread.  The biggest difference between the two
suites at the lower layers is in operational deployment and
experience.  The extent of IPS deployment is measured not
only by the size of the Internet, but also by IPS deployment
in private networks that are not part of the Internet.  In
contrast, there is no comparable OSI infrastructure;
although major backbone networks of the Internet offer CLNP
switching services, these are lightly used.  The number of
personnel experienced in the management and administration
of IPS networks relative to OSI networks is proportional to
the relative size of their respective installed bases.

Electronic Mail.  In the case of upper-layer services and
applications, the OSI standards define a richer set of
functionality in some cases.  The IPS electronic mail
application, Simple Mail Transfer Protocol (SMTP), contains
many services similar to the OSI X.400 message handling
system.  A service included in X.400 which is not present in
SMTP is standardized acknowledgments.  The Multi-media
Internet Mail Extensions (MIME) to SMTP expand the message
format to include non-ASCII text and multi-media
attachments.  X.400 interpersonal messages may contain
multiple body parts such as text, fax, voice, word
processing documents, and spreadsheets.  In addition, X.400
can be used to convey electronic data interchange (EDI)
messages for business applications between computer
applications.  Proprietary electronic mail systems are
widespread, with SMTP or X.400 gateways used to provide
external interoperability, but the additional X.400 or MIME
functionality is seldom made available to users.

Network Management.  The network management application
services in the IPS are collectively referred to as the
Simple Network Management Protocol (SNMP).  The
corresponding set of services in the OSI suite are
collectively referred to as the Common Management
Information Protocol (CMIP).  Both the IPS and OSI
management models utilize a client/server paradigm, where
the server contains managed resources and the client
requests services from the resources. The IPS management
protocol has had widespread implementation by many vendors
over the last several years.  The OSI management protocol
has been slow to be deployed.  Recent work has focused on
interworking of the IPS and OSI management protocols. 
Currently, SNMP seems to be the protocol of choice for
managing multi-protocol networks.  

File Transfer.  The IPS file transfer application, the File
Transfer Protocol (FTP), is a simple protocol designed to
transfer files between remote hosts.  The OSI counterpart,
File Transfer, Access and Management Protocol (FTAM), is
more sophisticated with additional capabilities such as the
ability to access, manipulate, and transfer portions of an
entire file.  Commercial implementations of FTP are widely
available and FTP is widely deployed throughout the
Internet. The provision and use of anonymous FTP services is
the primary mechanism for the public sharing of files in the
Internet community. Commercial FTAM implementations are also
available for most computing environments, although some
current FTAM products only implement the simple file
transfer and management profiles.

Remote Login.  The IPS virtual terminal protocol, TELNET,
was designed with scroll mode terminals in mind, although
some page mode terminal properties can be negotiated.  The
OSI Virtual Terminal (VT) application provides mechanisms to
insulate application processes from the specific
characteristics of the terminals with which they
communicate. The VT standard and implementors' groups have
defined several profiles for specific types of terminals and
applications, including the Generalized Telnet profile to
support services equivalent to those provided by the IPS
TELNET, the Forms profile to support the use of forms-based,
field-oriented, data-entry applications, and the Paged
Application profile to reflect the functionality of existing
block-mode terminals.  IPS TELNET implementations are widely
available and used extensively on the Internet for remote
login.  Users can procure VT implementations supporting
several asynchronous mode profiles, but actual deployments
of VT are not widespread today. 

Directory Services.  In the IPS environment, there is no
integrated directory service, but look-up capabilities are
provided by three components: WHOIS, the Host Table, and the
Domain Name System (DNS). WHOIS is a database service that
can be queried for information about network users, Internet
host machines, and the hierarchical domains used for naming
purposes within the Doman Name System.  The Host Table
contains the official name and network address of network
components that may be queried or copied.  The DNS is a
hierarchical distributed database system with servers that
provide translation between host name and corresponding host
address, and vice-versa.  The OSI directory, commonly
referred to as X.500, is designed to be a highly scalable
and extensible distributed database system.  The OSI
Directory has many standardized object classes including
people, organizations, organizational units, countries,
localities, and application processes.  The architecture of
the OSI Directory is specifically designed to accommodate a
broad spectrum of locally defined objects and attributes
without the need to modify either the standard or server
implementations.  WHOIS and DNS are widely used by the IPS
community; the Host Table is used by legacy implementations
that have not been converted to use DNS.  The OSI X.500
Directory is being deployed in a large number of countries,
including a large-scale pilot in the U.S. and deployments in
Europe that contain over one million user entries.  In most
of these deployments, the OSI Directory is used in
conjunction with RFC 1006 which specifies a mechanism that
allows OSI applications to run in the IPS environment.

The above summary comparison covers the most basic services. 
Additional areas of comparison exist, for example, security
services to be addressed in the next section.  Moreover,
these are areas where no direct comparison is possible
because a capability exists in only one suite.  Some
examples are discussed in section 5.3.  The bottom line is
that both the IPS and OSI suites have desirable features
that satisfy some requirements.

5.2  Security

This section expands upon the comparison contained in the
NIST report for IPS and OSI security.  As with the other
areas, the situations are not directly comparable, because
the Internet situation involves both a protocol suite and an
extremely large operational system.  The IPS-based Internet
is unique:  it has no counterpart of similar scale that uses
the OSI suite.  Also, the Internet community has worked
mostly bottom-up, while the OSI community has worked top-
down.  That is, the Internet community has traditionally
focused on concrete implementation and deployment of
individual protocols designed for specific purposes.  The
OSI community has traditionally concentrated on abstract
models and architectures.  Nevertheless, little security has
resulted in either case. Until recently, the Internet has
placed little emphasis on security. Although OSI designs
included many security features, they have been infrequently
implemented.

It is difficult to measure and compare the resources being
expended on security.  Both suites have grown large, and
there are numerous, decentralized committees involved.  Now
the Internet is paying more attention to generalized
architectural matters, and OSI is becoming more practical,
possibly because of competitive pressure from the Internet's
success.  The two communities are beginning to borrow freely
from each other and from other standards bodies, such as
IEEE.  The government has invested significantly in OSI
security initiatives, such as the Network Layer Security
Protocol (NLSP) and Transport Layer Security Protocol
(TLSP).  Although these are now International Standards,
there is little deployment experience.

With respect to the security situation in the operational
Internet, the infrastructure is highly vulnerable to a
variety of threats.  The fundamental routing protocols and
elements are largely unprotected.  Directory services,
particularly the Domain Name System, are similarly
unprotected.  The IETF is just beginning security work for
these two areas.  OSI is no better in the routing area, OSI
defines directory security, and implementation with strong
authentication and access control are starting to appear. 
The IPS mail protocol, SMTP, does not define any security
features, and is known to be vulnerable to forged messages. 
Security features have been defined for the most important
Internet management protocol, but they are not yet widely
deployed and they lack a system of key management support. 
The OSI situation in the management area is no better.  Many
other protocols in both suites have no security.

There are many bottom-up activities underway in the Internet
community to add security to the IPS, and there are also
top-down activities intended to coordinate the rest of the
efforts.  Driven by widespread usage and rapid
commercialization, it is likely that the next two or three
years will see significant improvement in the operational
Internet security situation, particularly aimed at a
reduction in the vulnerability of the infrastructure.  A
number of U.S. security policy issues affect the pace of
security deployment in the Internet, since solutions need to
be applicable worldwide.  These policy issues include
cryptography, key escrowing, export control, digital
signature standards and patents.

Internet hosts lack the kind of standard, end-to-end
encipherment protocols that they need to protect a variety
of applications.  However, even if these existed, end
systems have many other security problems unrelated to
protocol standards.  Most security vulnerabilities in
Internet hosts stem from problems in specific
implementations and in host configuration and management
practices.  In both of these areas, OSI has no inherent
claim to be more secure.  The wide use of IPS
implementations and availability of source code has
permitted continued close examination by those intent on
finding implementation holes.  Future wide use and
availability of OSI implementations might result in the same
kind of experience.  Again, the bottom line is that both the
IPS and OSI suites have limited capabilities to support
security, and more work needs to be done.

5.3  Technical Sufficiency

Both IPS and OSI are satisfying many Federal Government
requirements.  Deployment of OSI is more limited compared to
the widespread use of IPS.  Both the IPS and OSI suites have
technical limitations, and no protocol stack meets the full
range of present or future government requirements.  Both
IPS and OSI have limitations in some areas:  security;
accounting information for cost allocation; transaction
processing; and real-time applications.

Current weaknesses of IPS include limited address space and
inadequate directory services.  A strength of IPS is the
speed with which new applications become widely available. 
This is exemplified by the rapid growth in information
searching and retrieval capabilities, such as Gopher, Wide
Area Information Servers (WAIS), and World Wide Web. 
Extensive experimentation is taking place with multicasting
(using the multicast backbone or MBone) and with real time
video and audio.

Strengths of OSI include an expanded address space, full
directory services and Electronic Data Interchange (EDI), as
well as formal international acceptance.  The major weakness
of OSI is that the number of deployed systems is small
compared to the number of deployed systems using IPS.  There
are fewer OSI products in the marketplace, and they are not
as mature or well integrated as equivalent IPS products. 
For example, few host implementations of OSI ship with a
built-in CMIP management part or have a full stack of
applications that tie together X.500 directory, VT, FTAM,
and X.400 as a package that all plays together and is
optimized for high throughput and performance.  There is
pressure to re-engineer products such as FTAM and VT, which
are perceived as unnecessarily complicated.  Efforts are
underway to define and implement a minimal OSI (mOSI) stack
that, while conformant, only contains the protocol
facilities that exactly match the requirements of the
supported applications.  Some OSI products are harder to
install and configure because of their complexity and the
lack of tools and utilities.  On the other hand, the number
of X.400 and X.500 applications in the Federal Government is
increasing.  Most of these applications use protocols other
than a pure OSI suite.  Several agencies have committed to
deploy an operational X.500 directory infrastructure (DOD,
NASA, and USPS).  X.500 directory services are used by IPS
applications, as well as by OSI. 

Despite the availability of the IPS and OSI protocols
suites, proprietary systems