Ero sivun ”APRS iGaten ominaisuudet” versioiden välillä

Radioamatööriwikistä
Siirry navigaatioon Siirry hakuun
>Oh2mqk
p (Viite aprs-is verkkojen webisivuihin)
>Oh2mqk
(Keepaliveista rautalankaa, beaconien lähetyksen aikaväleistä)
Rivi 40: Rivi 40:
''Huomaa: Kaikki palvelinohjelmistot <u>eivät</u> anna tällaista "sydämenlyöntiä" yhteyksilleen!''
''Huomaa: Kaikki palvelinohjelmistot <u>eivät</u> anna tällaista "sydämenlyöntiä" yhteyksilleen!''


Vastaavan toiminnan jollain muulla palvelinohjelmistolla voi saada aikaan käyttämällä suodintoimintoja ja pyytämällä jonkin laajemman alueen datavirtaa, jolloin on melko jatkuva liikenne APRS-IS:stä igate:lle &mdash; tällöin linjavalvonnan valvonta-ajastinta virkistetään tiheään, vaikka ei olisi tarkoituskaan välittää mitään verkosta radiolle (kohtuus kuitenkin siinä datavirrassakin!). Kolmas tapa on käyttää käyttöjärjestelmän tarjoamaa TCP keepalive-ominaisuutta, silloin on kuitenkin useimmiten syytä säätää käyttöjärjestelmän keepalive-pakettien tarkistussaikaa pienemmäksi oletuksesta, esimerkiksi 5 minuuttiin.
Toinen keino vastaavan toiminnan tekoon kaikilla palvelinohjelmistolla on käyttää suodintoimintoja ja pyytämällä jonkin laajemman alueen datavirtaa, jolloin on melko jatkuva liikenne APRS-IS:stä igate:lle &mdash; tällöin linjavalvonnan valvonta-ajastinta virkistetään tiheään, vaikka ei olisi tarkoituskaan välittää mitään verkosta radiolle (kohtuus kuitenkin siinäkin datavirrassa!).
 
Kolmas keino on käyttää käyttöjärjestelmän tarjoamaa TCP keepalive-ominaisuutta, silloin on kuitenkin useimmiten syytä säätää käyttöjärjestelmän keepalive-pakettien tarkistussaikaa pienemmäksi oletuksesta, esimerkiksi 5 minuuttiin.  Tämän aikasäätö ei ole ohjelmakoodin tehtävissä UNIXin verkkokoodin API:ssa, vaan systeemimanagerin pitää se tehdä järjestelmälaajuisesti.
Pääsääntöisesti tätä ei pidetä hyvänä ideana.


Jos yhteyden muodostus epäonnistuu, ei kannata heti yrittää uudestaan, vaan odottaa 15-30 sekuntia ennen kuin aloittaa uuden yhteyden muodostamisen yrittämisen.  (Näin ohjelma ei pyöri villinä paikallaan.)
Jos yhteyden muodostus epäonnistuu, ei kannata heti yrittää uudestaan, vaan odottaa 15-30 sekuntia ennen kuin aloittaa uuden yhteyden muodostamisen yrittämisen.  (Näin ohjelma ei pyöri villinä paikallaan.)
== Beaconit ==
Beaconeja ''ei tulisi lähettää'' kellon ollessa jokin tasa 10 minuuttia!
Eikä edes kellon ollessa 05/15/jne 5 minuutin pykälä.
Mieluiten niin, että beaconit (jos niitä on enemmän kuin yksi) lähetetään tasaisesti koko viiveintervallin aikana, eikä yhtenä purskeena intervallin alussa.
NetBeacon-ryöppyjä tulisi lähettää [[APRS-IS]] verkkoon satunnaisin välein, joka vaihtelee 20-30 minuutin välillä.
Radiolle lähetettävienkin beaconeiden pitäisi olla satunnaistettuja.


== RX-igatelta vaadittavia ominaisuuksia ==
== RX-igatelta vaadittavia ominaisuuksia ==

Versio 3. joulukuuta 2007 kello 00.49

APRS igate on sovellus, joka kuuntelee radion kuulemia APRS paketteja ja välittää niitä internettiin APRS-IS verkkoon. Sovelluksen on myös mahdollista välittää paikkatietoja APRS-IS verkosta radiolle tietyin rajoituksin.

