HDTenEightyP/NetNews huggingface dataset:
From: aep@icd.ab.com (Alexander E. Pensky)
Subject: Re: Question on bind-socket
Organization: Allen-Bradley Co., Highland Heights, OH
Date: Thu, 9 Apr 1992 15:19:41 GMT

In article <1992Apr8.191115.26347@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
> >|> 
> >|> Basically, SO_REUSEADDR lets you have two sockets with *similar*
> >|> local & foreign address bindings, but nothing will allow you to have
> >|> two *identically* bound sockets, and that is what you are trying to do.
> >
> >The constraint is two identical "connected" sockets not two identical
> >"bound" sockets.  See earlier posting on why the original code failed.
> 
> Sorry, this is not correct in BSD or SunOS.
> The second bind will fail whether or not SO_REUSEADDR is specified,
> even if it is specified for the correct (the second) socket.
> The only time you may have two sockets with exactly the same local and
> foreign addresses and ports is when they are both "brand new" and 
> completely unbound.

Sorry, Brian, this is not correct either.  If SO_REUSEADDR is specified,
you may have two sockets bound to the same local address, as long as their
remote addresses are different.  This is true if both are bound to the
same local address, but one has connected to a remote port and the other 
has not. It is also true when both are connected to two different remote ports.
Thus SO_REUSEADDR can be used in a client-server design when a client wants
to use several servers simultaneously, but would like to use the same local
port number for all the connections.

> 
> As a demonstration, I tried the first part of your suggested:

[example program deleted...]

Wrong demonstration.  At the time of the second bind(), both sockets
will have the same complete address, that is,

	Local=(127.0.0.1,12321), Remote=(*,*)

Better demonstration: After binding the first socket, connect() it to
some port that another program is listening on, _then_ try to bind() the
second socket.  The addresses will then be:

	Socket i: Local=(127.0.0.1,12321), Remote=(Somehost,Someport)
	Socket j: Local=(127.0.0.1,12321), Remote=(*,*)

and the second bind() will succeed.
	

 -----------------------------------------------------------------------------
 Alex Pensky    	(aep@icd.ab.com)		         (216)646-5211
 Allen-Bradley Company             747 Alpha Drive, Highland Heights, OH 44143
 -----------------------------------------------------------------------------
From: sblair@upurbmw.dell.com (Steven C. Blair "Unix Network Services")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: One physical wire, multiple logical networks question
Date: 9 Apr 92 14:51:40 GMT
Distribution: usa
Organization: Dell Computer UNIX Internetworking Services

In article <1992Apr09.133834.14574@mixcom.com>, xeee01@mixcom.com (Aniruddh Chawda) writes:
> 
> If different computers are attached to the same wire, but
> use different network addresses, is a router required
> so that they will talk to each other?

