🚀 go-pugleaf

From: Feroz Ghouse 4S7FG/WU9N <FGHOUSE@LAX.WISC.EDU>
Date: Sun, 14 Jul 91 18:13 CDT
Subject: 

Please add me to your group
 


----
From: Kevin J. Rowett <kevinr@tandem.com>
Date: Sun, 14 Jul 91 16:21:14 PDT
Subject: FYI.. htonl and patent #4,956,809

From: rms@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.announce,gnu.gcc.announce,gnu.g++.announce,gnu.emacs.announce,gnu.misc.discuss
Subject: Patent on a standard-byte order for intermachine communication
Message-ID: <9107131607.AA14833@mole.gnu.ai.mit.edu>
Date: Sat, 13 Jul 91 09:07:45 PDT
Followup-To: gnu.misc.discuss
Lines: 46
Approved: info-gnu@prep.ai.mit.edu
To: info-gnu@prep.ai.mit.edu, info-gnu-emacs@prep.ai.mit.edu
To: info-gcc@prep.ai.mit.edu, info-g++@prep.ai.mit.edu

US patent number 4,956,809 covers using a single standard byte
ordering for transfer of data between machines whose normal byte
ordering is different.

Unless invalidated (by prior art from mid-1982 or earlier), this patent
prohibits the principal means for transfering data between disparate
types of computer systems.  For example, Sun is now being faced with
demands to pay royalties for NFS, which uses this method.  This
directly threatens the GNU operating system, since we were planning to
support NFS.  (It also threatens BSD.)

Here is an explanation of the communication problem, and of the
solution which this patent covers.

The memory of today's computers is divided into units called bytes.
Each byte holds a single text character, or a number from 0 to 255.
Each byte of storage has a unique address.  These addresses start at 0
and range upward.

When you need to represent a number in a range bigger than 0 to 255,
you need more than one byte.  For example, two bytes can hold a number
in the range from 0 to 65535.  Four bytes can hold a number in the
range from 0 to 4294967295.  This four-byte number might be held in
bytes 72, 73, 74 and 75--four consecutive bytes.

There are various options for distributing the value of the number
among the bytes.  In practice, most of today's computers use one of
two methods.  The "little endian" method is to put the less
significant figures in the low-numbered bytes.  The "big endian"
method is to put the most significant figures in the low numbered
bytes.  (These names come from "Gulliver's Travels".)

If you transfer a block of data from a big-endian computer to a
little-endian computer, preserving the order of the bytes, all the
multi-byte numbers will be scrambled.

The simplest way to communicate data between different computers is to
set up a convention for the ordering of the bytes in any multi-byte
number.  If the big-endian ordering convention is chosen, then
little-endian computers must reverse the byte order when they read and
write network messages.

This is exactly what is covered by US patent 4,956,809.

If you find prior art dated 1982 or earlier, please inform
league@prep.ai.mit.edu.



----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Mon, 15 Jul 91 11:38:42 EST
Subject: PA0GRI warning: invalid pointer