APRS igate ei yleensä ole Digipeater, vaan siihen on eri sovellus. igate kuitenkin tyypillisesti ottaa paketteja vastaan myös samassa laitteessa toimivalta Digipeaterilta.

APRS-IS yhteys

APRS-IS:n dokumentaatio on webissä: http://www.aprs-is.net/ ns. "Tier-2" APRS verkko on tuon päällä: http://www.aprs2.net/

APRS-IS:ään yhteys muodostetaan esimerkiksi johonkin seuraavista osoitteista:

  • finland.aprs2.net
  • rotate.aprs.net

Molemmissa tapauksissa jokaisella kerralla kun yhteyttä muodostetaan, nimi pitää resolvoida IP numeroksi, eikä sitä tulosta saa laittaa pysyvään käyttömuistiin, sillä näiden nimien takana on useita koneita ja kuormaa jakaakseen niihin yhteyden ottamisten pitäisi antaa jakautua "satunnaisesti". Jos nimi antaa useita IP numeroita, nämä kannattaa uudelleenjärjestellä satunnaiseen järjestykseen, koska jotkin systeemikirjastot ja resolverit haluavat järjestää saamansa osoitteet jollakin kriteerillä.

Suositeltava porttinumero kummassakin tapauksessa on 14580, joka mahdollistaa käyttäjän määritellä suotimen, jolla valikoidaan APRS-IS:stä igate:lle tulevia paketteja.

Kirjautuminen APRS-IS:ään tcp-yhteyden muodostumisen jälkeen: vähintään:

user <igaten kutsu> pass <kutsun passcode>

softaversion kanssa:

user <igaten kutsu> pass <kutsun passcode> vers <ohjelman_nimi ja versio>

suotimen kanssa (suodinta ei rx-igatessa käytännössä tarvita, koska igate välittää liikennettä vain yhteen suuntaan):

user <igaten kutsu> pass <kutsun passcode> vers <ohjelman_nimi ja versio> filter <suodinteksti>

esimerkiksi:

user OH9XYZ-13 pass 12944 vers munsofta 0.0.1 filter a/72/16/58/34 p/OF/OG/OH/OI/OJ

Suotimista kerrotaan sivulla: http://www.aprs-is.net/javAPRSSrvr/javaprsfilter.htm

Vastaanotettaessa #-merkillä alkavat rivit ovat kommentteja ja APRS-IS-palvelun omaa kohinaa, jolla ei ole määrämuotoa. Ne voi jättää huomiotta.

Kerrallaan saa olla vain yksi TCP-yhteys APRS-IS-palvelimeen, mutta TCP-yhteyden hereilläoloa kannattaa tarkkailla ja tarpeen mukaan vaihtaa yhteys johonkin toiseen APRS-IS-palvelimeen.

Vaikka radioverkossa ei olisikaan paikallisia tapahtumia, yllä mainitut APRS-IS järjestelmät käyttävät javAPRSSrvr ohjelmistoa joka juttelee "sydämenlyöntiään" TCP yhteydelle noin kerran 20 sekunnissa. Jos valvoo että TCP-yhteydeltä ei ole tullut mitään luettavaa 120 sekuntiin ja silloin sulkee vanhan yhteyden, ynnä avaa uuden normaalin käynnistysmenettelyn mukaisesti, systeemin pitäisi tuolloin huomata verkon häiriöt ja toipua niistä automaattisesti ja riittävän ripeästi.

Huomaa: Kaikki palvelinohjelmistot eivät anna tällaista "sydämenlyöntiä" yhteyksilleen!

Toinen keino vastaavan toiminnan tekoon kaikilla palvelinohjelmistolla on käyttää suodintoimintoja ja pyytämällä jonkin laajemman alueen datavirtaa, jolloin on melko jatkuva liikenne APRS-IS:stä igate:lle — tällöin linjavalvonnan valvonta-ajastinta virkistetään tiheään, vaikka ei olisi tarkoituskaan välittää mitään verkosta radiolle (kohtuus kuitenkin siinäkin datavirrassa!).