Not if you want to set the subnet masks very wide(255.255.0.0(example),
and do something really nasty like having one host do route advertising
for all the other networks, as well as doing a bunch of arp -s addr
to fake stuff out. A fairly normal thing to do to a class B network, when
*and only when* one needs to do some testing. Best way is to take a
machine, put 2 interfaces in it, and fake it out(UNIX/routing information)
via the second interface.

good luck,

-- 
Steven C. Blair    DELL UNIX NETWORK OPERATIONS        sblair@dell.com
==========================================================================
"One form to rule them all, one form to find them, one form to bring them"
	"all and in the darkness rewrite the hell out of them."
                       -- Sendmail ruleset 3 comment from DEC
Newsgroups: comp.protocols.tcp-ip
From: smd@uunet.ca (Sean Doran)
Subject: Re: WHOIS at nic.dn.mil
Organization: UUNET Canada
Date: Tue, 7 Apr 1992 07:17:30 GMT

jjm13@po.cwru.edu (Jeff Murphy) writes:

>Try it *without* the .CA on the end.  Those sites are listed as UBC and SFU 
>in the nic database, *not* as UBC.CA and SFU.CA.

Close, but this is not quite what was being looked for.  The records
that one can get with "whois ubc" or "whois sfu" are NET ones, not DOM
ones, which is what was being searched for.  The NET records will only
tell you about 137.82.0.0 (NET-UBC) and 142.58.0.0 (NET-SFU), and not
about the domains ubc.ca or sfu.ca.

The NIC does not list sites under CA-DOM in the whois database, but
(as with all valid top-level-domains) lists a DOM record for CA.

Authoritative information about any registered domain in .ca can be
found for anonymous ftp at cs.ubc.ca:/ca-domain,
relay.cdnnet.ca:/ca-domain, clouso.crim.ca:/CAnet/ca-domain, and
ftp.cs.utoronto.ca (ftp.cs.toronto.edu) in /ca-domain.  We also mirror
this information, and make it available at ftp.uunet.ca:/ca-domain.  

	Sean.
Newsgroups: comp.protocols.tcp-ip
From: mark_silbernagel@mentorg.com
Subject: Re: tftp time out booting X terminal
Date: Tue, 14 Apr 1992 23:07:00 GMT
Organization: Mentor Graphics Corporation



In deep, dark recesses of memory I seem to recall that *some* tftp daemons had
a sort of security check where too many requests in a short period would cause
tftpd to stop for a while. The assumption was that it was an attack across the
net.

It was discovered to be a pain when they found that the new, fast workstations
could ask for that many in a very short period of time.

Or, maybe it was inetd protecting tftpd with that mechanism.

You get the idea.

If you're wondering, I'd recommend asking the server's vendor.

Mark
From: vlachopo@nunki.usc.edu (Panagiotis Vlachopoulos)
Newsgroups: comp.protocols.tcp-ip
Subject: SRP - CRC
Date: 7 Apr 1992 20:47:13 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: nunki.usc.edu
Summary: Trivial but valuable...
Keywords: SRP - CRC


Hi Netters,
I am searching for two things:

(1)     A simulation of the Selective Repeat Protocol written in ANY
computer language. It will be used to calculate and plot the efficiency
of the protocol vs. buffer size. (I know it's in Tanenbaum, but I'd
rather have it in anything else than Pascal).
(2)     A piece of code that calculates CRC's for a given generator.

As I'm not reading this group I would like to have any responses
sent to panosv@theseas.ntua.gr
Thanx in advance :-)
From: k@hprnd.rose.hp.com (Steve Kao)
Date: Wed, 8 Apr 1992 15:21:40 GMT
Subject: Re: tcp printer servers
Organization: HP Roseville Networks Division
Newsgroups: comp.protocols.tcp-ip

Why not get an HP LaserJet with the appropriate TCP/IP card?  You can
then plug the printer directly onto the TCP/IP network.

- Steve Kao
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Newsgroups: comp.protocols.tcp-ip
Subject: Negative ping times
Date: 16 Apr 92 23:04:27 GMT
Article-I.D.: mindlink.11470
Organization: MIND LINK! - British Columbia, Canada

What is it that causes ping to report negative times like the following?

PING 128.189.1.2: 56 data bytes
64 bytes from 128.189.1.2: icmp_seq=0. time=-500. ms
64 bytes from 128.189.1.2: icmp_seq=1. time=-560. ms
64 bytes from 128.189.1.2: icmp_seq=2. time=-800. ms
64 bytes from 128.189.1.2: icmp_seq=3. time=-580. ms

----128.189.1.2 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)  min/avg/max = -800/-610/0

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada
From: ljm@Babyoil.ftp.com (leo j mclaughlin iii)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: LPD
Date: 31 Mar 92 19:24:41 GMT
Article-I.D.: leather-.920331132441
Reply-To: ljm@ftp.com
Organization: FTP Software, Inc., Wakefield, MA
Nntp-Software: PC/TCP NNTP

>I have the BSD sources and I do not see it to be very different from the
>protocol (if you dare to call it that) descirbed in RFC 1179. I am curious
>what exactly you had in mind when you said that the RFC is tuned to help
>PCs....

RFC 1179 allows hosts to send the control file before the data file.  This
helps any client or server with insufficient stable storage to cache data
files while waiting for the control file to arrive.  This also helps any
client which does not store text files in a format that allows it to know
how long the file will be when translated into UNIX standard EOL format.

The new RFC improves on some of the mechanisms described in RFC 1179, most
notably answering the complaints of those who wished the protocol to
explicitly determine if an old or new LPD server was being used.

enjoy,
leo j mclaughlin iii
ljm@ftp.com
Newsgroups: comp.protocols.tcp-ip
From: ratlifc@prometheus.stu.rpi.edu (Christian A. Ratliff)
Subject: Re: 3B2 client-server latency problem
Reply-To: ratlifc@eclipse.its.rpi.edu
Distribution: usa
Date: Fri, 17 Apr 1992 16:52:57 GMT

In article <1992Apr17.150957.17268@mixcom.com> Dean.Roth@mixcom.mixcom.com  
(Dean.Roth) writes:
}
}I'm new to an organization that has a server running on
}a 3B2.  I've seen a large latency between when data is
}sent by a client and when the read in the server completes.
}
[stuff deleted]
}I've never worked with a 3B2 before. Is this behavior
}characteristic of this machine?  The software is using 
}the socket API.  Thank you.
}


  Yeah. This is _very_ characteristic since every packet has to pass from  
