| |
ZL3AI > APRDIG 05.06.03 09:27l 267 Lines 11003 Bytes #999 (0) @ WW
BID : 1425-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 30, 4/5
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<HA3PG<KD4GBA<ZL2BAU<ZL3VML
Sent: 030604/1344Z @:ZL3VML.#80.NZL.OC #:1680 [Chch-NZ] FBB7.00i $:1425-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRS Internet System Design Philosophy
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 30 May 2003 17:04:03 -0400
X-Message-Number: 28
The talk of fourth.aprs.net is bringing up some smoldering issues with the
APRS Internet System. Allow me to summarize some of the points involved in
these issues.
When the APRS IS was created, the goal was to provide a central system for
linking the RF networks around the world. My architecture called for a
small number (initially 2) of interlinked central servers to which IGates
and users could connect.
As aprsd and later javAPRSSrvr gave anyone the ability to serve
connections, an alternative architecture was advocated, the two-tier model.
In this design, the core servers serve only IGates and each other, users
are served at a second layer of servers. Like many things in ham radio,
this has become a politically and emotionally charged argument.
I am on record as saying that either of these designs, when appropriately
implemented and managed, could fulfill the needs of the APRS IS. Still, I
am a strong advocate of the original design, because I feel that it offers
the best chance of being implemented given the resources available to an
amateur project like this. Most importantly, it requires the cooperation of
a smaller number of people, and the monitoring of a smaller number of
servers.
The shortcoming of the current central hub implementation is capacity. Two
of the servers have limitations on the number of connects that are too low
or marginal. This is for bandwidth reasons...the APRS stream is large, and
when duplicated a couple hundred times is quite a load on a server's
internet connection. Still, server locations that can easily handle large
loads are surprisingly available...when I needed a new home for findU, I
got many offers for very fat pipe locations...it is amazing how many hams
have control of large data centers! second and now fourth.aprs.net are in
places that can support 175 and 250 connects respectively. first can
support 125, which I consider marginal, and third can only support 60,
which I consider inadequate for a core server. If third moved to a better
co-lo site, and first moved, or a fifth were added, the core could likely
support the needs of APRS for some time to come.
With a centralized core, you can have an automated monitoring system that
looks for packet loss. I have written such a system:
http://www.findu.com/stream/
Every hour a five minute set of data is obtained from each of the core
servers, as well as findU's own javAPRSSrvr, which connects to all of the
core servers and to aprswest. For each of these sets, four minutes of data
(skipping the first and last 30 seconds to prevent false hits due to timing
differences) is checked against the other captures, and any missing data
counted and placed on a web page.
The shortcomings in the two tier system are it requires the cooperation of
a much larger number of people, the multiple servers are more confusing to
users, and it is much harder to monitor the system.
The second tier stats page:
http://www.ahubswe.net/aprs_stat.asp
looks at the number of users of the system, but does not test for the data
loss. The more servers you have, the harder it is to do anaylsis like my
stream analysis, as the number of comparisons goes up exponentially.
Advocates of the two tier approach like to say that it allows more
filtering options, but there is no filtering a second tier server could do
that a core server could not.
As I say, either design could work, but the present chaotic hybrid is far
from the ideal of either approach. Without anyone willing to take a
leadership role, I don't see much hope for improvement...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "Spider" <spider@rivcom.net>
Date: Fri, 30 May 2003 15:47:13 -0700
X-Message-Number: 29
----- Original Message -----
From: "Steve Dimse" <k4hg@tapr.org>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Friday, May 30, 2003 2:04 PM
Subject: [aprssig] APRS Internet System Design Philosophy
>Advocates of the two tier approach like to say that it allows more filtering
>options, but there is no filtering a second tier server could do that a core
>server could not.
>
>As I say, either design could work, but the present chaotic hybrid is far from
>the ideal of either approach. Without anyone willing to take a leadership role,
>I don't see much hope for improvement...
>
>Steve K4HG
As you know, there can be many servers connected to the 4 "core" servers
that are in place. Having more core servers does nothing but improve
reliability for everyone, including those that call themselves "2nd level".
This does nothing to harm the servers that choose to have special ports and
run special applications.
Since 4th has been up this is obvious! With the JavaServer application on
4th, the ability for Dave to also supply filtered ports directly off the
core server is nothing but a plus for the users that choose to use those
ports. I think the software alone changes they way a core could perform
provided the pipe is there to support it. 4th is in Florida. What an
excellent opportunity for those (even those funny looking Island stations
<g>) in Florida to have a good connect so close...and there are a bunch of
APRS users in Florida.
I think this will help the other main servers out a great deal. I can see
nothing but a win win situation for every one here!
As far as all those big data centers out there that are willing, could you
send some toward FireNet? We need about 3 or 5 more servers around the
country! :)
Jim, WA6OFT
FireNet Coordinator
www.dwrracesupport.com/fire
"10% of life is what happens to you. The other 90% is how you react to it."
----------------------------------------------------------------------
Subject: Re: callsign server
From: "Spider" <spider@rivcom.net>
Date: Fri, 30 May 2003 15:57:05 -0700
X-Message-Number: 30
Chris,
I do not know if you know of this one and it's not exactly an "APRS"
callsign server. I use it with Achat to look calls up! Works great!
Telnet would work too!
You an download Achat at www.wa6oft.com/dnld.htm
The server is: wm7d.net and the port is 5000. This is NOT an APRS port
but more of a telnet port.
In Achat, you connect to that server, enter a callsign in the Text to Send,
hit send and you get an immediate reply that looks like:
query->
call: N4BSA class: Technician
SCHWAB, CHRISTOPHER J
1479 HUNT LANE
CLEARWATER, FL 33762
issued: 11/09/1998
expires: 11/09/2008
effective: 10/23/2001
last update: 10/23/2001
prev call: KD4PHS
prev class: Same
73
Jim, WA6OFT
FireNet: www.dwrracesupport.com/fire
www.wa6oft.com
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Fri, 30 May 2003 23:19:34 -0000
X-Message-Number: 31
How about some buffering on the server side? I'm looking at a TCP dump of
my regional feed, and invariably it's getting one APRS line per datagram.
Most APRS-IS datagrams are about 150 bytes, while MTUs on the Internet are
typically 576 or 1500 bytes. That means there's a lot of unnecessary
overhead in the IP and TCP headers and the ACK responses. Sending a full
1500-byte datagram would only require holding off on transmit for at most a
few seconds, even on lower volume regional feeds. It requires no changes to
the client, since the APRS reports are already delimited by CR/LF pairs, and
should really be just a matter of how the server passes data to the TCP
stack.
I think we can tolerate a few seconds of latency in the network if it means
reducing bandwidth usage by 30%...
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "Steve Dimse" <k4hg@tapr.org>
Date: Fri, 30 May 2003 23:32:59 +0000
X-Message-Number: 32
On Fri, 30 May 2003 15:47:13 -0700, Spider wrote
>
>As far as all those big data centers out there that are
>willing, could you send some toward FireNet? We need about 3
>or 5 more servers around the country! :)
Have you asked? When I did I was overwhelmed by the response.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS Internet System Design Philosophy
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Fri, 30 May 2003 19:49:44 -0500
X-Message-Number: 33
See below.
>-----Original Message-----
>From: Miller Scott Contr 30SCS/FTI
>[mailto:Scott.Miller@vandenberg.af.mil]
>Posted At: Friday, May 30, 2003 6:22 PM
>Posted To: APRS SIG
>Conversation: [aprssig] Re: APRS Internet System Design Philosophy
>Subject: [aprssig] Re: APRS Internet System Design Philosophy
>
>How about some buffering on the server side? I'm looking at
>a TCP dump of my regional feed, and invariably it's getting
>one APRS line per datagram. Most APRS-IS datagrams are about
>150 bytes, while MTUs on the Internet are typically 576 or
>regional feeds. It requires no changes to the client, since
>the APRS reports are already delimited by CR/LF pairs, and
>should really be just a matter of how the server passes data
>to the TCP stack.
>
>I think we can tolerate a few seconds of latency in the
>network if it means reducing bandwidth usage by 30%...
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. Now, to answer your question regarding why TCP_NODELAY is set at
the servers. APRS is a real-time protocol. As such, the servers
implement a duplicate checking algorithm to reduce the number of packets
repeated and to reduce the possibility of loops. Even so, there are
still loops caused by WIDE7-7,TRACE7-7 paths hitting IGates at intervals
exceeding the dupe time (adjustable on each server). 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.
This does cause an increase in bandwidth requirements and certain
low-end routers have a limited packet/second capacity. 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.
You are right for non-real-time, non-subnetworked data, TCP_NODELAY
makes no sense. 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.
73,
Pete Loveall AE5PL
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