Kolmas keino on käyttää käyttöjärjestelmän tarjoamaa TCP keepalive-ominaisuutta, silloin on kuitenkin useimmiten syytä säätää käyttöjärjestelmän keepalive-pakettien tarkistussaikaa pienemmäksi oletuksesta, esimerkiksi 5 minuuttiin. Tämän aikasäätö ei ole ohjelmakoodin tehtävissä UNIXin verkkokoodin API:ssa, vaan systeemimanagerin pitää se tehdä järjestelmälaajuisesti. Pääsääntöisesti tätä ei pidetä hyvänä ideana.

Jos yhteyden muodostus epäonnistuu, ei kannata heti yrittää uudestaan, vaan odottaa 15-30 sekuntia ennen kuin aloittaa uuden yhteyden muodostamisen yrittämisen. (Näin ohjelma ei pyöri villinä paikallaan.)

Beaconit

Beaconeja ei tulisi lähettää kellon ollessa jokin tasa 10 minuuttia! Eikä edes kellon ollessa 05/15/jne 5 minuutin pykälä.

Mieluiten niin, että beaconit (jos niitä on enemmän kuin yksi) lähetetään tasaisesti koko viiveintervallin aikana, eikä yhtenä purskeena intervallin alussa.

NetBeacon-ryöppyjä tulisi lähettää APRS-IS verkkoon satunnaisin välein, joka vaihtelee 20-30 minuutin välillä. Radiolle lähetettävienkin beaconeiden pitäisi olla satunnaistettuja.

RX-igatelta vaadittavia ominaisuuksia

APRS-IS:n tekijöiden Gating criteria dokumentti kertoo oleellisimmat, tässä selostetaan hieman lisää.

APRS-IS verkkoon lähetettäessä kaikki paketit (= rivit) päätetään CR/LF-yhdistelmään. Jos paketissa itsessään on sisältönä CR tai LF merkkejä, katkaistaan paketti juuri ennen ensimmäistä tällaista merkkiä ja lisätään perään normaali CR/LF.

Radiolta paketteja vastaanotettaessa päätetään paketti ensimmäiseen vastaanotettuun CR:ään tai LF:ään.

Kaikkien bandilta kuultujen pakettien sisältö välitetään sellaisenaan (huomioi myös nollatavujen mahdollisuus pakettien sisällössä - vaikkakin C-koodit eivät niitä käytännössä tue!) APRS-IS:ään seuraavin poikkeuksin:

  • Kaikkien pakettien headerit tarvittaessa muutetaan ns. TNC2-muotoon (mm. KISS-paketit ja PK232-formaattiset), eli LAHDE-4>KOHDE-5,POLKU*,POLKU2:paketin datasisältö. Jos polkuosa on tyhjä, lyhenee paketti muotoon LAHDE-4>KOHDE-5:paketin datasisältö. Jos SSID on nolla, jätetään SSID ja sitä edeltävä väliviiva pois. Huomioi myös alempana mainittu igaten "signeeraus". Tähti polussa olevan kutsun perässä tarkoittaa, että ko. paketin on kyseinen asema toistanut (ns. has-been-digipeated bitti). Tähditys on syytä säilyttää alkuperäisenä, igatella ei siis lisätä eikä poisteta niitä.
  • Dataosaltaan '}'-merkillä (ASCII koodi 125) alkavia paketteja (ns. 3rd party) ei välitetä APRS-IS:ään, koska ne on jo kertaalleen Internet→RF suunnassa välitetty, jolloin voisi aiheutua looppi
  • Dataosaltaan '?'-merkillä alkavia (ns. generic query) ei välitetä APRS-IS:ään.
  • Ei välitetä radiolle paketteja, joiden polussa esiintyy TCPIP, TCPXX, koska tällaisen paketin voi olettaa tulleen väärin toimineesta igate:sta.
  • Jos paketin polussa missä kohdassa tahansa on merkkijono RFONLY tai NOGATE, ei pakettia välitetä. Lisäämällä tämän pakettinsa polkuun käyttäjä voi halutessaan kieltää paketin välittämisen APRS-IS:ään ja vastaavasti APRS-IS:stä bandille (jos lähettävä asema on suoraan TCP/IP-verkossa kiinni).
  • CR/LF-käsittely kuten yllä on kuvattu, eli paketti päätetään ensimmäiseen CR:ään tai LF:ään.
  • Hienompi sovellus voi lisäksi pitää kirjaa äskettäin sekä bandilta että internetistä "kuulluista" paketeista ja olla välittämättä jo kuultuja paketteja. Mahdollinen duplikaattipakettien tunnistusmekanismi kuvataan alla.

