| |
ZL3AI > APRDIG 06.06.03 15:02l 237 Lines 10305 Bytes #999 (0) @ WW
BID : 1427-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 31, 1/8
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0IUZ<DB0GOS<DB0EEO<DB0RES<ON0AR<
ZL2BAU<ZL3VML
Sent: 030605/1332Z @:ZL3VML.#80.NZL.OC #:1723 [Chch-NZ] FBB7.00i $:1427-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, May 31, 2003.
1. Re: APRS Internet System Design Philosophy
2. Re: APRS Internet System Design Philosophy
3. Re: Coverage Map
4. Re: APRS Internet System Design Philosophy
5. Re: APRS Internet System Design Philosophy
6. RE: APRS Internet System Design Philosophy
7. Email Line Length
8. Re: Coverage Map
9. RE: Broadband on Power --City(not FCC) enforces radio law and busts CBer
10. raw frames
11. Re: Email Line Length
12. RE: APRS Internet System Design Philosophy
13. Re: raw frames
14. RE: APRS Internet System Design Philosophy
15. findu.com & TinyTrak3
16. Re: raw frames
17. Re: findu.com & TinyTrak3
18. Re: findu.com & TinyTrak3
19. Re: findu.com & TinyTrak3
20. Re: findu.com & TinyTrak3
21. Re: findu.com & TinyTrak3
22. Re: callsign server
23. Re: findu.com & TinyTrak3
24. Re: Email Line Length
25. Re: callsign server
26. APRS in Germany
27. Re: APRS Internet System Design Philosophy
28. Re: Email Line Length
29. Re: APRS Internet System Design Philosophy
30. APRSdos problem
31. Re: findu.com & TinyTrak3
32. Re: APRS Internet System Design Philosophy
33. D700 *& APRS
34. Re: findu.com & TinyTrak3
35. Re: APRS Internet System Design Philosophy
36. Re: D700 *& APRS
37. Re: APRSdos problem
38. Re: Email Line Length
<LYR30523-135098-2003.05.31-08.08.49--kb2scs#optonline.net@lists.tapr.org>
39. Re: APRSdos problem
40. Re: & TinyTrak3
41. Re: PAPRS 1.94 problem update
42. Re: & TinyTrak3
43. D7 not capable of full Voice Alert?
44. Re: D7 not capable of full Voice Alert?
45. Re: APRS Internet System Design Philosophy
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "Sean \\The RIMBoy\\" <sean@rimboy.com>
Date: Fri, 30 May 2003 21:38:35 -0500 (CDT)
X-Message-Number: 1
On Sat, 31 May 2003, Steve Dimse wrote:
>On 30 May 2003 21:06:17 -0500, David L Norris wrote
>>What I think would further this idea is a simple daemon-like program
>>that does precisely one thing: interconnect a TNC to a core
>>server. It has no GUI.
aprsd, as Steve points out does this.
>>It lives in one process with no
>>multithreading and simply connects a single TNC to a single
>>core server handling basic gating requirements.
I believe aprsd is multithreaded, a ps shows multiple instances of itself
running. Dale would be best to answer that question.
>>freely available to the community. It must be reasonably
>>portable so it could run _native_ on Windows, Unix, etc
>>without too much effort.
aprsd is freely available, GPL. However, porting to Windows is probably
not high on the list. Presumably it could run on Windows, but I would not
know where to start.
>>By portable I mean written in C and no bulky emulation layers.
It's written in C++, close enough?
>>i.e. not Java Think: bootable floppy disk
How's this?
http://www.rimboy.com/rimdistro/rimigate/
One floppy running linux complete with TCP/IP stack and WA4DSY's aprsd.
KG4NRC-1 has 600 hours of uptime running on a 486 sx25 with 12 megs of
ram. This is only because of a recent power outage (from that week of May
storms). I tried to query KG4OZL-1 which is running it but George either
closed off the http port or it's down at the moment... which is fine,
that's the approach we took with nashvilleaprs.net. Losing one igate in
the area is not the end of our feed to aprs.net (our servers show him
connected though).
Note, those that missed the QRZ.com announcment for v0.2, I've eliminated
the need for a linux system to build the disk. All of the important info
resides on a DOS partition on the floppy. As a result, Windows and Mac
users should be able to edit the config files with any unix LF compliant
editor (I make a suggestion for Windows, BBEdit for Mac or anything for
OSX should suffice). Distribution is now via disk image, ala boot
floppies you create for Red Hat. Download the image, write it to floppy
and then edit the files. Stick it in the target system, boot, and you're
done.
>Most aprsd users are using it as an IGate only daemon. Yes, it has the
capability to be a
>hub, but it does the IGate stuff well, and the hub functions of the program
take no
>resources unless you use them.
Nashvilleaprs.net is using this for its servers and it's working quite
well. We deploy the floppy distro's whereever possible (or encourage
people to use them) and then tie them into the nashvilleaprs.net servers
which in turn feed APRS-IS (aprs.net). So, yes, we're a tier 2 server
service provider. We feel it allows local users to get a feed of what
they want without having to tie up the resources of the APRS-IS services
at large. As it's been pointed out there's a limited number of connects
on the servers, we feel we're keeping our local people wanting to run
igates from tying up valuable ports on the APRS-IS system. Likewise, the
aprs.net servers get one unified feed from Nashville (in general).
First.nashvilleaprs.net is on my employer's backbone, which happens to
have Internet2. We're usually connected to first.aprs.net which resides
at Virginia.edu, also an I2 site. As a result all of the traffic from
Nashville comes over a very large and generally under-utilized pipe that
is designed for low latency multi-site applications (ie, grid computing).
>I don't know offhand of any floppy boot system that would give you an IP stack
that
>would be useable for an IGate, but there may be a stripped version of Linux
out there
>that does this.
RIMiGate. You can (and I have) fit a tcp/ip stack onto an 800k DOS
floppy, and cram NCSA telnet onto it also. But that's neither here nor
there. I do quite a bit of development with floppies under linux. The
nice part about going the floppy route is that you eliminate fsck's and
likewise having to maintain an entire install of linux. Server hung or
messing up? Reset switch or power cycle is all you need to get it back up
and running. Like I said, I've had 600 hours of uptime on my igate only
due to a recent power failure. KG4OZL's Igate runs RIMiGate on better
hardware and has turned in very good uptimes also.
>Certainly Knoppix could do it with a CD boot system, you would need to
>burn the disk for each use though with a separate config file for the IGate
(or use
>Knoppix's persistant home directory feature on a floppy).
That's one way to do it (and how I've considered doing it if I'd ever go
the CD route). As it stands for now, I'm sticking with the floppy
because an igate that plugs into a tier 2 server really does not need much
under the hood. Likewise, the media can be had for dirt cheap (as can the
CD, I know).
FWIW, RIMiGate is running a slightly older version of aprsd, version
2.1.5a7 with a patch from Terry Trapp KE4PJW. a7 is pre q constructs. I
intend to upgrade to the latest version of aprsd whenever the slow memory
leak is fixed (remember, I'm running and targeting low end 486's with 12
or more megs of ram). I've traded emails with Dale about this and I would
do more to help fix it but unfortunately I'm not a C or C++ programmer (I
just cobble the stuff together). a7 has been very stable. The patch from
Terry Trapp is what we call priority hubbing and we only suggest it for
nashvilleaprs.net (or if another tier 2 supports it, NOT for aprs.net
servers). It's off by default, but basically rather than cycling thru the
list of hubs 1,2,3,1,2,3 etc if it loses the connection to 1 it will
bounce to 2, but will check back to see if 1 is back. If 1 is back it
reconnects to 1. Likewise if it bounces to 2, loses connect it'll
bounce to 3. The only catch IIRC is that 2 will need to come back before
it can reconnect back to 1. However, if it's that big of a problem then
power cycle and you're back to 1. We tested this with success when we
moved first.nashvilleaprs.net to its current location. Again, do not use
this feature on the aprs.net servers. We did it for nashvilleaprs.net for
our tier 2 servers (2 of a planned 3 deployed so far).
LMK if you have any questions.
Cheers,
Sean...
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Sat, 31 May 2003 04:53:49 -0000
X-Message-Number: 2
>First, lets use the correct terminology. A datagram is a non-connected
packet, for instance as used in UDP. APRS-IS uses connected packets in TCP.
RFC 0793, 'Transmission Control Protocol', page 2:
TCP is based on concepts first described by Cerf and Kahn in [1]. The
TCP fits into a layered protocol architecture just above a basic
Internet Protocol [2] which provides a way for the TCP to send and
receive variable-length segments of information enclosed in internet
datagram "envelopes". The internet datagram provides a means for
addressing source and destination TCPs in different networks.
>If NO_TCPDELAY was not set, someone connecting to an outer tier server
over a slow connection could potentially see significant (over the dupe
time) delays between packets because each buffered group of data
requires an ack before the next buffer is sent. With TCP_NODELAY, the
data streams and acks are asynchronous to the data.
I've got no problem with IGATE uplinks and inter-server connections
using TCP_NODELAY. But the average client doesn't need the low latency,
and client connections vastly outnumber backbones and uplinks.
>But, the alternative is to go back to a point where 30+ second delays
in packets transiting APRS-IS could occur on a regular basis.
Just set it to flush out the buffer every 5 or 10 seconds if it's not
full. And even at its slowest, I don't think my statewide connection
ever goes that long without 1500 bytes of data.
>However, APRS-IS is a near real-time, subnetwork of the Internet. It
is a similar principal to the TCP streaming protocols for voice and
video, only we use smaller packets.
The key is that it's NEAR real-time. APRS can stand a whole lot more
latency than VoIP. Why not take advantage of that for some gains in
efficiency and capacity?
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
