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:      [email protected] (Ian Hoyle)
To:        comp.protocols.tcp-ip
Subject:   Re: Australian file transfer program - help?
[email protected] (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 ([email protected]) 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   [email protected]
 \  / / /   :  
  \/\/\/    : "perl - the swiss army chainsaw of UNIX tools"
            :               -- Rob Kolstad

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 1994 11:32:51 +0100
From:      [email protected] (Andreas Frackowiak)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: DOS TCP/IP as an IP GATEWAY ?
[email protected] (Ken Wallewein) writes:
>In article <[email protected]> [email protected] (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
[email protected]                                      FAX: +49-2305-25411
                                               [email protected]

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 Jan 1994 13:21:37 GMT
From:      [email protected] (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  ([email protected])

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Jan 1994 10:07:53 GMT
From:      [email protected] (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 ([email protected]) 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: [email protected] (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 <[email protected]> [email protected] (Hitoaki Sakamoto) writes:
: >    >In article <[email protected]> [email protected] (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
: > [email protected] // [email protected] // ...!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: [email protected]
: V-Mail-To: +1 212 854 8120

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 94 12:31:52 GMT
From:      [email protected] (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:  [email protected]

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Sun, 2 Jan 1994 18:07:47 GMT
From:      [email protected] (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: [email protected]
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:      [email protected] (Mark Morley)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET/LINUX/BBS
Stan F./ InfoTec Development ([email protected]) 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:      [email protected] (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 "[email protected]". Thank you.



-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 07:05:05 GMT
From:      [email protected] (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

[email protected]



-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 1994 01:56:05 -0800
From:      [email protected] (Kazimir Kylheku)
To:        comp.protocols.tcp-ip
Subject:   Re: Two PC Network... :-((
In article <[email protected]>,
Harrington <[email protected]> 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:      [email protected] (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 			[email protected] 

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 1994 16:39:28 GMT
From:      [email protected] (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 - [email protected]       |   /   All Std. Disclaimers apply.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 17:07:44 GMT
From:      [email protected] (Kim H|glund)
To:        comp.protocols.tcp-ip
Subject:   Re: Practical Network Trouble Shooting Books
[email protected]corp.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:      [email protected] (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP References in RFC1122 - where are they?
In <[email protected]> [email protected] (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:      [email protected] (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: [email protected]

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Jan 1994 21:46:00 GMT
From:      [email protected] (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: Practical Network Trouble Shooting Books
In article <[email protected]> [email protected] (Kim H|glund) writes:
>[email protected] (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: [email protected]

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Jan 1994 23:22:30 GMT
From:      [email protected] (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
[email protected]    |   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:      [email protected] (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:      [email protected] (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
[email protected]    |   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:      [email protected] (Kazimir Kylheku)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET/LINUX/BBS
In article <[email protected]>,
Stan F./ InfoTec Development <[email protected]> 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:      [email protected] (Derek Jean-baptiste)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or
In article [email protected], [email protected] (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:[email protected]		|FAX :(212) 783-4838
N.Y., NY. 10048		|I-net	:[email protected]	|Beep:(212) 646-7200


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 15:27:51 GMT
From:      [email protected] (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
[email protected]
Richard Berke   RBRK   [email protected]  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 94 20:54:01 EDT
From:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for PD TCP/IP for VAX/VMS
In article <[email protected]>, [email protected] (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
> [email protected]

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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Frame types!
In article <[email protected]> [email protected] 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:      [email protected] (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: Frame types!
[email protected] (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....
  [email protected]


-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 19:35:02 GMT
From:      [email protected] (Nectar Nirvana)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!
In article <[email protected]>, Art Berggreen wrote:
> In article <[email protected]> [email protected] 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
[email protected]m    |   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:      [email protected] (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
[email protected]

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Jan 1994 21:17:30 GMT
From:      [email protected] (Erick Engelke)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or
Derek Jean-baptiste <[email protected]> wrote:
>[email protected] (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:      [email protected] (Michael Sontum)
To:        comp.protocols.tcp-ip
Subject:   Re: Practical Network Trouble Shooting Books
Lee Parsons ([email protected]) 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 			[email protected] 


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:[email protected]    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:      [email protected] (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:      [email protected]
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  [email protected]

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 94 00:46:00 GMT
From:      [email protected] (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  ([email protected])

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 00:56:30 GMT
From:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!
In article <[email protected]> [email protected] 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:      [email protected] (Fred Whiteside)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or
In <[email protected]>, [email protected] writes:
>In article [email protected], [email protected] (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
[email protected]   [email protected]   ...!uunet!utai!utgpu!maccs!fred

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 1994 17:12:45 -0500
From:      [email protected] (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: location of RFC's
In article <[email protected]>,
Stan Huyge <[email protected]> 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:      [email protected] (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:      [email protected]
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!
In article <[email protected]> [email protected] (Art Berggreen) writes:
>In article <[email protected]> [email protected] 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:      [email protected] (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
In article <[email protected]>, Mark D. Eggers <[email protected]> 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:                               [email protected]
> 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:      [email protected] (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:      [email protected] (Stephen R Davies)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or
In article <[email protected]> [email protected] (Erick Engelke) writes:
>Derek Jean-baptiste <[email protected]> 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
_/_/_/ _/   _/_/_/     _/   _/_/_/  [email protected]
== PGP 2.x public key available === [email protected] =======

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 16:34:57 GMT
From:      [email protected] (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   [email protected]  (214) 575-2828
Texas Instruments      Plano, Texas
-------------------------------------------------------------------------

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 94 17:12:53 GMT
From:      [email protected] (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: [email protected]
| 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:      [email protected] (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

<[email protected]>

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

In article <[email protected]>, [email protected]
(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:  [email protected]    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:      [email protected] (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: [email protected]         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:      [email protected] (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:      [email protected] (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Can cslipper run on Beam&whiteside or
In article <[email protected]> [email protected] writes:

   In article [email protected], [email protected] (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 <[email protected]>      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:      [email protected] (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

[email protected]

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Jan 1994 19:45:15 GMT
From:      [email protected] (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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1
Frank Lofaro ([email protected]) 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 <[email protected]>
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:                               [email protected]
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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!
In article <[email protected]> [email protected] writes:
>In article <[email protected]> [email protected] (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:      [email protected] (Arnt Gulbrandsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Local Full Hostname?
In article <[email protected]>,
Brian Adamson <[email protected]> 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:      [email protected] (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:      [email protected] (Mike Yip)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article [email protected]  (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: [email protected]
| 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:      [email protected] (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
[email protected]

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 09:16:22 -0500
From:      [email protected] (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
[email protected]

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 01:27:39 GMT
From:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1
Frank Lofaro ([email protected]) 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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]> [email protected] writes:
>In article [email protected]  (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    [email protected]

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 16:11:06 -0600
From:      [email protected] (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      
[email protected]

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 06:16:07 +0000
From:      [email protected] (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 [email protected]
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:      [email protected] (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                                         [email protected]
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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]> [email protected] 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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 94 16:36:41 MDT
From:      [email protected] (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
In article <[email protected]>, [email protected] (Rick Jones) writes:
> Joe Doupnik ([email protected]) 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:      [email protected] (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: [email protected]
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" <[email protected]>
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:      [email protected] (Ian G Batten)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]>,
Vernon Schryver <[email protected]> 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:      [email protected] (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:      [email protected] (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: [email protected]     |
| 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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
In article <[email protected]> [email protected] (Joe Doupnik) writes:
>In article <[email protected]>, Mark D. Eggers <[email protected]> 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 <[email protected]>
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:                               [email protected]
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:      [email protected] (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
Joe Doupnik ([email protected]) 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:      [email protected] (006600 Al Firth, T2 4E)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]>, [email protected] 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			[email protected]

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


-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 18:35:38 GMT
From:      Sayeed Ahmed <[email protected]>
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:      [email protected] (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: [email protected]
Home: [email protected]

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 19:16:28 GMT
From:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
Mike Yip ([email protected]) 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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
Mark D. Eggers ([email protected]) 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:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
In article <[email protected]> [email protected] (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    [email protected]

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

In article <[email protected]>, [email protected]
(Mike Yip) writes:
>In article [email protected]  (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:      [email protected] (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 ([email protected]phy.ucsf.edu, fax +1 415 476-4929)


-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 1994 21:17:18 GMT
From:      [email protected] (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: connect()-connect() question
In article <[email protected]>,
Michael Burr <[email protected]> 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: [email protected]
Home: [email protected]

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 94 02:19:01
From:      [email protected] (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining Local Full Hostname?
In article <[email protected]> [email protected] (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.		[email protected]

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Jan 1994 21:30:14 GMT
From:      [email protected] (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: [email protected]
National Science Foundation               BITNET: [email protected]
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:      [email protected] (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:      [email protected] (don provan)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Frame types!
In article <[email protected]> [email protected] (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
						[email protected]

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 94 01:14:45 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]> [email protected] 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:      [email protected]_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:      [email protected] (Tom Soderlund)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
Donald L. Nash <[email protected]> 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). 
-- 
[email protected]

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1994 01:15:51 -0800
From:      [email protected] (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:      [email protected] (Christoph Weber-Fahr [KIT])
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or
[email protected] (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:  [email protected] 
  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:      [email protected] (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Unix routing considered harmful

		Unix Routing Considered Harmful
	Copyright 1994 by Russell Nelson <[email protected]>
	    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 <[email protected]>      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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X.25: info needed
In article <[email protected]> [email protected] (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:      [email protected] (Mark Morrissey)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful
[email protected] (Russell Nelson) writes:


>		Unix Routing Considered Harmful
>	Copyright 1994 by Russell Nelson <[email protected]>
>	    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
[email protected]         #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:      [email protected] (Tod McQuillin)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful
Russell Nelson ([email protected]) 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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]> [email protected] (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
[email protected]

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 19:13:46 GMT
From:      [email protected] (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
[email protected]




-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 19:28:03 GMT
From:      [email protected] (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful
In article <[email protected]> [email protected] (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
[email protected]                                   +1 614 459 5054 (FAX)

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 18:04:40 +0100
From:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Security Issues?
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 1994 20:42:40 GMT
From:      [email protected] (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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Can telnet report origin?
bill daniels ([email protected]) 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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Packet Fragmentation
In article <[email protected]> [email protected]_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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 20:57:55 GMT
From:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
Paul Brooks ([email protected]) 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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
Tony Li ([email protected]) 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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet option negotiation
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Jan 1994 21:04:56 GMT
From:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet sizes from hosts through routers
Joe Doupnik ([email protected]) 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:      [email protected] (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 
[email protected]


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Sat, 08 Jan 1994 00:01:32 GMT
From:      [email protected]_soft.win.net (Herman Rouge Willett)
To:        comp.protocols.tcp-ip
Subject:   Re: Alternate IP & MAC Address (Perfectly OK)
 
In article <[email protected]>, "Mark Lo Chiano" ([email protected]) 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 [email protected]_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 <[email protected]>
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
				[email protected]

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:15:34 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix routing considered harmful
In article <[email protected]> [email protected] (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    [email protected]

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:20:38 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]> [email protected] (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    [email protected]

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:24:29 GMT
From:      [email protected] (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.

	[email protected] works fine on a reply, but
	[email protected] bounces with 'name not found'


-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 01:48:55 GMT
From:      [email protected] (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]>,
Mark Evans <[email protected]> wrote:
>Tony Li ([email protected]) 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:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP address with mail?
In article <[email protected]> [email protected] (Steven Lawson) writes:
>Ok, what (if any) is the proper format for a mail address using an
>IP address?  

[email protected][NNN.NNN.NNN.NNN]
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

[email protected]          {uunet,harvard}!think!barmar

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1994 07:36:03 GMT
From:      [email protected] (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:    [email protected]

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:      [email protected] (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:      [email protected] (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Subject:   Re: Alternate IP & MAC Address

In-Reply-To: <[email protected]> "Mark Lo Chiano" <[email protected]>

In article   : <[email protected]>
"Mark Lo Chiano" <[email protected]>  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
[email protected]          |   139-147 av. Paul-Vaillant Couturier
[email protected]                      |   93126 La Courneuve - CEDEX, France



-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Jan 1994 16:46:41 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: UNIX TCP/IP packet sniffer?
In article <[email protected]> [email protected] (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:      [email protected] (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:      [email protected]_soft.win.net (Herman Rouge Willett)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
 
In article <[email protected]>, Sayeed Ahmed ([email protected]) 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 [email protected]_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:      [email protected] (Fred Whiteside)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Can cslipper run on Beam&whiteside or
In <[email protected]>, [email protected] writes:
>[email protected] (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
[email protected]   [email protected]   ...!uunet!utai!utgpu!maccs!fred

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 94 20:19:37 GMT
From:      [email protected] (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:      [email protected]_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 <[email protected]>, C.M. Leung ([email protected]) 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 [email protected]_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:      [email protected] (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		[email protected]
--
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:      [email protected] (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 [email protected]  I will summarize for anyone
who is interested in the results.

Thanks,
Steve

--
===============================================================================
DOMAIN: [email protected]                                       Steven Chanin

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 1994 21:20:41 -0500
From:      [email protected] (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:      [email protected] (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
[email protected]

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Jan 1994 15:29:32 GMT
From:      [email protected] (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                |                               |
[email protected]                 |                               |
___________________________________________________________________

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 1994 21:40:45 GMT
From:      [email protected] (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...
[email protected]    \  /         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:      [email protected] (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
[email protected] 
206-632-8093, 206-727-5020 fax


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 94 22:17:54 GMT
From:      [email protected] (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 | [email protected] |__________________
      | +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:      [email protected] (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 <[email protected]> [email protected] (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
[email protected]  | I met my death - an experience I don't hesitate
[email protected] | strongly to recommend" - Baron von Munchchausen

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 13:48:21 -0800
From:      [email protected] (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: How many CRC are needed?
In article <[email protected]> [email protected] 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:      [email protected] (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:[email protected]: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:[email protected]:[email protected]:rw:tc=300-baud:

e|Console-1200|Console Decwriter III:\
	:[email protected]:[email protected]:[email protected]:rw:tc=1200-baud:

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

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

X|Xwindow|X window system:\
	:[email protected]:[email protected]:[email protected]: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:[email protected]:tc=38400-baud:
 D2400|Fast-Dial-2400:\
	:nx=D1200:tc=2400-baud:
 3|D1200|Fast-Dial-1200:\
	:nx=D300:[email protected]: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^[email protected]: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:      [email protected] (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:      [email protected] (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:      [email protected] (Samuel Lam)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ethernet modem?
In article <[email protected]>, [email protected]
 (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
-- 
<[email protected]> -- Connectivity Technology Inc.

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

{ftp,gopher,www}.CDPublishing.com or <[email protected]>


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:17:02 -0500
From:      [email protected] (Riley G)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
[email protected] (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: [email protected]
TCP/IP:   psicop.pipeline.com         198.80.32.101














-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 12:04:27 +0000
From:      [email protected] (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:      [email protected] (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
[email protected] (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: [email protected]
----------------

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 12:16:46 GMT
From:      [email protected] (Hans-Peter Huth)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
Sayeed Ahmed ([email protected]) 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: [email protected]				|
|---------------------------------------------------------------|

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 13:40:31 GMT
From:      [email protected] (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
[email protected] (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   | [email protected]   .uucp |
  \--------------------------------------------------------------------------/

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 13:41:35 GMT
From:      [email protected] (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
[email protected]   IRC: mowgli    [email protected]



-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 13:42:13 GMT
From:      [email protected] (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
[email protected] (Keith Warren Rickert) writes:

>In <[email protected]> [email protected] (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   | [email protected]   .uucp |
  \--------------------------------------------------------------------------/

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 14:40:56 GMT
From:      [email protected] (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.          [email protected]


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



Brian Adamson
Information Technology Division
Naval Research Laboratory

<[email protected]>

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 94 14:50:24 GMT
From:      [email protected] (Cliff Green)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print
[email protected] (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 -  [email protected]
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:      [email protected] (Von Welch)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print
In article <[email protected]>, [email protected] (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: [email protected]

-- 
Von Welch ([email protected])	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:      [email protected] (John Fracasso)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print
In article <[email protected]> [email protected] (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:      [email protected] (Alun Jones)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Mosaic: Unable to save or print
In article <[email protected]> [email protected] 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:      [email protected] (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 <[email protected]>, [email protected] (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
[email protected]       Dpt. for Applied Computer Science
                              and Information Systems
---------------------------------------------------------------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 18:28:29 GMT
From:      [email protected] (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:      [email protected] (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
- [email protected]



-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:51:46 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 19:55:58 GMT
From:      [email protected] (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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling
In article <[email protected]> [email protected] 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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 20:19:04 GMT
From:      [email protected] (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 <[email protected]>, [email protected] (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
[email protected], 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:      [email protected] (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
[email protected] (Bernhard Strassl) writes:

>In article <[email protected]>, [email protected] (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   | [email protected]   .uucp |
  \--------------------------------------------------------------------------/

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:25:37 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router
In article <[email protected]> [email protected] (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
[email protected]

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:27:14 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: (C) status of RFC's
In article <[email protected]> [email protected] (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
[email protected]



-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 20:33:35 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] (Hans-Peter Huth) writes:
>Sayeed Ahmed ([email protected]) 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
[email protected]

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 20:34:36 GMT
From:      [email protected] (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
[email protected]
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:      [email protected] (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits
In article <[email protected]>,
Steven Lawson <[email protected]> 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: [email protected]    of fame?'"  - [email protected]
Home: [email protected]       "As this is alt, that should probably be '15 Mb
                             of flame.'"  - [email protected]

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 1994 22:31:04 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer
In article <[email protected]> [email protected] (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    [email protected]

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Jan 94 22:40:28 GMT
From:      [email protected] ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected] (Barry Margolin) writes:
|> In article <[email protected]> [email protected] (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.
|> 
|> [email protected]          {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:  [email protected]
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:      [email protected] (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:      [email protected] (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:      [email protected] (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router
Ran Atkinson ([email protected]) 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:      [email protected] (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
[email protected] (Barry Margolin) writes:

>[email protected] (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....
  [email protected]


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 1994 23:53:46 GMT
From:      [email protected] (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
[email protected]                                         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:      [email protected] (Brian Hall)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ethernet modem?
[email protected] (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: [email protected]
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:      [email protected] (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router
In article <[email protected]>, Rick Jones <[email protected]> wrote:
>Ran Atkinson ([email protected]) 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:      [email protected] (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
[email protected] (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   | [email protected]   .uucp |
  \--------------------------------------------------------------------------/

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 04:24:02 GMT
From:      [email protected]o.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:      [email protected] (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
          [email protected]

"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:      [email protected] (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:      [email protected] (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
psico[email protected] (Riley G) writes:
: [email protected] (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: [email protected]
: TCP/IP:   psicop.pipeline.com         198.80.32.101
: 


Best Regards
-
Luis Delgado
INESC-CCAE, Lisbon
e-mail: [email protected]
----------------

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 16:12:29
From:      [email protected] (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:      [email protected] (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about the costs of using TCP
In article <[email protected]>
   [email protected] (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: [email protected]
  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:      [email protected] (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:<[email protected]>
<<< 551 <<[email protected]>> ... User not local, Relay disabled.
550 [email protected] 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   -   [email protected] 

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 13:23:47 GMT
From:      [email protected] (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 <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
From: [email protected] (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 [email protected]

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 19:11:57 EST
From:      Andrew T. Robinson <[email protected]>
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 [email protected]

Andy

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 19:19:33
From:      [email protected] (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:      [email protected] (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" <[email protected]>
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 [email protected]    | 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:      [email protected] (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: [email protected]
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:      [email protected] (Mike King)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
In article <[email protected]>, Luis M. Delgado <[email protected]> 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

[email protected]                Speaking for me only...


-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 94 17:49:55 GMT
From:      [email protected] (Chris Huey)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP File Transfer
Edward Wells ([email protected]) 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:  [email protected]

We now return you to your regularly scheduled Usenet.

Chris
-- 
Chris Huey                                           Tactix ReEngineering, Inc.
[email protected]                                       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:      [email protected] (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 <[email protected]>

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 20:20:05 GMT
From:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Packet Fragmentation
Barry Margolin ([email protected]) wrote:
: In article <[email protected]> [email protected]_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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Intelligent BOOTP servers?
John Matthews ([email protected]) 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
: 				[email protected]

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 20:40:11 GMT
From:      [email protected] (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.

[email protected] , 708-933-5743

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 20:54:29 GMT
From:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Bootp broadcast addresses
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 21:19:47 GMT
From:      [email protected] (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:      [email protected] (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected]
("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: [email protected]

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:12:19 GMT
From:      aki <[email protected]>
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 - [email protected]

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 22:34:48 GMT
From:      [email protected] (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:   [email protected]
BOS Dev. Team                   |  USnail:     780 Madison Ln  Florissant 63031
                                |  BellNet:    (314) 289-5791

-- 
==============================================================================
Roy M Speier   	       	       	|  Internet:   [email protected]
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:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about Bootp broadcast addresses
Mike Hartman ([email protected]) 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:      [email protected] (Kim H|glund)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Wanted: RFC931 Source
[email protected] (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,  [email protected],    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:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits
Steven Lawson ([email protected]) 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:      [email protected] (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:      [email protected] (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: [email protected].com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Jan 1994 23:32:32 GMT
From:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits
Stephen C. Trier ([email protected]) 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:      [email protected] (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:      [email protected] (Vera Heinau)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Wanted: RFC931 Source
[email protected] (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 
 / \    [email protected]       |    Institut fuer Kristallographie
/FUB\                                    |    Takustrasse 6
`---'                                    |    D-14195 Berlin Germany

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 00:30:05 GMT
From:      [email protected] (Dennis Freeman)
To:        comp.protocols.tcp-ip
Subject:   Re: EZRPC
In article [email protected], [email protected] (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: [email protected]



-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1994 23:07:25 +0100
From:      [email protected] (Armin Gruner)
To:        de.comp.standards,alt.sources.wanted,comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Wanted: RFC931 Source
[email protected] (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 <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re: What?  What do you mean you can't find yourself????
In article <[email protected]> aki,
[email protected] 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:      [email protected] (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
[email protected]



-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 05:01:24 GMT
From:      [email protected]
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)]?

[email protected]

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 05:04:28 GMT
From:      [email protected] (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:      [email protected] (G. Paul Ziemba)
To:        comp.protocols.tcp-ip
Subject:   Re: How does bootp communicate without routing?
[email protected] (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: [email protected]	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:      [email protected] (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:      [email protected] (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:      [email protected] (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: [email protected]   |
|  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:      [email protected] (Michael Griesser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling
In article [email protected], [email protected] (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
[email protected]   IRC: mowgli    [email protected]


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 12:34:36 GMT
From:      [email protected] (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  ([email protected])

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:      [email protected] (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 [email protected] can Xerox
a copy of individual papers for a minimal fee.

	Rich Stevens  ([email protected])

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 13:02:19 GMT
From:      [email protected] (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
[email protected] (Mike King) writes:
: In article <[email protected]>, Luis M. Delgado <[email protected]> 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
: 
: [email protected]                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: [email protected]

----------------

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 13:06:16 GMT
From:      [email protected] (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a Firewall
In article [email protected], [email protected] (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 [email protected] can Xerox
> a copy of individual papers for a minimal fee.
> 
> 	Rich Stevens  ([email protected])


This paper is in directory pub/security as file gateway.ps.Z on ftp.delmarva.com.

---
+---------------------------------------------------------------------+    
|  John K. Scoggin, Jr.			Email: [email protected]   |
|  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:      [email protected] (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
[email protected] or [email protected]

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 13:41:31 GMT
From:      [email protected] (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:      [email protected] (Marcus J. Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a Firewall
"Jeremy G. Mereness" <[email protected]> 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 [email protected]
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:      [email protected] (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:      [email protected] (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:      [email protected] (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] (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		[email protected]
--
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:      [email protected]
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 [email protected]
    Thanks in advance
 
Alex

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 15:56:09 GMT
From:      [email protected] (Alun Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for OS/2 2.0 Bug in FTPd?
In article <[email protected]> [email protected] (Peter N Lewis) writes:
>[email protected] (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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] 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:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Backoff/Retransmit limits
In article <[email protected]> [email protected] (Ken Mintz) writes:
>Stephen C. Trier ([email protected]) 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:      [email protected] ( 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.
[email protected]

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 94 17:19:53 GMT
From:      [email protected] ( 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 ????
[email protected]

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 94 17:52:14 GMT
From:      [email protected] ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected] (Sean Allen) writes:
|> In article <[email protected]>, [email protected]
|> ("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:  [email protected]
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:      [email protected] (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)
[email protected]

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 18:56:03 GMT
From:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing
In article <[email protected]>
[email protected] 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" <[email protected]>
To:        comp.protocols.tcp-ip
Subject:   Re:  Contacting Wollongong on the Internet
In article comp.protocols.tcp-ip:19515, [email protected](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:   [email protected]
Support at Wollongong's e-mail address: [email protected]
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 [email protected]

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:      [email protected] (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
> [email protected] or [email protected]

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	       [email protected]
		      Computer Science Division
		  University of California, Berkeley

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 19:33:55 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (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:      [email protected]lsys.com (Neil L. Kleeman)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Need help w/ Versaterm SLIP, MacTCP, etc.
In Article <[email protected]>, [email protected]
(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: [email protected]   
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:      [email protected] (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 ([email protected]) 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:      [email protected] (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing

In article <[email protected]>, 
[email protected] 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), <[email protected]>
University of Arizona Network Operations, Tucson AZ 85721


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 1994 21:12:54 GMT
From:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing
In article <[email protected]> [email protected] 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:      [email protected] (Robert Pratt)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers
In article <[email protected]> [email protected] (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  : [email protected]
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:      [email protected] (Andrew Wilcox)
To:        comp.protocols.tcp-ip
Subject:   Re: Buying a router

   [email protected] (Ran Atkinson) writes:

   [email protected] (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:      [email protected] (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?
[email protected] (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 <[email protected]>       Ph: +61 9 368 2055

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jan 1994 23:11:58 GMT
From:      [email protected] (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting
In article <[email protected]> [email protected] (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.
>
>[email protected] , 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:      [email protected] (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??
In article <[email protected]> [email protected]
(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:      [email protected] (Mike King)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
In article <[email protected]>, Luis M. Delgado <[email protected]> wrote:

>[email protected] (Mike King) writes:
>: In article <[email protected]>, Luis M. Delgado <[email protected]> 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    [email protected]     Speaking for myself only....


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 00:15:29 GMT
From:      [email protected] (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers
In article <[email protected]>,
Robert Pratt <[email protected]> wrote:
>In article <[email protected]> [email protected] (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  : [email protected]

Sincerely,

Patrick Klos
-- 
============================================================================
    Patrick Klos                           Internet: [email protected]
    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:      [email protected] (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 			   		<[email protected]>
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:      [email protected] (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:      [email protected] (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: [email protected]
Other   : voice (602) 581-4496   fax (602) 581-4967

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 03:29:41 GMT
From:      [email protected] (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing
In article <[email protected]>, [email protected] 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
				[email protected]*

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 03:52:50 GMT
From:      [email protected] (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing
In article <[email protected]>, [email protected] (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
				[email protected]*

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 10:21:06
From:      [email protected] (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:      [email protected]lite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??
In article <[email protected]> [email protected] (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    [email protected]

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 94 15:55:26 -0500
From:      [email protected] (James Harvey)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Clarkson Packet Drivers
In article <[email protected]>, [email protected] (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   [email protected]   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:      [email protected] (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.
>
> [email protected]

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 [email protected] Wed Jan 12 17:41:46 1994
From: "Ingo Cyliax" <[email protected]>
To: [email protected]
Subject: Re: TCP for m68k embedded system
Newsgroups: comp.protocols.tcp-ip,comp.sys.m68k
In-Reply-To: <[email protected]>
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 [email protected] Wed Jan 12 23:09:24 1994
From: [email protected] (Fred Christiansen)
To: [email protected]
Subject: Re: TCP for m68k embedded system
Newsgroups: comp.protocols.tcp-ip,comp.sys.m68k
In-Reply-To: <[email protected]>
Organization: Motorola, 2900 S Diablo Way, Tempe, AZ 85282
Content-Length: 653
X-Lines: 14
Status: RO

In article <[email protected]> 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: [email protected]
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 [email protected] Wed Jan 12 23:49:38 1994
From: [email protected]
To: [email protected]
Subject: Re: TCP for m68k embedded system
Newsgroups: comp.protocols.tcp-ip,comp.sys.m68k
In-Reply-To: <[email protected]>
Organization: University of Hawaii
Cc: [email protected] (Raquel Sanborn)
Content-Length: 1990
X-Lines: 44
Status: RO

In article <[email protected]> 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
[email protected]              |---------------------------------
[email protected] (AmiTCP only) |<-Note the ref. to Middle Earth
------------------------------------------------------------------------------

From [email protected] Thu Jan 13 01:07:12 1994
From: [email protected] (Dave Hodgkinson)
Organization: The rfc1122 police
Reply-To: [email protected]
To: [email protected]
Subject: TCP for m68k embedded system
Content-Length: 707
X-Lines: 23
Status: RO

In article <[email protected]> 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:      [email protected] (Luis M. Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: CompuServe access
[email protected] (Andrew T. Robinson) writes:
: From: [email protected] (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 [email protected]

--
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: [email protected]

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 13:18:49 GMT
From:      [email protected] (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-
[email protected]


-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 14:20:15 GMT
From:      [email protected] (Matt Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over 802.3/802.2
In article <[email protected]> [email protected] 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
[email protected]


-- 
Matt Perry
[email protected]

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 14:35:25 GMT
From:      [email protected] (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
[email protected]                                   +1 614 459 5054 (FAX)

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 13:35:01 +0100
From:      [email protected] (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 
* [email protected] * don't need it!!!!!!!!
*************************

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 1994 16:00:18 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Large IP Site Management Tool Wanted
In article <[email protected]>, [email protected] (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: [email protected]

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 17:52:13 GMT
From:      [email protected] (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected] (Ran
Atkinson) writes:
->In article <[email protected]> [email protected] 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: [email protected]

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 18:04:15 GMT
From:      [email protected] (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP fault handling
In article <[email protected]> [email protected] writes:
>In article [email protected], [email protected] (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
						[email protected]

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 19:06:50 GMT
From:      [email protected] (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				[email protected] 
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:      [email protected] (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>,
[email protected] (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: [email protected]

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 94 19:43:23 GMT
From:      [email protected] ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected] (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:  [email protected]
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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] (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:      [email protected] (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: [email protected]

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 1994 21:44:27 GMT
From:      [email protected] (Jeff Douglass)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers
In <[email protected]> [email protected] (Robert Pratt) writes:
>In article <[email protected]> [email protected] (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:  [email protected] / 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:      [email protected] (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%[email protected]  |

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 01:30:25 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] 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    [email protected]

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 01:42:51 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] ("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    [email protected]

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Jan 94 10:05:10 +1100
From:      [email protected] (Luke Howard)
To:        comp.periphs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ethernet modem?
In <[email protected]> [email protected] (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.

-- 
[email protected] - Si seulement j'avais un SGI, je serais content...

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 14:10:26 -0500
From:      [email protected] (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
[email protected] (614) 292-0056    "I'm your huckleberry..."  -DH

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 94 14:07:11 CST
From:      [email protected] (Wayne Sewell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP vs Netbios/IPX LAN performance
In article <[email protected]>, [email protected] 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		[email protected]

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: [email protected]
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[email protected] (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:      [email protected] (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:      [email protected]
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		[email protected]
MCI Consumer Markets
4115 Freidrich Lane
Austin, TX  78744

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 16:54:27 GMT
From:      [email protected] (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
[email protected]

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 17:15:38 GMT
From:      [email protected] (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD Socket Books
Hayden Harman ([email protected]) 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:      [email protected] (Bruce A. Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
Vernon Schryver writes:
> In article <[email protected]> [email protected] 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    [email protected]
--
------------------------------------------------------------------------------
Bruce A. Mah		   Graduate Student	       [email protected]
		      Computer Science Division
		  University of California, Berkeley

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 18:59:57 GMT
From:      [email protected] (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected]
(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: [email protected]

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 19:17:39 GMT
From:      [email protected] (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP on *strictly* unidirectional data link layer??
In article <[email protected]> [email protected] (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
[email protected]                                   +1 614 459 5054 (FAX)

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 21:04:11 GMT
From:      [email protected] (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
[email protected]

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 21:46:22 GMT
From:      [email protected] (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			<[email protected], [email protected]>
Boulder County Info Svcs
Boulder CO

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Jan 1994 21:49:31 GMT
From:      [email protected] (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
[email protected]

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 1994 22:13:30 GMT
From:      [email protected] (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Improving interactive SLIP performance

In article <[email protected]>, 
[email protected] (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), <[email protected]>
University of Arizona Network Operations, Tucson AZ 85721




-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1994 11:40:48 -0800
From:      [email protected] (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:      [email protected] (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP protocol bug?
In article <[email protected]> [email protected] (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 ([email protected]) is
the author/editor of RFC-1122.  Perhaps he'd be the place to start.

					don provan
					[email protected]

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 00:45:46 GMT
From:      [email protected] (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
[email protected]
(619)674-5100  ext: 4488



-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 03:10:43 GMT
From:      [email protected] ( 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:      [email protected] (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: [email protected], [email protected]

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Jan 1994 14:36:25 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (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:      [email protected] (Michael Richardson)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?
In article <[email protected]> [email protected] (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
 [email protected] /of being fun to play with." - p.47 Intro to Quarks&Partons
 [email protected] / +1 613 729-5409 / +1 613 788-2600 3853 (work)

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1994 11:37:45 -0500
From:      [email protected] (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.  [email protected]

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 94 07:01:15 GMT
From:      [email protected] (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 >> --      | [email protected]             |
| 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:      [email protected] (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:      [email protected] (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
[email protected] (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:      [email protected] (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:      [email protected] (Grenville Armitage)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] writes:
>In article <[email protected]>, [email protected] (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:      [email protected] (John Cant)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP
In article [email protected], [email protected] (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 
>* [email protected] * 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            |
[email protected]   | 
-----------------------------------------------------------------------------


-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 94 01:00:57 GMT
From:      [email protected] (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: CIDR & variable netmask implications on subnet addressing
In article <[email protected]>, [email protected] (Aaron Leonard) writes:
> 
> In article <[email protected]>, 
> [email protected] 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  [email protected]
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:      [email protected] (Thomas A. Endo)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for secure FTP servers
John Bourke ([email protected]) 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 [email protected], 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 [email protected] for further details, or subscribe to the
firewalls mailing list via E-mail to [email protected], message
body "subscribe firewalls [email protected]".  Once you E-Mail the
[email protected] 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:  [email protected] [Work];
ARINC Research Corporation       |            [email protected] [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:      [email protected] (Thomas A. Endo)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a firewall
Sextant Group ([email protected]) 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:  [email protected] [Work];
ARINC Research Corporation       |            [email protected] [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:      [email protected] (Thomas A. Endo)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for SMTP on Ethernet Network
Richard Thiessen ([email protected]) 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:  [email protected] [Work];
ARINC Research Corporation       |            [email protected] [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:      [email protected] (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Building a firewall
In article <[email protected]> [email protected] (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:  [email protected] [Work];
>ARINC Research Corporation       |            [email protected] [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:      [email protected]  (Jonathan A. Rodin)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffers
[email protected] (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
[email protected]               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:      [email protected]  (Peter Bowyer)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: SMTP <-> DISSOS/Memo
In article <[email protected]> [email protected] (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:      [email protected] (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:      [email protected] (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP
John Cant ([email protected]) wrote:
: In article [email protected], [email protected] (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:      [email protected] (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                                               [email protected]
ASK Ingres GmbH, Frankfurt, Germany                          +49 69 66413-285

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 14:36:46 GMT
From:      [email protected] (David Lapp)
To:        comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: HP Laserjet IV & Ethernet
Jan-Piet Mens ([email protected]) 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:      [email protected] ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>, [email protected] (Vernon Schryver) writes:
|> In article <[email protected]> [email protected] ("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:  [email protected]
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:      [email protected] ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip,comp.periphs.printers
Subject:   Re: HP Laserjet IV & Ethernet
In article <[email protected]>, [email protected] (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                                               [email protected]
|> 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:  [email protected]
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:      [email protected] (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:      [email protected] (Sean Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]>,
[email protected] (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: [email protected]                   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:      [email protected] (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: [email protected]


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: [email protected]

    Craig Partridge (Program Co-Chair for North America)
    BBN
    10 Moulton St
    Cambridge MA 02138

    Phone: +1 415 326 4541
    E-mail: [email protected]


-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1994 19:57:27 GMT
From:      [email protected] (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                                   [email protected]

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 94 20:22:37 GMT
From:      [email protected] ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: RS6000 rlogin to Sun problem
In article <[email protected]>, [email protected] (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:  [email protected]
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:      [email protected] (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 : [email protected]

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

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Jan 1994 21:20:05 GMT
From:      mgic <[email protected]>
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:      [email protected] (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:  [email protected]


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 13:56:37 -0600
From:      [email protected] (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 "[email protected]". 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:      [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 1994 11:14:31 GMT
From:      [email protected] (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:      [email protected] (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:  [email protected] | *!> 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: [email protected] |         |

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1994 21:32:42 -0500
From:      [email protected] (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:      [email protected] (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 <[email protected]>, [email protected] (Willard Dawson) writes:
|> [email protected] (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
[email protected]       Dpt. for Applied Computer Science
                              and Information Systems
---------------------------------------------------------------

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 03:29:33 -0800
From:      [email protected] (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 <[email protected]>
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 <[email protected]> Karen Linde,
[email protected] 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:      [email protected] (Mark Evans)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Does anybody have mods to tcpdump to decode Novell traffic?
Steinar Haug ([email protected]) 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:      [email protected] (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:      [email protected] (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Questio on voice over TCP/IP
In article <[email protected]> [email protected] 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 <[email protected]>      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:      [email protected] (E.J.Leoni-Smith)
To:        comp.mail.sendmail,comp.protocols.tcp-ip
Subject:   Re: sendmail catatonia?
In article <[email protected]> [email protected] 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  [email protected]
>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:      [email protected] (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:  [email protected]             |

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Jan 1994 23:43:14 GMT
From:      [email protected] (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.                                   [email protected]
Senior Design Technician, Dicomed Inc.           (612) 895-3244
//////////////////////////////////////////////////////////////////////////////

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 94 00:04:18 GMT
From:      [email protected] (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
[email protected]

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 00:25:11 GMT
From:      [email protected] (TNERT)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
In article <[email protected]>, mgic <[email protected]> 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: [email protected] (Ashok Aiyar)
Subject: Re: MSDOS / Winsock SLIP server?
Date: Fri, 14 Jan 1994 01:40:13 GMT

In article <[email protected]> [email protected]
(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: [email protected]
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  [email protected]

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 11:01:50 -0500
From:      [email protected] (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: CNAME same as Domain name - OK?
In article <[email protected]>, Barry Flanagan <[email protected]> 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:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses
[email protected] (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 "[email protected]". 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:      [email protected] (Jamie H. Clark)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
mgic ([email protected]) 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, [email protected]| ClarkNet Public Access Internet, [email protected],
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:      [email protected] (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:      [email protected] (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 <[email protected]>, [email protected] (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: [email protected]

	Ehud

--
Ehud Gavron        (EG76)     
[email protected]

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 06:41:07 GMT
From:      [email protected] (Andy Heffernan)
To:        comp.protocols.tcp-ip
Subject:   Re: Multinetting ( IP MUXes ) ?
In article <[email protected]> [email protected] (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:      [email protected] (Simon Hackett)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multi Cast
[email protected] (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:      [email protected] (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 <[email protected]>| 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 <[email protected]>| 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 <[email protected]>| 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:      [email protected] (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:      [email protected] (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

- [email protected] (M.C Wong)
-- 
- [email protected]

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 14:40:38 -0000
From:      [email protected] (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 - <[email protected]>
 ----
| 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:      [email protected]
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 : [email protected]

-- 

-------------------------------------------------------------------------------
     ____       __                        |  e_mail   
    /          / |                        |
   /---       /--|  __      _ __. ._      |  Janet    : [email protected]
(_/     o  (_/   (_/ /_ |/|/ (_/|_/<      |  Internet : [email protected]
                                          |___________________________________
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:      [email protected] (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                       [email protected]    (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:      [email protected] (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses
In article <[email protected]> [email protected] (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		[email protected]	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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] (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
[email protected]




-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 15:51:08 GMT
From:      [email protected] (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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] (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
[email protected]


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 16:02:51 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice over TCP/IP
In article <[email protected]> [email protected] ("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
[email protected]




-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 16:15:11 GMT
From:      [email protected] (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: CNAME same as Domain name - OK?
[email protected] (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: [email protected]

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 17:04:29 GMT
From:      [email protected] (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: [email protected]
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:      [email protected] (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: [email protected]
800 Saginaw Drive, Redwood City, CA 94063 

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 94 19:07:07 GMT
From:      [email protected] (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: [email protected]

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 19:19:21 GMT
From:      [email protected] (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:[email protected]		|FAX :(212) 783-4838
N.Y., NY. 10048		|I-net	:[email protected]	|Beep:(212) 646-7200


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 20:00:48 GMT
From:      [email protected] (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 [email protected], [email protected] (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:[email protected]		|FAX :(212) 783-4838
>N.Y., NY. 10048		|I-net	:[email protected]	|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:[email protected]		|FAX :(212) 783-4838
N.Y., NY. 10048		|I-net	:[email protected]	|Beep:(212) 646-7200


-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Jan 1994 20:06:00 GMT
From:      [email protected] (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                     [email protected]
   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: [email protected]
           Amprnet:  [email protected]


-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1994 21:04:12 GMT
From:      [email protected] (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: X protocol over TCP/IP
In article <[email protected]>, [email protected] (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 <[email protected]>            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:      [email protected] (Jim Fiori - Special Projects)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 implementation
In article [email protected], [email protected] (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  [email protected] 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:      [email protected] ("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:  [email protected]
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:      [email protected] (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 <[email protected]> [email protected] (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:      [email protected] (Jonathan Stone)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 implementation

In article <[email protected]>, 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 ([email protected]) 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:      [email protected] (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 [email protected])

Thanks,

Nam N.




-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 13:53:46 -0600
From:      [email protected] (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   Re: Admin of multiple SLIP lines?
Peter Espen <[email protected]> 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: [email protected],  Tel: +1 512 251 8122,  Fax: +1 512 251 8308
--

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 94 09:32:00 EST
From:      [email protected] (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:      [email protected] (Simon Hackett)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: SMTP <-> DISSOS/Memo
[email protected]  (Peter Bowyer) writes:

>In article <[email protected]> [email protected] (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... [email protected] can give you more
details I expect.

Simon

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 06:21:42 GMT
From:      [email protected] (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:      [email protected] (Jens Kjerte)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for SMTP on Ethernet Network
Richard Thiessen ([email protected]) 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: [email protected]  
    | | |  | ||/ /	|  Dansk Data Elektroniks A/S  | Phone: +45 42845011

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 13:00:56 GMT
From:      [email protected] (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:      [email protected] (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			[email protected]
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:      [email protected] (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:      [email protected] (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
  /   | \/                  [email protected]
  \__/|_/\_&_/~X_           617/873-2962
 

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Jan 1994 15:52:09 GMT
From:      [email protected] (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
[email protected]



-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 15:55:39 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (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			[email protected]
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:      [email protected] (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
	[email protected]

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 20:39:56 GMT
From:      [email protected] (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 <[email protected]>, [email protected] 
(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), <[email protected]>
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:      [email protected] (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: X protocol over TCP/IP
In article <[email protected]> [email protected] (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.

[email protected]          {uunet,harvard}!think!barmar

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1994 20:52:02 GMT
From:      [email protected] (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Admin of multiple SLIP lines?

In article <[email protected]>, [email protected] 
(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), <[email protected]>
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:      [email protected] (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 <[email protected]> [email protected] writes:
>
>In article <[email protected]>, [email protected] 
>(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    [email protected]

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 01:18:24 GMT
From:      [email protected]
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			[email protected]
					[email protected]   (SLIP)
--------------------------------------------------------------------
	Slip Slipping' away...		NeXT Mail Preferred
--------------------------------------------------------------------

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 01:19:07 GMT
From:      [email protected] (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 ([email protected]) wrote:

: In article <[email protected]>, [email protected] 
: (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:      [email protected] (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 <[email protected]> [email protected] 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:      [email protected] (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:      [email protected] (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 <[email protected]> [email protected] (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: [email protected] [email protected]
# 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:      [email protected] (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1323 implementation
In article <[email protected]> [email protected] 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:      [email protected] (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:      [email protected] (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?
[email protected]o.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:      [email protected] (Ayfer Karakaya Stump)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
In article <[email protected]> [email protected] (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
[email protected]

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 10:36:28
From:      [email protected] (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:      [email protected] (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 <[email protected]> [email protected] (Greg Skinner) writes:
>In article <[email protected]> [email protected] 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					[email protected]
Network Appliance Corporation 			(415) 428-5106

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 06:38:40 GMT
From:      [email protected] (Jonathan Stone)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
In article <[email protected]>, [email protected] (Ayfer Karakaya Stump) writes:
|> In article <[email protected]> [email protected] (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:      [email protected] (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

---------------------------------------------------------------------
[email protected]
Jim Hendry (student)
Rose-Hulman Institute of Technology

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 08:39:26 GMT
From:      [email protected] (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   ----------------------
                           [email protected]  
                             [email protected]      
           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:      [email protected] ("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:      [email protected] (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: <[email protected]>
>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 --    [email protected]
- Palo Alto, CA -
---
þ CmpQwk #UNREGþ UNREGISTERED EVALUATION COPY

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 10:50:58 GMT
From:      [email protected] (sparx)
To:        comp.protocols.tcp-ip
Subject:   help on ibm vm tcp-ip
[email protected]

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:      [email protected] (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?
In article <[email protected]>, [email protected] (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: [email protected]

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 16:29:08 GMT
From:      [email protected] (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 <[email protected]> Bernhard Strassl wrote:
-| In article <[email protected]>, [email protected] (Willard Dawson) writes:
-| |> [email protected] (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:      [email protected] (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 <[email protected]>

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 17:56:53 GMT
From:      [email protected] (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
[email protected]

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1994 18:27:26 GMT
From:      [email protected] (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 [email protected])

Thank you in advance,


Nam N.




-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 94 18:29:29 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (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:      [email protected] (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 ([email protected])

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 00:41:58
From:      [email protected] (Trent Stevens)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
In article <[email protected]> [email protected] (Jim Shankland) writes:
>From: [email protected] (Jim Shankland)
>Subject: Re: SLIP/PPP server - how to?
>Date: Fri, 21 Jan 1994 21:47:44 GMT
 
>In article <[email protected]> [email protected] (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  [email protected]


-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Jan 1994 21:05:03 GMT
From:      [email protected] (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:      [email protected] (Jim Shankland)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
In article <[email protected]> [email protected] (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:      [email protected] (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
 \ [email protected] \ 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:      [email protected] (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: [email protected]
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:      [email protected] (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:      [email protected] (Neal Howard)
To:        comp.protocols.tcp-ip
Subject:   Re: Mosiac for Winsock
Mayank Shah ([email protected]) 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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?
In article <[email protected]> [email protected] (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
[email protected]


-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 03:30:40 GMT
From:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)
In article <[email protected]> [email protected] (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
[email protected]



-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Jan 1994 07:32:24 GMT
From:      [email protected] (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:      [email protected] (John K Scoggin Jr)
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?
In article [email protected], [email protected] (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: [email protected]   |
|  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:      [email protected] (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   Re: Questio on voice ove
from [email protected] , we learn that:

>>Message-ID: <[email protected]>
>Newsgroup: comp.protocols.tcp-ip
>
>In article <[email protected]>, [email protected] (Barry
>Margolin) writes:
>|> In article <[email protected]> [email protected]
 (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.
>|> 
>|> [email protected]          {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 --    [email protected]
- Palo Alto, CA -
---
þ CmpQwk #UNREGþ UNREGISTERED EVALUATION COPY

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1994 17:18:46 GMT
From:      [email protected] ( 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:      [email protected] (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:      [email protected] ( )
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: SLIP/PPP server - how to?
In article <[email protected]>,

=
=>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  [email protected]
=

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 ([email protected]) 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: [email protected]
 
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 ([email protected]),
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
------------------------------------------------------------------------------
-- 
[email protected],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:      [email protected] (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: time sync protocol ?
In article <[email protected]> [email protected] (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:      [email protected] (Bruce A. Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE (IP Multicast)
Ran Atkinson writes:
> In article <[email protected]> [email protected] (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	       [email protected]
		      Computer Science Division
		  University of California, Berkeley

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1994 13:30:08 -0800
From:      [email protected] (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 [email protected] Sun Jan 23 11:14:35 1994
Date: Mon, 17 Jan 94 11:43:19 EST
From: Dane Bills <[email protected]>
To: [email protected]
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.						[email protected]
//  Canton, OH 44720			
//
//-----------------------------------------------------------------------

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1994 04:10:36 GMT
From:      [email protected]
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:      [email protected] (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Re: PC-NFS
 
In article <[email protected]>, James L. Hendry ([email protected]) 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
>
>---------------------------------------------------------------------
>[email protected]
>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:      [email protected] (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 <[email protected]>,
Dana B Bourgeois <[email protected]> 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 [email protected], 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:      [email protected] (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:      [email protected] (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 <[email protected]> [email protected] (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
[email protected]

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 04:33:09 GMT
From:      [email protected] (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:   [email protected]

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 05:03:59 GMT
From:      [email protected] (Ivan Leong)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for SMTP on Ethernet Network
Jens Kjerte ([email protected]) wrote:

> Richard Thiessen ([email protected]) 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: [email protected]  _OR_  [email protected]

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 06:03:21 GMT
From:      [email protected] (Stein-Aksel Basma)
To:        comp.protocols.tcp-ip
Subject:   Re: NetBIOS running on TCP
Parthiban Durai ([email protected]) 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:	[email protected]
//	Phone:	+47 78 95 07 45
//------------------------------------------------------------

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 94 19:11:34 PST
From:      [email protected]
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:      [email protected] (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Bidirectional SOCKET throughput
In comp.protocols.tcp-ip, article <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket/TCP/IP calls hang in the OS
In comp.protocols.tcp-ip, article <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (Matthias Urlichs)
To:        comp.protocols.tcp-ip,comp.os.386bsd.development
Subject:   Re: RFC 1323 implementation
In comp.protocols.tcp-ip, article <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (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
[email protected]
USC/Information Sciences Institute

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 16:36:49 GMT
From:      [email protected] (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   [email protected]






-- 
Chris Lloyd			Internet:	[email protected]
Manager, Production Systems	Bitnet:		[email protected]
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:      [email protected] (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
[email protected]

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1994 19:26:13 GMT
From:      [email protected] (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 <[email protected]>
To:        comp.protocols.tcp-ip, John Greene <[email protected]>
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:      [email protected] (Stefan Grefen)
To:        comp.protocols.tcp-ip,comp.os.386bsd.development
Subject:   Re: RFC 1323 implementation
In article <[email protected]>,
Matthias Urlichs <[email protected]> wrote:
>In comp.protocols.tcp-ip, article <[email protected]>,
>  [email protected] (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: [email protected]
>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
[email protected]		       Phone: +49-69-665270


-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jan 1994 21:17:11 +0000
From:      [email protected] (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:      [email protected] (Karl-Heinz Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing: KA9Q or PCroute?
In article <[email protected]>, [email protected] (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:      [email protected] (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
[email protected]


-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 94 01:56:33 GMT
From:      [email protected] (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

		[email protected]

	(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:      [email protected] (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 <[email protected]>,
Richard Bainter <[email protected]> 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
          [email protected]         |    [email protected]
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:      [email protected] (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              [email protected] - 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:      [email protected] (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:      [email protected]
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			[email protected]
					[email protected]   (SLIP)
--------------------------------------------------------------------
	Slip Slipping' away...		NeXT Mail Preferred
--------------------------------------------------------------------


-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 04:06:09 GMT
From:      [email protected] (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Hashing of IP addresses - summary of responses
In article <[email protected]> [email protected] (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    [email protected]

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 10:11:58
From:      [email protected] (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.)|
| [email protected]     | 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:      [email protected] (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    [email protected]
"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:      [email protected] (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:      [email protected] (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:  [email protected]        Uucp:  uunet!olsen!robert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 06:54:46 GMT
From:      [email protected] (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		[email protected]	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:      [email protected] (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: [email protected]   Voice: 703-739-5089   FAX: 703-739-0775

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 14:21:44
From:      [email protected] (Tomas Liljebergh)
To:        comp.protocols.tcp-ip
Subject:   Re: UNIX --> SAME PRINTER <-- Novell
In article <[email protected]> [email protected] (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: [email protected] (chris_lloyd)
>Subject: UNIX --> SAME PRINTER <-- Novell
>Message-ID: <[email protected]>
>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:      [email protected] (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:      [email protected] (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 [email protected]  
-- 

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 94 12:20:53 GMT
From:      [email protected] (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: [email protected]             |        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:      [email protected] (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: [email protected]

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:      [email protected]rd.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.

[email protected]
Iowa Network Services, Inc.
System Admin. Wyse 9000i


-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 94 15:01:25 GMT
From:      [email protected] (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: WOW!! Aint that cool
In article <[email protected]> [email protected] 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			[email protected]
>					[email protected]   (SLIP)
>--------------------------------------------------------------------
>	Slip Slipping' away...		NeXT Mail Preferred
>--------------------------------------------------------------------
>

Cliff

-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
[email protected]


-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 15:05:31 GMT
From:      [email protected] (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, [email protected] (Ehud Gavron) said:
EG> In article <[email protected]>, [email protected] (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:      [email protected] (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    [email protected]
I am not mad, wibble wibble, I love UNIX | Internet: [email protected]
                                         | UUCP:(US) uunet!inmos.com!antony

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 16:26:22 GMT
From:      [email protected] (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:      [email protected]
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?

In article <[email protected]>, <[email protected]> 
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: [email protected] (Ran Atkinson)
> Subject: Re: death to GOSIP?
> Message-ID: <[email protected]>
> Sender: [email protected]
> Organization: Naval Research Laboratory, DC
> References: 
 <[email protected]>
> Distribution: usa
> Date: Sat, 22 Jan 1994 03:16:35 GMT
> Lines: 28
> 
> In article 
<[email protected]> 
[email protected] (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
> [email protected]
> 
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:      [email protected] (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 :=(

[email protected]

(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:      [email protected] (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:      [email protected] (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 <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (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:      [email protected] (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
[email protected]


-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 18:47:10 GMT
From:      [email protected] (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                                 [email protected] 
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:      [email protected] (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 <[email protected]>
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
[email protected]
Cray Systems on contract to the European Space Agency

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 04:56:12 -0500
From:      [email protected] (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:      [email protected] (Alan M. Friedman)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Need help w/ Versaterm SLIP, MacTCP, etc.
In Article <[email protected]>, [email protected]
(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)
>[email protected]

    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   | [email protected]
           \_\_\_  \_                         | AppleLink:    D5620
                  \_\_\_                      | Compuserve:   72120,564
_____________________________________________________________________________

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Jan 1994 23:01:57 GMT
From:      [email protected] (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:      [email protected] (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:      [email protected] (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: death to GOSIP?
In article <[email protected]> [email protected] 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:      [email protected] (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
[email protected]

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 01:10:58 GMT
From:      [email protected] (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:  [email protected] 
--------------------------------------------------------------------

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 02:09:06 GMT
From:      [email protected] (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr Client
[email protected] (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....
  [email protected]


-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 94 10:31:10
From:      [email protected] (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: [email protected], [email protected]

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1994 07:59:54 GMT
From:      [email protected]
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: [email protected]
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:      [email protected] (B. Scott Bilas)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,alt.winsock
Subject:   Re: Minimal Telnet
In article <[email protected]> [email protected] (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 <[email protected]>|"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:      [email protected] (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 <[email protected]> [email protected] (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,  [email protected]

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 1994 11:37:11 GMT
From:      mgic <[email protected]>
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:      [email protected] (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:      [email protected] (Matthias Urlichs)
To:        comp.protocols.tcp-ip,comp.sys.sun.apps
Subject:   Re: OOB data questions (SunOS specific)
In comp.protocols.tcp-ip, article <[email protected]>,
  [email protected] (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: [email protected]
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:      [email protected] (Oliver Yehung Hsu)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP
M J HART ([email protected]) 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 
: * [email protected] * 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:      [email protected] (Oliver Yehung Hsu)
To:        comp.protocols.tcp-ip
Subject:   Re: How to FTP from an application
rajeev.dolas ([email protected]) 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:      [email protected] (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:      [email protected] (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 [email protected]" 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:   [email protected]
[email protected]       U.S. Robotics, Inc.            Support: [email protected]
[email protected]   Skokie, Illinois USA           Phone:   +1-708-982-5010

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Jan 94 15:04:25 GMT
From:      [email protected] (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 <[email protected]> [email protected] (Jerzy Tarasiuk) writes:
>>>>>> On 19 Jan 1994 12:48 MST, [email protected] (Ehud Gavron) said:
>EG> In article <[email protected]>, [email protected] (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:      [email protected] (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: [email protected]

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 94 15:26:20 GMT
From:      [email protected]
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 t