kernel space into user space and then into kernel space and then into user  
space again while going through the etherd. It's thoroughly annoying for  
those of us who want fast networking and use 3B2s.


--------
Christian A. Ratliff               Rensselaer Polytechnic Institute
ratlic@rpi.edu                     113 9th St.  Troy, NY 12180
ratlifc@eclipse.its.rpi.edu        <NeXT Mail Accepted at all addresses>
Newsgroups: comp.protocols.tcp-ip
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: default address mask selection for a point-to-point network?
Organization: Morning Star Technologies
Date: Wed, 8 Apr 1992 16:22:58 GMT

In RFC-1122 section 3.2.2.9 we see

  (b)  Until it has received an Address Mask Reply, the host SHOULD
       assume a mask appropriate for the address class of the IP
       address, i.e., assume that the connected network is not
       subnetted.

The implementation is obvious for a connection a broadcast network
like an Ethernet - just derive the mask from the IP address of the
interface.  But a point-to-point network connection (PPP, SLIP, or
whatever) has two IP addresses, one each for the "local" and "remote"
ends of the link.

From which address (local or remote) should a host infer the default
subnet address mask for a point-to-point network?

(My opinion: it should look at the remote address, because that's
where it looks for routing decisions.)
Newsgroups: comp.protocols.tcp-ip
From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
Subject: terminal concentrators
Organization: W S Rupprecht Computer Consulting, Fremont CA
Date: Wed, 8 Apr 1992 10:20:26 GMT

I'm looking for the measured throughput figures for various terminal
concentrators.  How many full-speed connections can the various
vendor's TCs handle before 1) output slows down and 2) input gets
dropped?  I saw several reviews of various router's throughputs.
Hopefully there is something similar for TC's.

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511
Newsgroups: comp.protocols.tcp-ip
From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: Screen Sharing via TCP/IP
Organization: University of Waterloo
Date: Wed, 15 Apr 1992 20:37:55 GMT

 car@public.BTR.COM (Carlos Rimola-Sarti  car@btr.com) writes:
>
>I am looking for a "screen sharing" program that runs on an PC using
>TCP/IP (e.g. FTP Software).  Something along the lines of Carbon Copy
>would do.  The only packages that I have heard of all use serial lines.
>

FTP to sunee.uwaterloo.ca and get pub/wattcp/telnetd.zip.  It provides
VT100 or VT200 emulation for remotely controlling your pc.  Since
both the local and remote keyboard can enter keystrokes and watch
the screen, this is a good solution for remotely controlling networks
or providing consulting.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards
From: mike@gordian.com (Michael Thomas)
Subject: LPR on a terminal server, Opinions?
Reply-To: mike@gordian.com (Michael Thomas)
Organization: Gordian; Costa Mesa, CA
Date: Thu, 9 Apr 1992 23:20:11 GMT


   I am considering writing a LPRd for a terminal/printer server (from
 RFC 1179).  The obvious win with implementing LPR within a terminal server
is that no special host software is needed. The loses, however, appear to be
many. The basic problem is that LPR expects another unix system on the remote
side with spooling capabilities, and various output filters. A terminal
server is a limited environment though (how many have you seen with 100 meg
drives? ;-).
   What I am interested in hearing is whether some of the options which
LPR supports are dispensable or work-aroundable on the server/host side:

   1) The control file, seems to come second (after the data file).
      On a terminal server, there isn't any spool area, and this
      means that a terminal server would have to ignore it. 
 	a) Is there a way to get the control file to come before the
	   data file, and if so how.
	b) If (a) cannot be worked around, how serious a limitation would
	   this be? (Ie no server generated banner pages, none of the
	   various filtering options, etc)
   2) Assuming (1) can be worked around, there are several options which
      would _never_ be implemented on the terminal server (Troff-X, DVI,
      plot/raster filters etc). Would an LPRd which lacked these features
      be a serious hinderance? Would it be possible to work around these
      by having the host side (ie LPR side) pre format the data stream and
      send it to the LPRd raw?

Comments greatly welcomed. 
-- 


		Michael Thomas	(mike@gordian.com)
	"I don't think Bambi Eyes will get you that flame thrower..."  
		-- Hobbes to Calvin
		USnail: 20361 Irvine Ave Santa Ana Heights, Ca,	92707-5637
		PaBell: (714) 850-0205 (714) 850-0533 (fax)
