| |
ZL3AI > APRDIG 31.08.03 10:23l 314 Lines 13274 Bytes #999 (0) @ WW
BID : 1843-ZL3AI
Read: GUEST
Subj: TAPR Digest, Aug 27, 5/7
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PCC<OK0NAG<OK0PPL<DB0RES<ON0AR<ZL2TZE<
ZL3VML
Sent: 030829/1436Z @:ZL3VML.#80.NZL.OC #:7299 [Chch-NZ] FBB7.00i $:1843-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRSWest.net ISP Switch
From: "Dick Stanich" <dick@kb7zva.com>
Date: Wed, 27 Aug 2003 14:46:13
X-Message-Number: 22
My Tier 2 server APRSWest.net, aka arizona.aprs2.net, aka ahubwest.net will
be undergoing a major ISP switch. I expect to be off the internet for maybe
3-4 days.
The new service will meet my growing requirements and much better
bandwidth. In the meantime, if you lose service there are other Tier 2
Servers available:
socal.aprs2.net (CWOP CW/WX Backup server)
indiana.aprs2.net
midwest.aprs2.net
uk.aprs2.net
My email will still work :)
dick@kb7zva.com
Dick Stanich, KB7ZVA
APRSWEST.NET Tier 2 Server
http://arizona.aprs2.net:14501/ (server stats)
APRSWXNET/CWOP
http://kb7zva.com
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 27 Aug 2003 15:53:52 -0400
X-Message-Number: 23
On 8/27/03 at 2:09 PM AE5PL Lists <HamLists@ametx.com> sent:
>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.
As the definition showed, if you collect data, you are buffering. A
database, for example is one form of a buffer. There are ring buffers,
FIFO's LIFO's (stacks), and many other kinds of buffers. You are being to
specific in your assignment of the meaning of the word, as the definition I
showed on dictionary.com shows.
>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.
That is exactly what I am referring to. What did you think I meant????
>>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
I did not say it was possible. I am talking about things that could be
done, I never said no programming was needed, though this particular change
to your program is trivial.
>single outbound validated feed. You are living in the past, Steve, when
>the only way to connect a server was via port 1313
There never was a time when the only way to connect to a server was 1313,
that was added months after APRServe was opened to the public.
>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,
Again, I never claimed your program could do this now.
>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.
Yes, this has all existed long before you wrote your program. However, what
I am concerned about is keeping every hub functioning in full communication
with all the others, so no packets are lost. This issue is not about what
happens if one server goes down, but about preventing the APRS IS from
being split into parts which are not able to communicate with each other.
>>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.
Again, you are completely missing the point. Yes, there are people that do
not connect to the core hubs, I have never denied that. The problem is that
there is no management of the entire system, and some of the hubs are not
correctly configured, or poorly maintained. It was in response to these
observations my challenge that someone look at the issues and try to manage
them, that the tier two group formed. However, rather than address the
problems, they simply formed another level below the core, which yes, are
better configured and maintained than other non-core hubs, but do nothing
to address the problems withing the APRS IS. They then began to try to
convince people that their network was better than the core.
>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.
Each of these also will show in the list, but with very specific patterns
because MORE than one link is affected, but still the problem is in the
link described...whether due to down connection, overloaded server, packet
loss, or whatever, the problem still is in the link described. If you see
problems in every connection to first, then there is obviously a problem
with first, but what is being monitored is that the links between first and
second, first and third, and first and fourth, are not functioning
correctly.
>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.
That is your opinion. Yes, the sample only covers 5 minutes out of an hour,
or one-twelth of the time. However the concern here is system-wide large
scale issues. I know exactly what I am measuring, it is that the core
servers remain communicating with each other through the links. Any packet
on one server is on all the others.
>>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.
No, they don't...they provide alternate hubs in the event one is down, but
they do not provide alternate paths. Paths on the APRS IS are determined by
the network configuration at the moment it is sent. If you tell me the two
hubs any stations are connected to, I can give you the exact path the
packet will follow. If any of the links that packet must pass are down, the
packet will not get there. You can provide one or a thousand tier 2, 3, and
4 servers, but the packet still will not get through!
>>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.
He chose not to communicate to me that he had blocked findU's IP, which
seems to me a very un-amateur behavior. Yes, we have serious disagreements,
but I would never block his data from or access to findU or any other
assest I control. Even now I do not conssider that an option. Calling him
on it in public seems quite appropriate to me.
Steve K4HG
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 27 Aug 2003 15:28:19 -0500
X-Message-Number: 24
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Posted At: Wednesday, August 27, 2003 2:59 PM
>Subject: [aprssig] RE: New fourth.aprs.net
>
>As the definition showed, if you collect data, you are
>buffering. A database,
>for example is one form of a buffer. There are ring buffers,
>FIFO's LIFO's
>(stacks), and many other kinds of buffers. You are being to
>specific in your
>assignment of the meaning of the word, as the definition I showed on
>dictionary.com shows.
The definition you quoted was for the transitive verb which does not say
that collecting data is buffering. It says that collecting data to a
buffer is buffering. Since you like dictionary.com, the noun definition
for buffer is:
5. Computer Science. A device or area used to store data temporarily.
A database can be used as a buffer but it is not, by default, a buffer.
As to my use of the term, it is very accurate and has been for the over
30 years that I have been involved with computers, software and
hardware. But, this is off topic and I shall not pursue this further.
>>This is not possible with javAPRSSrvr. javAPRSSrvr only supports a
>
>I did not say it was possible. I am talking about things that
>could be done, I
>never said no programming was needed, though this particular
>change to your
>program is trivial.
But undesirable. That is, IMO, bad program design due to potential loop
problems, among other networking problems. Specifically, I was saying
that your "example" was not an example at all because it could not be
done with javAPRSSrvr contrary to your statement above.
>the others, so no packets are lost. This issue is not about
>what happens if one
>server goes down, but about preventing the APRS IS from being
>split into parts
>which are not able to communicate with each other.
Agreed. And the tiered system accomplishes that.
>connect to the core hubs, I have never denied that. The
>problem is that there is
>no management of the entire system, and some of the hubs are
>not correctly
>configured, or poorly maintained. It was in response to these
>observations my
>challenge that someone look at the issues and try to manage
>them, that the tier
>two group formed. However, rather than address the problems,
Actually, I believe they formed for their own reasons and you did not
play a part in their organization. And, there still is no "management"
of APRS-IS nor will there be as long as the current architecture that
you implemented exists. Fortunately, there are a number of
forward-thinking sysops that have taken it into their own hands to
manage their slice of the pie, both by the core sysops and the non-core
sysops.
>>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.
>>
>No, they don't...they provide alternate hubs in the event one
>is down, but they
>do not provide alternate paths. Paths on the APRS IS are
>determined by the
>network configuration at the moment it is sent. If you tell
>me the two hubs any
>stations are connected to, I can give you the exact path the
>packet will
>follow. If any of the links that packet must pass are down,
>the packet will not
>get there. You can provide one or a thousand tier 2, 3, and 4
>servers, but the
>packet still will not get through!
Ah, but if the link between two servers is down, then it can be safely
assumed that all connections to one of those servers are also down (this
isn't magic). If the non-core server sees this, it switches to one of
the remaining operating core servers, just like a client would EXCEPT
that the non-core server only has one presence at the core instead of
20, 50, 100, or more presences.
While this is an interesting look at routing on the Internet, I fear
that it has gone far off-topic for the SIG. You have it in your mind
that the only way APRS-IS will work is for there only to be core
servers. I have shown that not only is this not true, but that APRS-IS
is working today in a tiered configuration. Since I doubt you will
change your mind, and since the network continues to run extremely well,
go ahead and have your final post because I have no intention of
pursuing this further.
>He chose not to communicate to me that he had blocked findU's
>IP, which seems to
>me a very un-amateur behavior. Yes, we have serious
>disagreements, but I would
>never block his data from or access to findU or any other
>assest I control. Even
>now I do not conssider that an option. Calling him on it in
>public seems quite
>appropriate to me.
Pot calling the kettle black? Similar attitudes make it hard to get
warring factions in the world to sit down and become peaceful. Think
about it. You would be amazed at what a little civil communication can
accomplish.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