I found this in my logfile today, after minnie crashed on the weekend. The
pa0gri version is given at the bottom... [I'm using a binary from ucsd.edu]

Sat Jul 13 02:28:27 1991 134.130.45.2:1026 - open FTP
Sat Jul 13 02:28:38 1991 134.130.45.2:1026 - anonymous logged in, ID test
Sat Jul 13 02:29:32 1991 134.130.45.2:1026 - close FTP
Sat Jul 13 04:44:35 1991 - free: WARNING! invalid pointer (896E:0008) pc = 3b64:02d0 proc network

Sat Jul 13 04:44:35 1991 - free: WARNING! invalid pointer (942F:0008) pc = 3b64:02d0 proc network

Sat Jul 13 04:44:44 1991 - free: WARNING! invalid pointer (0673:ECC3) pc = 3b64:02d0 proc network

Sat Jul 13 04:44:44 1991 - free: WARNING! invalid pointer (058B:001F) pc = 3b64:02d0 proc network

Sat Jul 13 04:44:44 1991 - free: WARNING! invalid pointer (FF54:0070) pc = 3b64:02d0 proc network

Sat Jul 13 04:44:45 1991 - free: WARNING! invalid pointer (88A8:0008) pc = 3b64:02d0 proc network

Sat Jul 13 04:44:45 1991 - free: WARNING! invalid pointer (88A9:0008) pc = 3b64:02d0 proc network

Mon Jul 15 09:39:04 1991 - NOS v910618 (PA0GRI v1.7b) was started at Mon Jul 15 09:39:04 1991

Ideas? etc...

	Warren  vk1xwt.


----
From: karn@ka9q.bellcore.com (Phil Karn)
Date: Mon, 15 Jul 91 04:13:53 UTC
Subject: Re: FYI.. htonl and patent #4,956,809

Unbelievable. If there was ever an absurd software patent that needed to be
tossed out, this is it.

As for "prior art", I think the TCP/IP protocols themselves do this very
nicely. All of the multi-byte fields in both IP and TCP are explicitly
described as being in big-endian order, regardless of the byte order of the
machine running an implementation of these protocols. So not only NFS
"infringes" this patent.  So do all implementations of IP and TCP, and
related Internet protocols.

Fortunately, IP and TCP were around long before mid-1982. For example, see
RFCs 760 and 761, dated January 1980. These are earlier specifications of IP
and TCP than the current RFCs 791, 792 and 793, dated September 1983.  There
are many even earlier versions of the IP and TCP specs in the IEN (Internet
Experiment Note) series.

I, for one, will ignore this patent as described.

Phil


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Mon, 15 Jul 91 15:33:45 EST
Subject: Re: Flat ampr.org

> > > What is the "hostname" he forwards it to?
> > The hostname of the static mail gateway in Virginia.
> And then how does the mail get to you?  Do you connect to this gateway
> to read it, hoping the path between you and it is up at the time?

Yes! Seeing as I am now in Virginia, and one of my original assumptions
was that the mail gateways were static, unmoving, and stable, thus I
should be able to connect to it directly.
> 
> > Exercise #1: 5% of the ham TCP/IP sites have moved to
> > random parts of the world. Devise a method of routing that will allow
> > them to ttylink to each other. Assume a network of link layers exist for
> > this to be done: ax25, Ethernet, SLIP, Token ring, ROSE, Netrom etc.
> > 
> > Exercise #2: Modify the algorithm in #1 to scale from 5% to 100%.
> 
> Good exercises that need to be worked out.  When you first connect direct
> somewhere, that node should always route its packets for your IP address
> over the link you came in on (particular radio frequency).  Then you access
> a service to announce your IP address location. 

Which has to pass routing information onto EVERY TCP/IP site in the world,
so that EVERYBODY will be able to connect to you.

> That all should take less than 5 minutes.

This backbone must be amazing. What's it made out of?


> As you might see above, the idea I am thinking of is to keep your IP address
> and check in with a local node to have it send your IP address to the backbone
> gateways.  We just need to make sure that when any node receives an IP packet
> directly from the station transmitting to it, it will for that time always
> know to send packets for that IP address over that radio channel.  That gets
> you connectivity to that node (and all upper layer protocols).

But only to the nodes that it can hear. A routing protocol may eventually
pass the new route on to some TCP/IP machines, but I maintain that it is
nearly impossible to pass the new route information on to EVERY machine.
Even every `backbone' machine would be impossible.

The whole point of class-A,-B, -C networks and subnetting was to make
routing efficient. I don't understand why this should be thrown away.

	Warren vk1xwt.


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Mon, 15 Jul 91 15:59:25 EST
Subject: Re: Flat ampr.org

> > Which has to pass routing information onto EVERY TCP/IP site in the world,
> > so that EVERYBODY will be able to connect to you.
> 
> No, just those nodes along the path to your original location.  Upon seeing
> the misroute, they can then transmit the new reroute back up the path from
> which the misrouted packet came (towards the current routing of the IP
> address that sent it).

What about everybody else in the world who wants to route to me? At least,
EVERY backbone node in the world. Unless the inefficiency of someone in
New Jersey sending a packet, which goes to Canberra and back to Virginia
is tolerated.

> > This backbone must be amazing. What's it made out of?
> 1.544 megabaud links at 2.3 GHz and up and 10 megabaud links at 10 GHz and up.

I was trying to aim my method at what currently exists, assuming enough
people are running nos to form a real global network.

> > The whole point of class-A,-B, -C networks and subnetting was to make
> > routing efficient. I don't understand why this should be thrown away.
> 
> That is BETWEEN networks, e.g. between 44.X.X.X and 32.X.X.X, for instance.
> WITHIN a network, the schemes can be anything at all.

I'd still prefer it to be efficient, meaning broadcast & speed efficient.
I was kinda looking at 44.x.x.x as a class-A network with many subnets.

Anyway, I think we'll have to agree to disagree on this one.

	Warren vk1xwt.


----
From: gvdg@tophat.cdh.cdc.com
Date: Mon, 15 Jul 91 11:43:36 MDT
Subject: New(er er) NOS 910618

Hello All,
NOS 910618 1.7e is now on ucsd.edu and on wb3ffv xbbs systems.
I hope that finaly all tmpfile troubles are over. The tmpfile is gone
as Borland does well on creating/deleting those files in tc2.0.
A new module mkname.c is created and has __TMPNAM _TMPNAM and nkname
in it to create temporary files. It is nice to have so many conflicting
advices comming in. TC2.0 uses __TMPNAM (normaly in TMPNAM_TEXT in TC2.0)
By N1BEE TC2++ uses _MKNAME but on his last reviced revision it says
__MKNAME. Anyhow IT WORKS. The superfuous cleanup routine (Now i know
why they needed it !!!!!!) is gone. TC2.0 and TC2++ both can handle
the -zC_TEXT option, so that is in MAKEFILE with a MKNAME=mkname switch
to enable /disable it for other compilers.
Please no flames UNLESS you realy know it better and can prove i am the jerk
i am.
Watchdog is fixed back to 300 seconds.
Ftp login now gives back some comments if during login you just hit return.
(the famous " nothing hapens" mode)
Now it is getting time to go into the dock stages and do Bdales 30 point list
of things to do to satisfy the "community" with a """""release"""""
(I know one of his International users: me with 300 baud sending release
after release of BM to him. It has been more than 8 years now that i started
hacking on Phil's code. It starded with good old ax25 for the x820, still
being used here in Holland on the 6809 Flex systems. We have come a long way.)
Good luck with the (defenitlely not bugfree) code.
PS, version 900828 was the last version with the DNS in it. I am still thinkin
of doing it all over again but time ...... My unix system at home does a good
job on playing DNS so my hurries are over (sorry) I know the neccesety for
the rest as that is what i was fighting against.
Regards, Gerard.
-- 
Internet: gvdg@tophat.cdh.cdc.com       |     Gerard J van der Grinten
UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
Telephone: 0(+31)-70-3119703            |     Van Markenlaan 5
                                        |     2805 VL RIJSWIJK    Netherlands


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Sun, 14 Jul 91 01:01:57 EDT
Subject: The LAST of the TMP Puzzle


Well I will have to admit it was a good learning experience!! I found the
problem with the TMP file code. It was my fault (with the help of Gerard!).
In his latest version NOS_0618 1.7d he had added a tmpfile and a rmtmp
function. In Mike's note he made no mention of those functions. I took
out mkname and tmpname creating mkname.c (with makefile rules) but did not
take out the other two functions. Therefore NOS was using it's own tmpfile
function using the mkname.c code BUT - the important but - because it was
not using the BC tmpfile an fclose did not delete the files.

Anyone trying to compile 1.7d (in any compiler) should see this problem.
To correct the problem in 1.7d...

1. Take out ALL!!! references to temporary files in PC.C - this
   includes MKNAME,TMPFILE,TMPNAME,RMTMP - all function from
   MKNAME to the end of the file.

2. Follow Mikes  WED July 10th message

   a. create MKNAME.C
   b. Apply fixes to makefile and pc.tl

The message here is that any correction to the tmpfile function has to
be done internal to BC (as it is with Mike's code). Any attempt to
redefine tmpfile (with your own fopen) will fail because the file will
not automatically unlink at fclose. Before I found the above fix I was
attempting to see how I could delete the temporary files based on NOS
itself having opened them.

A global list of temporary file pointers and full file names 
could be updated in the NOS tmpfile function and a special close could
be called with the FP to unlink the file. The list would contain the
FP and full name of the file.

Better to do it in TC/BC the function is there.

One other thing - With the code working correctly (all of the above
fixes applied) I notice that when a TMP file is being created the disk
thrashes alot more than it use to (old compiler) This may not be noticeable
on a fast drive but on my st225 XT it does about 4 times as much movement
as before. It is like it is searching thru more than it should. It looks
like it should hit access the first time and then open the file. It takes
alot longer to do something like a local DIR because of this. Is it
possible that _tmpnum is not being remembered.

Sorry for all of the messages on this.

Doug


----