Duplikaattipakettien tunnistus tarkistussummalaskennalla

Jotta igate ei tarpeettomasti toistelisi nettiin tai varsinkaan radiolle paketteja jotka se on saanut jo aiemmin jommasta kummasta suunnasta, paketista voidaan laskea tiiviste (hash, tarkistussumma) ja pitää niistä kirjaa muistissa.

Tämän voi tehdä esimerkiksi niin, että ylläpitää tarkistussummakantaa, johon lasketaan jokaisen paketin "sisimmästä" AX.25 lähdeosoitteesta (call-ssid), kohdeosoitteesta (call, mutta ei ssid eikä myöskään polku) ja datakentän sisällöstä, mahdollisesti lopussa olevat välilyönnit poistaen tarkistussumma, sekä aikaleima.

Jos esimerkiksi viimeisen 60 sekunnin aikana kuullaan sama paketti uudestaan, ei sitä tarvitse turhaan välittää. Muista myös tyhjentää tarkistussummakannasta vanhentuneet tarkistussummat.

Paketin lopun välilyönnit jätetään tarkistussummalaskennassa huomiotta siksi, että jotkut igate-ohjelmat lisäävät tai poistavat välilyöntejä pakettien lopuista, jolloin välilyöntien määrän vaihdellessa tarkistussumma voisi muuttua. Paketti kuitenkin välitetään aina alkuperäisen määrän välilyöntejä sisältävänä.

Esimerkiksi seuraavassa paketissa tarkistussummalaskentaan otetaan mukaan "OH2XYZ-11", "APZYXW" ja ">pakettia":

"OH2XYZ-11>APZYXW-4,RELAY,WIDE:>pakettia  "

samoin seuraavasta kertaalleen välitetystä paketista otetaan mukaan vain "OH2XYZ-11", "APZYXW" ja ">pakettia", jotta eri asemien välittäessä saman paketin ne tuottavat saman tarkistussumman:

"OH1YYY>APRS,WIDE:}OH2XYZ-11>APZYXW-4,TCPIP,OH1YYY*:>pakettia  "

lopuksi kaikkiin APRS-IS:ään välitettyihin paketteihin lisätään polkuosan loppuun "qAR," ja igaten kutsu, esimerkiksi

"qAR,OH1YYY-3"

Eli bandilla kuultu paketti

"OH2XYZ-11>APZYXW-4,RELAY*,WIDE:>pakettia  "

välitettäisiin APRS-IS:ään muodossa

"OH2XYZ-11>APZYXW-4,RELAY*,WIDE,qAR,OH1YYY-3:>pakettia  "

RX/TX-igatelta vaadittavia ominaisuuksia

Ensinnäkin: APRS-IS→RF igate:n ei ole tarkoitus olla rakentajansa egon pönkittäjä ja liikkuvien asemien käyttämän kanavan tukkija

APRS-IS:n tekijöiden Gating criteria dokumentti kertoo oleellisimmat, tässä selostetaan lisää.

Kanavan tukkimisen välttäminen on tärkeää ja siksi kaksisuuntaisen igate:n kanssa tarvitaan RX-igaten ominaisuuksien lisäksi seuraavia.

