| |
ZL3AI > APRDIG 31.08.03 10:22l 234 Lines 9348 Bytes #999 (0) @ WW
BID : 1842-ZL3AI
Read: GUEST
Subj: TAPR Digest, Aug 27, 4/7
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 030829/1423Z @:ZL3VML.#80.NZL.OC #:7298 [Chch-NZ] FBB7.00i $:1842-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: EEPROM Burners
From: "Jason Rausch" <ke4nyv@msn.com>
Date: Wed, 27 Aug 2003 13:42:59
X-Message-Number: 18
I have recently got ahold of a Motorola Syntor X here at the shop and I
don't have access to a suitcase programmer anymore. So I need to find a
EEPROM burner that will let me burn a SEEQ DQ2816A-300 8429 EEPROM. I
would like to find somthing I can just build and avoid somthing like a $200
programmer.
The Syntor X I have uses a small EEPROM to hold the codeplug information
and I need to just find a way to burn a raw HEX file right to it.
Anyone know of anything?
Thankx,
Jason KE4NYV
www.ke4nyv.com
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 27 Aug 2003 14:09:02 -0500
X-Message-Number: 19
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Posted At: Wednesday, August 27, 2003 1:11 PM
>Subject: [aprssig] RE: New fourth.aprs.net
>
>From dictionary.com:
>
>3. Computer Science. To hold or collect (data) in a buffer.
>
>This is exactly what APRServe, and later javAPRSrvr, do. They
>collect the data,
>and when a user connects to that port, they get a dump of the
>buffer. Just to
>prove that in fact this is a term in use in connection with
>APRServe from the
>beginning, here is my original paper on APRServe presented at
>the DCC in 1997:
>Sorry that you object to the terminology I chose 6 years ago,
>Ihope you can
>forgive me for not changing based on your personal preferences.
I am well aware of your original paper and your misuse of the term buffer.
But, feel free to abuse the English language in any way you see fit. For
the record, javAPRSSrvr does not collect historical data in a buffer.
>I disagree strongly. Remember that the APRS IS is not like
>TCP, or IP multicast
>protocols. TCP is point to point, and multicast is point to
>everywhere. APRS IS
>is everywhere to everywhere...data enters at many points, and
>the idea is to get
>data to everywhere that enters anywhere in the system, and
>have no looping
>occurring.
But the server interconnection architecture is based on TCP so there is
full acknowledgement going on between servers. You later indicated the
possibility of packet loss in a TCP connection. The only way this
occurs is if the connection is lost.
>Adding a spiderweb of interconnects in this case DOES NOT
I never said that there should be a "spiderweb of interconnects". In
fact, I said just the opposite.
>20 hubs or more, all connected to a few (or even all) of the
>others. The
>connections are not using unvalidated port 1313 as presently
>on both core and
>tier 2 networks, but validated full feeds. What happens?
This is not possible with javAPRSSrvr. javAPRSSrvr only supports a
single outbound validated feed. You are living in the past, Steve, when
the only way to connect a server was via port 1313 or when a server
could be configured for multiple bidirectional feeds (some software
still supports this, but javAPRSSrvr does not and never has). In fact,
the non-core servers act as a collection point and each communicates via
a single feed to the core. Should a core server go down, the non-core
server reconnects to any core server still operating and continues to
provide a steady feed. This reduces loss of packets because it prevents
the overloading of the remaining core servers and it limits exposure to
differences in client configurations and timeouts.
>There are probably many other ways the APRS IS could be made
>more reliable,
>these are just off the top of my head. However, adding a
>second tier, without
>increasing the paths a packet can take to reach the other
>hubs, does nothing to
>increase reliability, and in fact decreases it on a simple
>mathematical basis,
>as there are more things to go wrong.
As shown above, this statement is just flat wrong. The current APRS-IS
is, whether you like it or not, a tiered network and has been for a very
long time.
>>Your monitoring system has nothing to do with how links are restored.
>>Your monitoring system only reflects whether all the servers
>are passing
>>the same packets and does not monitor the inter-server links.
>>
>That shows you do not understand what I am monitoring. For
Steve, you sample the data from the four core servers once every hour
for 5 minutes and hope that you catch a large difference in server data.
In fact, this difference could be caused (and has been caused) by
bandwidth issues, software issues, or server loading issues. Without
putting a full time network monitor on each port 1313 connection, your
"monitoring" is simply conjecture and a hope that your sample will occur
when a link failure occurs and that link failure is not concurrent with
other inabilities to reach a given server. I would say that you do not
understand what you are monitoring.
>Each server doesn't introduce errors, but it does increases
>the chance for an
>error (namely a bad link or a crashed server) to occur. If
>more servers
>increases the ability for the system to function if one goes
>down, then it is a
>good thing, but the second tier does nothing to provide
>another path in the
>event of a failure somewhere in either tier.
As shown above, they certainly do provide alternate paths. And,
attached clients also have a large number of servers to choose from that
they can rotate through, as well, if the tier 2 server goes down.
>impossible. I find this very interesting...is there something to hide?
Why don't you be polite and communicate with Dick directly as I
recommended before? From the looks of the stream page before findu was
blocked, I would say Dick has nothing to hide as the page was showing
his server providing the same level of reliability as the core servers.
>You say that tier 2 servers make the network more reliable.
>Please, give me an
>example of a failure that the tier 2 servers prevent.
Done above.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Wed, 27 Aug 2003 14:19:36 -0500
X-Message-Number: 20
In some of my past emails about my design for a replacement/overlay APRS-IS
network, I have tried to make it clear what issues exist with the current
system.
This discussion is sort of hinting at one of the primary issues.
There is nothing that guarentees that a single packet received over RF by a
particular I-Gate, will make it to any particular screen or database in the
world.
TCP makes the bytes that you send arrive on the other end, arrive in order.
It does not make sure that all the bytes you sent actually made it to the
other end. This is what transaction processing is used for. Wouldn't it be
nice if you could pay for something with your credit card, and occassionaly,
the system would fail, and you wouldn't get charged!
Until we have end to end guarentees, adding levels to the network will only
provide other places that might fail to deliver packets to the intended
recipient (the core servers or outbound subscribers). That is a simple and
plain fact. If the intervening nodes, instead provide a validation of each
packets delivery from end to end, then, and only then would multiple routes
and multiple machines provide a failover capability that would enhance the
dependability of the system.
In my purposed design, packet could then flow across a level three layer to
multiple I-Gates simulataneously, and up through levels 2 and 1 and across
each of those layers as well so that the latency for any particular RF-to-RF
packet would be minimized. And, in many cases, the core would never send a
packet back out over the internet, because dup checking would tell it that it
had already seen it over a particular link to another server (at the same
level or below).
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 27 Aug 2003 14:31:54 -0500
X-Message-Number: 21
Gregg,
I agree and, as you stated, creating a level 3 transport layer for APRS
activities on the Internet is the most desired solution. However, that
is something that needs to be looked at for the "next generation"
design. It might be worthwhile to design such a protocol which would
initially be implemented solely between servers with the servers acting
as a gateway to current clients, IGates, etc. While this would not be
end-to-end, it would improve reliability within the server network.
Since APRS is a UI protocol, there never will be a complete guarantee
that a packet on RF will make it to the Internet, but it would be
worthwhile to look at setting a protocol in place to say "if it makes it
to a server, it makes it to all servers".
In the long run, IGates and clients could also make use of the new
protocol (it would always be available, just not mandatory).
As always, I would be interested in doing whatever I could to implement
such a protocol within javAPRSSrvr.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
