[aprssig] Packet routing, path specification.
Robert Bruninga bruninga at usna.eduThu Jun 23 14:03:56 UTC 2005
- Previous message: [aprssig] NOSaprs update - cross port digi with callsign substitution
- Next message: [aprssig] Packet routing, path specification.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>> HamLists at ametx.com 06/22/05 9:55 PM >>> > There is no requirement to get "agreement" >amongst all the hams on the eastern seaboard >to effectively implement the NSR algorithm. This seems inconsistent with the NSR stated objective that "Each digi will only allow diigpeats from those other digis that the sysop will allow." By definition, this means the list is restrictive to limit traffic to a reasonable level. In this area that is surely 2 tiers or less. But I routinely like to check in to the Philly area weekly APRS Sunday NIght check-in which is 3 hops away (because it is the ONLY live humans on the air at the time). Under the NSR there is no way the Philly area digis are going to allow packets from a Washington DC digi. SImilarly under NSR, the stated objective is to PREVENT me from directing my packets to an area of my choosing. Only the SYSOP of each digi will decide where my packets can go. >NSR has everything to do with implementing a >diverse, yet stable network. And that is exactly >what the NSR does. But by defniition, that means a rigid, stagnant, unresponsive network completely incapable of AD-hoc response to an immediate need. ANd experience has shown that getting DIGI sysops to respond quickly (read weeks) to needed changes in many areas is a demosntrated problem. The NSR approach by definition kills the original intent of APRS which was ad-hoc responsiveness to what ever the need at hand. And the need at hand was NEVER intended to be 24/7 beacons with lights on but no one home doing nothing most of the time. APRS was for facilitating real-time human-to-human digital exchange of data of immediate use. >True, you might not be able to work Philadelphia >from Annapolis on a direct RF path, but then >again you can't reliably do that now. You can, >however, work anyone in Philadelphia from Annapolis >today by specifying only one digi in your path and >using messaging (and the internet). I fully suport the APRS-IS, and global messaging via the internet, but it being able to use a reasonable RF path as needed where needed is the essence of HAM radio in my mind. There is a big difference between the distribution needs of APRS 24/7 home stations just doing nothing all day versus a real-live-HAM radio activity with humans at both ends... >Dallas is far from an "isolated" area. We see >packets everyday from Kansas to South Texas, >New Mexico to Louisiana. In fact, we don't >need to see the packets from users in Dallas >County (the next county south) or vice versa. I hope users in Dallas county are reading this and understand the implication here that under NSR, they will not be allowed to send any packets into Dallas under any circumstances except via the Internet. O r without explicit attention by the sysop to add them specifically to an exception list. >This is not a matter of "agreement" with remote >users or sysops; it is a matter of usability of >APRS for local users. Usability is a subjective term. If you dissalow any packets from getting into your area except a given routine load of local packets only from a given list of digis, then you preclude any responsiveness to any other non-routine RF needs or situation. In effect you turn APRS into any other bureaucratic comms system that is un-responsive in non-routine needs which is where HAM radio is supposed to excell. >You have not shown a single example where it is >critical that a user be able to define where their >broadcast packets end up. I do it every night. I look at the list of stations using RELAY and WIDE and TRACE and W4-4 etc and send out a few messages. I choose a path of DIGI1, DIGI2, DIGI3 where digi 3 is the digi in their area of the group of people I want to hit. THus I am easily able to get my packets into New Jersy 150 miles away but with only 3 total copies produced. Compared with WIDE2-2 which in this area will generate 10 to 15 total copies on the network. It doesnt take a rocket scientist to see the advantage of only 3 total packets to let me communicate 3 hops to a specific area, versus blathering my packets out 15 copies in all directions and yet not reaching my intended recepients. You say, these packets should arrive via the Internet. Believe me, it doesnt work. When I send a message via local RF to someone out of area (where the APRS-IS should make it work perfectly) I NEVER get an ack but in maybe 5% or less of any attempts. It simply does not work. Where a directed 3 hop path works well (if there is a real human at the other end). Even in this ihigh density area, it sometimes takes 3 hops to find another live human... Remember, 3 hops via a 3 hop directed path is 5 times more efficient than sending the same packet only 2 hops via WIDE2-2. APRS was designed for rapid path changing to meet the immediate needs of the operator. APRSdos provided for up to 12 pre-definedd specific paths that could be INVOKED on each message line by line by a simple two character abbreviation at the front of a message entry. NW: Hey john, (northwest of me) did you get that radio? SW: sam, where is tht new digi you were talking about W2: This is a local messge packet going out WIDE2-2 DC: This is a directed packet to Wash DC using the pre defined path to DC In each case, it took less than 0.1 second for the sender of a message line to indicate the path he wanted THAT ONE PACKET to go by adding the two digit path abbreviation for it. THe problem is that NONE Of the other APRS follow-on clone software implented any of this. They just set a one-path-fits all mentality and the result is the mess we see today. Remember this is radio and the rule has always been, use the minimum power (read path) to get the job done. I can not help it that other clone software overlooked this fundamental aspect of APRS. and not only that but did not even display the PHG data on the map so that one could easily SEE the best path to use. de WB4APR, Bob Bob
- Previous message: [aprssig] NOSaprs update - cross port digi with callsign substitution
- Next message: [aprssig] Packet routing, path specification.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