From: frank@rniwi.rni.sub.org (Frank Mogaddedi)
Newsgroups: comp.protocols.tcp-ip
Subject: NIS, broadcast, etc. Need help
Summary: Need help w/ setting up networks
Keywords: NIS, YP, broadcast - help
Date: 8 Apr 92 08:09:41 GMT
Organization: Frank's Wild Unix

Dear World,
I hope this is the group to post to.

I have the following situation:
I have one Token-Ring Network, running Novell3.11
Connected to that are 3 *nix-Boxes only capable of ethernet-connections,
integrated into the TR thru 3 Novell-3.11 Routers.

ftp, rlogin, telnet, nfs etc. all work fine over the net. I currently
have the nets set up as 4 different class A Networks, 1.0.0.0, 2.0.0.0
3.0.0.0 and 4.0.0.0. I feel this is OK, since we don't plan to go
outside of the office-buildings to the world.

Now my problem: I would like to only have one NIS(YP) Server.
How can I do this? How do I convince th other machines to look beyond
their own net? What has the broadcast-address to do with it?

I have tried to read the manuals concerning addresses, broadcasts etc.,
but I don't understand them fully.

I can change the IP-Addresses, if necessary, but I understand that I still
need subnetworks, since the novell-router doesn't do what I hav been said
is called 'source-routing' on ethernet..

Anybody out there who can help?

Thanks in advance
	Frank Mogaddedi
-- 
+-----------------------------------------------------------------------------+
| e-mail: frank@rniwi.rni.sub.org | Disclaimer: "Read my lips" (George Bush)  |
|	  Beauty is only skin-deep, but ugliness goes clean to the bone	      |
|			Maybe life is but a nightmare?			      |
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: danony@aix.rpi.edu (Yaron Danon)
Subject: Re: Print PCL with NCSA or Waterloo LPR (Help)
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: Tue, 7 Apr 1992 18:06:56 GMT

In article <1992Apr7.161705.27702@watserv1.waterloo.edu> eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
>danony@aix.rpi.edu (Yaron Danon) writes:
>
>>I conclude that both NCSA and Waterloo LPR can not send binary files only 
>>text files or postcript files which are actually text files.
>>
>
>The problem is with the protocol.  The LPR clients don't try to interpret
>the data, but the server probably kills the job when it sees a binary 0 come
>through.  The LPR protocol is not well suited for non-text printing.
>
Today I did some more tests; NCSA LPR with the -l option can send a PCL
file to a SUN and the sun then spools it to the PC-XT with NOS-LPD. This
works fine but when I LPR directly to the XT NOS-LPD get stuck. So it 
seems that the LPR and NOS-LPD do not have a matching protocol.

Is there anyone who setup a PC as printer server and prints PCL and text,
I would like to know how ?

Thanks, Yaron

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: aoelked@kirk.msoe.edu
Subject: Re: KA9Q as a router - help!
Reply-To: aoelked@kirk.msoe.edu
Organization: Milwaukee School Of Engineering, Milwaukee, Wisconsin
Date: Sat, 11 Apr 1992 17:13:31 GMT

In article <9204101518.AA11454@wshs.mi.org>, joot@wshs.mi.org (Joseph Wisdom) writes:
>comp.protocols.tcp-ip.ibmpc
>
>	We are presently using KA9Q on an IBM-PC to do routing of TCP/IP
>packets into and out of a small Unix network.  The current set up that
>we use fails miserably, if a packet length of more than 1006 bytes overall
>is encountered.  Do you have any suggestions, or anywhere where a version
>of KA9Q specifically taylored for routing could be obtained?
>
>	Please E-mail only, as there is normally no access to this group
>here.
>					-jw
>
>					<joot@wshs.mi.org>

	Could someone please also post a source (if something
like this actually exhists).


Dan Oelke                                              AOelkeD@kirk.msoe.edu
Academic Computer Services Department        Milwaukee School of Engineering
       The opinions within are mine and no-one else may claim them.
----------------------------------------------------------------------------
  VAX/VMS is like sex - if you've tried it, you can't get along without it,
     if you haven't you really have no idea what the fuss is about.
From: donp@novell.com (don provan)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re:  PKTMUX issues
Date: 6 Apr 92 07:13:54 GMT
Organization: Novell, Inc., San Jose, California

In article <9204032317.aa22555@louie.udel.edu> RAF@cu.nih.gov (Roger Fajman) writes:
>Is there any inherent reason why it can't be made to work if the
>different TCP/IP stacks have different IP addresses?

That is, after all, the standard way to address IP packets to
different IP implementations.  I think the packet driver community has
been blinded by the fact that the two implementations in this case
happen to be running on the same hardware.