Kunnollinen suodatus internetistä bandille välitettävälle liikenteelle:

  • Ei välitetä bandille paketteja, joiden polussa ei ole ",qAR," tietoa — "tämän lähettäjä on oikein verkolle tunnistautunut radioamatööri tai hänen igatensa."
  • Ei välitetä bandille paketteja jotka on jo bandilla esim. viimeisen viiden minuutin sisään kuultu, joko suoraan tai jonkun toisen välittämänä (ks. tarkistussumma-algoritmi yllä). Ei välitetä bandille APRS-IS:stä saatuja paketteja jotka on jo kuultu bandilta tai jotka on lähetetty bandille viimeisen viiden minuutin sisään.
  • Ei välitetä kovin kaukana igaten kohdealueesta olevia paketteja bandille yksinkertaisesti siksi, että ADSL-liittymänkin siirtonopeus on tyypillisesti vähintään tuhat kertaa suurempi kuin 1200 bps AX.25 APRS-kanavan. "Kaukopaketin" voi tunnistaa esimerkiksi sijaintipaketista lähettäjän sijainnin katsomalla ja laskemalla kuinka kaukana se on igaten sijainnista. Tätä sijaintitietoa voi sitten hyödyntää myös muiden ko. lähettäjän pakettien suodattamiseen (esim. statuspaketit, bulletiinit, yms).
  • Pääsääntöisesti välitetään bandille ylipäätään vain kohdealueelle kuuluvaa paikkatietoa sisältäviä paketteja, ei telemetriaa tai muuta kohinaa joissa ei ole paikkatietoa.
  • Poikkeuksena kaukopakettien välittämiskieltoon voidaan pitää APRS-viestejä, silloin kun viestin vastaanottaja tunnetusti sijaitsee igaten lähistöllä (igate pitää kirjaa lähistöllään bandilla sijaitsevista asemista). APRS-viestin yhteydessä bandille voi välittää myös lähettävän aseman sijaintipaketin tai pari, jolloin viestin vastaanottaja näkee missä viestin lähettäjä sijaitsee.
  • Käytetään laajuudeltaan hyvin lyhyttä polkua välitetyille paketeille, esimerkiksi vain WIDE (alias WIDE1-1, ääriharvoin WIDE2-2 joka sallii kaksi digipeat-toistoa radioverkossa!) Vaikka välityspaikalla APRS-liikennettä olisi bandilla hyvin vähän, se ei tarkoita sitä, että parin hypyn päässä esimerkiksi isommassa amatöörikeskittymässä olisi yhtä hiljaista. Tällöin ulkopuolelta bandia pitkin "hyppivät" paketit voivat tukkia vilkkaamman alueen.
  • Ei välitetä radiolle paketteja, joiden polussa esiintyy TCPXX, NOGATE tai RFONLY (Huom: TCPIP sallitaan!)
  • Kaikkien muiden suodattimien jälkeenkin rajoitetaan vielä bandille välitettävien pakettien maksimimäärä aikayksikössä esimerkiksi neljään pakettiin minuutissa. Tämän on tarkoitus toimia eräänlaisena failsafena, että koskaan ei tukittaisi kanavaa ja estettäisi bandilla olevien APRS-asemien toimintaa.
  • Vaihtoehtoisesti pidetään kirjaa kanavan käyttöasteesta. Jos se nousee yli 33% tason (omat lähetykset + kanavan signaalitason nousu FM-ilmaisimen ilmaisukynnyksen yli), rajoitetaan omaa lähettämistä pudottaen ensin pois netistä tulevat paketit, sitten omat RF-beaconit. Liukuvassa 1 minuutin jaksossa sallitaan 50% käyttöaste, kunhan samanaikaisesti ei ylitetä liukuvassa 5 minuutin jaksossa 33% käyttöastetta.


Internetistä radiolle välitetyt paketit välitetään ns. 3rd party formaatissa, eli esimerkiksi igaten OH4ZZZ-5 saadessa internetistä paketin

"OH2XYZ-11>APZYXW-4,RELAY*,WIDE,qAR,OH1YYY-3:>pakettia  "

välitetään se bandille muodossa

"OH4ZZZ-5>APZ123,WIDE2-2:}OH2XYZ-11>APZYXW-4,TCPIP,OH4ZZZ-5*:>pakettia  "

jossa APZ123 on igate-ohjelmiston käyttämä/tunnistava kohdeosoite, WIDE2-2 igaten käyttämä polku ja OH4ZZZ-5 igaten kutsu, joka siis toistuu sekä AX.25 headerissa, että paketin sisällössä. TCPIP "sisemmän" paketin polussa kertoo että paketti tuli internetistä. Paketin alkuperäinen polku siis poistetaan kokonaan tilaa viemästä.