Date: Wed, 14 Apr 93 04:30:10 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #98
To: tcp-group-digest
TCP-Group Digest Wed, 14 Apr 93 Volume 93 : Issue 98
Today's Topics:
conferencing and reliable stream service
Conferencing unrei liably ...
Loosing 420-430 band?
Networking Code / Linux
Porting to other systems
Thoughts on 108e (2 msgs)
Trenton Computer Fest (TCF)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Wed, 14 Apr 93 05:28:59 GMT
From: ki6cq@w6ue.caltech.edu
Subject: conferencing and reliable stream service
To: tcp-group@ucsd.edu
I seem to remember a long time ago, someone was experimenting on a
udp based conference system.
It seems to me that order of packets is not important in conferencing in
non-emergency situations. I'm fairly smart, and can figure out the lines
are backwards, etc...
It seems that relaxing the requirement of an ordered stream would speed
up communications on a noisy channel considerably. For that matter so
would some sort of multicast PACSAT like arrangement.
I think with udp you lose 100% delivery, that might be a problem. Is ther
a protocol that gives you retries and acks, but does not try to guarantee
a stream's order?
73 de Paul KI6CQ
------------------------------
Date: Wed Apr 14 12:42:23 1993
From: iiitac@pyr.swan.ac.uk
Subject: Conferencing unrei liably ...
To: tcp-group@ucsd.edu
There are some proper protocols for it, unfortunately when I was
playing with this stuff nobody told me. I settled for a mixture
of things. Lines people say are broadcast udp packets. They are
sequentially numbered (I used the NOS Clock). If a frame is detected
missing a station sends a query packet asking for a list of lines and
waits for them, if it gets no reply it waits 10 seconds and tries again
etc..
There were two things it didn't do properly. I never got around to polling
- so each station would say I last sent message xxxx in case someone lost
the last one, and because often everyone loses the same frame it went nuts
because everyone at once said 'give me number xxxx'. I think that would have
needed a random timer before the query, and if the answer appeared in the
time then don't ask.
It is possible to do and you don't really need to lose the ordering you can
just hold lines that don't have predecessors, or even insert them in the right
place as they come in.
Alan
------------------------------
Date: Tue, 13 Apr 93 07:59:18 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: Loosing 420-430 band?
To: tcp-group@ucsd.edu
I've been vacationing for the last week and a half, and I came home to
find this e-mail message from my partner-in-crime, KA7OEI. To give you
all a bit of backround, to get data to and from the Utah Backbone, we
requested 4 70cm freqs be co-ordinated, two near 421, two near 441.
John Lloyd is the Utah frequency co-ordinator. (one person, not a
committee) Is this guy up-in-the-night, or what? Does he know something
none of the rest of us know?
--------------BEGIN INCLUDED MESSAGE------------
In response to John Lloyd's statements to the effect that 420-430 Mhz WILL
be removed from amateur use "soon" I posted the following on the AMRAD
BBin Virginia:
Date: 04-11-93 (04:50) Number: 210 / 210
To: ALL Refer#: NONE
From: CLINT TURNER Read: (N/A)
Subj: LOSING 420-430 MHZ? Status: PUBLIC MESSAGE
Conf: MAIN BOARD (0) Read Type: GENERAL
Our packet radio group (UPRA: Utah Packet Radio Assoc.) is in the
process of upgrading the local packet radio network (i.e. 9600 baud+
interties, 1.5 mbaud backbones, etc.) and we requested coordination of
some 70cm frequencies for the of the "low speed" (9600 baud) links.
Specifically, some of the frequencies we requested coordination for are
in the 421 Mhz area.
In this area, the ONLY things in that frequency range include a handful
of links and the input to the local ATV repeater (426.25).
When we requested some frequencies, he stated that while there was
plenty of room in the 420-430 Mhz frequency range, THIS frequency range
was soon to be removed from amateur use and that he would NOT advise
investment in any equipment for that frequency range and thus, did NOT
coordinate any frequencies in that range.
As long as I can remember, I have heard "rumors" about how these
frequencies (and MANY others) would be soon "taken away" from amateur
use (alas, 220-222 Mhz...) and I DO remember the beginning of the "Line
A" exclusion for 420-430 Mhz, BUT I have spoken to several fairly
well-connected amateurs who would have certainly seen (or heard of) any
serious moves on this frequency range.
The coordinator (who himself works for a large local telecommunications
company) provided copies of the FCC part 90 sections pertaining to the
low-level U.S. useage of 420-430 mhz in the Detroit, Cleveland and
Buffalo, NY area, but NO documentation pertaining to any "official"
moves on these frequencies.
MY QUESTION: Can ANYONE point me to any "official" or authoritative
source that could be the source of this information? Certainly I
understand his concerns about the outlay of the scarce amateur resources
on frequencies if they, in fact, are soon to be "revoked" but, in fact,
is such work actually pending? Please point to "authoritative" sources,
not the "I heard somewhere too that..." type of information. If this
"reallocation of resources" is, in fact, still "years away" if the "use
it or lose it" philosophy is REALLY a valid one, then shouldn't we be
ENCOURAGED to use it? If such bona-fide uses can be documented when
those frequencies are "under the gun" won't they be ammunition for our
cause? Even if we eventually were to lose those frequencies, I believe
that AT LEAST some expendature of our limited resources would be
well-spent in preservation of some of our "best" spectrum...
Any information would be greatly appreciated.
----------------------------------------------------------------------
Clinton C. Turner, KA7OEI Salt Lake City, Utah
Internet: clint@uugate.aim.utah.edu
AMPRNET: ka7oei@uugate.wa7slg.ampr.org
MSYS: ka7oei@wb7ulh
For context, find the summary I did of the UPRA meeting, somewhere else
in the message list...
Clint.
------------------------------- CUT HERE -------------------------------
Clinton C. Turner (KA7OEI) 'Me thinks, therfores
Amprnet - ka7oei@uugate.wa7slg.ampr.org [44.40.1.193] me is'
- ka7oei.ampr.org [44.40.1.12]
Internet - ka7oei@uugate.aim.utah.edu [128.110.45.34]
ampr.org<>internet gateway system
---------------END OF INCLUDED MESSAGE------------
Comments?
Marvin Match KA7TPH
------------------------------
Date: Wed Apr 14 12:57:35 1993
From: iiitac@pyr.swan.ac.uk
Subject: Networking Code / Linux
To: tcp-group@ucsd.edu
The current 0.99.7 and 0.99.8 network code is fairly solid. I'm using it for
a multiuser machine on the internet running a BBS as well as other things
and with an uptime in days.
The big problem is the lack of SLIP support. With SLIP you can run KA9Q on your
unix box and use slip to hook KA9Q to the kernel tcp/ip via a serial port. Thus
you effectively get a router between you and the radio net, with its own
address and just happening to be on the same computer. That way you can
retire your XT and use it either as a box to put a new motherboard in or as
a lab power supply.. 8-)
When the new TCP/IP code appears (its one of those all singing all dancing
new mega improved erm no its not finished yet releases) it should have limited
kernel AX.25 support - for TCP/IP but only over AX.25 UI frames. I'd think
that it would be easy to add this layer of support to 386BSD SLIP too, since
it's just a new form of ARP frame and a slightly odd packet header. Even the
slip encoding/decoding is the same.
Until then I think the real solution is probably WAMPES. I'm running a port of
AmigaNOS because I happened to feel like porting it to see if it worked.
With either 386BSD or Linux you are unlikely to be dissappointed. KA9Q under
Unix isn't the ideal solution but you no longer spend all day trying to get
8K more base memory and having regular crashes when you run out.
You also get to use your computer at the same time.
Alan
------------------------------
Date: Tue, 13 Apr 93 14:23:30 +0100
From: Michael Chace <mikec@praxis.co.uk>
Subject: Porting to other systems
To: Alan Cox <iiitac@pyr.swan.ac.uk>
>>>>> Regarding Porting to other systems; Alan Cox <iiitac@pyr.swan.ac.uk> adds:
Alan> I've already started breaking NOS up under Linux, and inserting
Alan> segments of 'real' applications by routing packets through to
Alan> the real host tcp/ip layer. Its effectively much of what Wampes
Alan> also tries to do.
In case readers didn't know, Dieter DK5SG's latest update to
WAMPES supports 386BSD. I have it running on my machine at
home and it seems fairly stable. All the utilities also work
OK on 386BSD
bbs - The DK5SG BBS, much like any other mailbox. Also capable
of forwarding mail and being forwarded to by other BBSes.
convers and conversd - The convers round-table server and clients.
etc.
WAMPES is in hamradio/packet/tcpip/incoming on UCSD.EDU. Don't
forget to pick up the latest patchkit for it too!
Mike (G6DHU)
------------------------------
Date: Wed, 14 Apr 93 10:17:12 +1000
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Thoughts on 108e
To: karn@qualcomm.com (Phil Karn), crompton@NADC.NADC.NAVY.MIL,
In atricle by Phil Karn:
>
> I've got another idea. Now that I've made NOS's API very similar to
> that of Berkeley UNIX, how about porting the bigger applications
> (particularly the mailbox) from NOS to 386BSD?
>
> And maybe, just maybe, people would discover all of the nifty network
> applications that already exist under 386BSD, like sendmail and the
> domain name server, and not reinvent them...
Sounds good to me :-) 386bsd would need an AX.25 layer to do BBS forwarding...
Warren
------------------------------
Date: Tue, 13 Apr 93 22:09:21 EDT
From: Mike Gallaher <mg@bds.bds.com>
Subject: Thoughts on 108e
To: tcp-group.;@bds.bds.com
> Sounds good to me :-) 386bsd would need an AX.25 layer to do BBS
> forwarding...
It's much easier to use a separate PC running NOS as a gateway;
even an XT that's good for nothing else can do this.
This way each machine does what it's good at.
I've chosen Linux for a number of reasons, but primarily that
it takes MUCH less disk space. I don't know how it compares
in other areas vs. 386bsd, but it's a religious question in
some circles. I've fit a usable Linux configuration in
20MB of disk on a 4MB 386DX20. That's not all that expensive,
less than $500.
The catch is that the Linux networking code is unusable as yet.
Any Day Now this will get better. Really.
I think there is a place for some sort of BBS-like server
in NOS. It allows AX.25-only users to get to the TCP/IP
hosts via telnet, and to download files, etc. There should
be quite a few such access points in any network, but there
don't have to be that many full-blown servers (DNS, archie, etc.)
that would be better run under an operating system.
Also, ftp is useful even on a gateway for updating config files.
Mail forwarding is indeed the prime candidate for migration
to a server machine, as is converse. These happen to
contribute the most to NOS's instability (perhaps running
a close third is the DNS).
------------------------------
Date: Tue, 13 Apr 93 17:02:17 EDT
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Trenton Computer Fest (TCF)
To: nos-bbs@hydra.carleton.CA
Just a quick note to remind you that the Annual Trenton Computer Fest
is this coming Saturday/Sunday - April 17,18. We will have a room in
the Math Sciences building for the day, with general discusssions on
BBS's, TCPIP, and Netrom. I will have disks there with the latest NOS
(JNOS) source and executables and docs for those who need it. The above
discussion groups will only be on Saturday from approximately 10AM to
4PM and we may go to dinner afterwards.
If you have questions about TCP/IP, or packet in general I am sure there
will be plenty of assistance for you. Also it is a great opportunity to
meet other TCP'ers.
If anyone needs directions let me know.
Oh yes I forgot, Those who are veterans of TCF will bring your umbrella.
Those who are not make sure you do, because as usual the forecast for
Saturday is RAIN!!
Doug
------------------------------
End of TCP-Group Digest V93 #98
******************************
******************************