I was just thinking about this solution over the weekend.  I can't
imagine it would take more about an hour and a half to code this into
pktmux.  Just have pktmux present different virtual packet drivers,
each one delivering packets addressed to a different configured IP
address.  Iron a couple of details about broadcasts and ARP and you're
in business.  Can't RARP, of course, since RARP depends on a
one-to-one mapping between hardware address and IP address, but this
type of configuration would probably too complicated for normal RARP
or BOOTP to be much help anyway.

>Admittedly that's wasteful of addresses, but would it work?

It's no more wasteful than the fairly typical practice of giving two
different PCs in the same office two different IP addresses.

						don provan
						donp@novell.com

p.s.  Does this mean that we don't have to have weekly discussions any
more about how impossible this problem is?
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: mikeod@itx.isc.com (Mike O'Donnell)
Subject: Is there a FAQ for this group?
Summary: WANTED: FAQ
Keywords: FAQ
Organization: Interactive Systems Corporation, Boulder, CO
Date: 13 Apr 92 16:27:19 GMT

Is there a FAQ for this group.  If so would someone
please e-mail a copy.

Thanks


--
Mike O'Donnell                   |
INTERACTIVE Systems Corp.        | Tel: (512) 343-0376 Ext. 119
9442 Capital of Texas Hwy. North | Fax: (512) 343-1414
Arboretum Plaza One, Suite 700   | Net: mikeod@itx.isc.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: ralph@swmerc.rain.com (Ralph Merwin)
Subject: Re: PCRoute with EtherCard PLUS Elite
Organization: Merwin Software Services, Inc.
Date: Thu, 16 Apr 1992 22:34:36 GMT

In article <1992Apr16.072009.407@swmerc.rain.com> ralph@swmerc.rain.com (Ralph Merwin) writes:
>
>Has anyone gotten PCRoute to work with the EtherCars PLUS Elite boards?
>I have the 8-bit board, and have tried using the builtin driver, and
>tried using a packet driver configuration with both the wd8003e.com
>driver and the 8003pkdr.exe from SMC (which seems to cause the board to
>lose it's configuration sometimes).

Well, to followup my own posting, here's what I found.  Turns out that
the Elite boards can be setup with either the ezsetup program or the
setup menu in the diagnose program, but the configuration is saved in
NVRAM only by the ezsetup program.

The reason that I tried to use the packet driver is because I thought
PCRoute's builtin WD driver wasn't able to talk to the Elite board,
because its configuration changed when I moved the board into the router.
After talking to SMC tech support and learning of the setup/save bug, I
retried using PCRoute's builtin driver after using szsetup.  Works like
a champ...

FYI, be aware that the older WD8003e boards allowed you to disable the
interrupt line as well as selecting the IRQ level.  The Elite board lets
you select the IRQ, but doesn't seem to allow you to disable the interrupt
line.

Ralph
-- 
---------------------------------------------------------------------------
Ralph Merwin              ralph@swmerc.rain.com              (503) 526-8647
GT6+ "Rustbucket from Hell"     DoD #0547        FJ1200 "Attitude Adjuster"
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: khindria@maccs.dcss.mcmaster.ca (Vivek Khindria (CSU))
Subject: 3c503 card with BW and 3+share 1.3
Organization: McMaster University, Hamilton, Ontario, Canada.
Date: Wed, 8 Apr 1992 20:48:30 GMT


    This is an obscure request...but....

	Has anyone combined the BWsoftware with 3+share 1.3 so that
 
   both drivers share the 3c503 card?   If so, please email your 

  suggested configuration.  I am close to moving to another package for

  telnet service.


   Vivek Khindria
   McMaster University
   Hamilton, Ontario, Canada
From: sjm@Miles.COM (Scott Mark)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Need info on packet driver.
Date: 14 Apr 92 19:55:06 GMT
Article-I.D.: Miles.1992Apr14.195506.15136
Organization: Miles Inc., Diagnostics Division, Elkhart, IN

I've got PC-kermit running fine, and I've got the 3C503 packet driver that
Bob Clements wrote, but I need more information about the driver.

Does anyone have a simple C source program that shows how to send and
receive packets from this driver?

IP packets or Ethernet packets are fine.  I'd sure like to get ahold
of the "packet driver spec" that Clements describes in 3C503.not, but
even something that shows how packets come in and out would be enough.

I'm working to port my NFS/RPC/XDR client program to a PC.  No, I don't
expect to be able to set the thing up as transparently-mounted drives.  I
just want to be able to copy files back and forth to a server, and use
RPC to tell another server what to do with 'em.

Any hints would be much appreciated.

Scott Mark
sjm@miles.com	sjm@miles.miles.com