Morsen über das Internet?

53. UKW-Tagung Weinheim
Morsen über das Internet?
Dipl.-Ing. Erich H. Franke, DK6II
[email protected]
In diesem Beitrag werden wir uns Echtzeit-Übertragungsprotokolle im Internet und den technischen Hintergrund im Blick auf eine eher ungewöhnliche Applikation anschauen. Der tiefere Sinn? Nun, ich denke,
dass moderne Technik ruhig auch einmal sinnfrei sein kann, so wie manches mit dem wir uns in unserer
Freizeit beschäftigen. Ein Reiter beispielsweise denkt gemeinhin nicht darüber nach, dass Pferde heutzutage als Verkehrsmittel nur noch eine geringe Bedeutung haben. Kaum ein Musiker würde sein handbespieltes Instrument gegen einen MP3-Player eintauschen und Funkamateure fahren im Zeitalter von Internet und Mobiltelefonen noch immer mit Begeisterung QSO in Morsetelegraphie, obgleich letztere im kommerziellen Funkverkehr gar nicht mehr angewandt wird. Deshalb lassen Sie uns hier über ein Thema
sprechen, ohne die Spock’sche Logik über Gebühr zu strapazieren.
Königsbach-Stein, im Juli 2008
Motivation
Eigentlich wurden die Grundlagen zu diesem Beitrag schon vor ungefähr acht Jahre gelegt. Da saßen
DL1KHD, DL2FCQ, meine XYL DF6IV und ich am Rand einer Party zusammen und diskutierten zu
vorgerückter Stunde eher unernst über „over-IP“-Dienste, sinnvolle und exotische. Ich weiß leider nicht
mehr, wer letztendlich auf die Idee kam, Morsezeichen über das Internet zu übertragen und damit –
wer weiß - dem Amateurfunk vielleicht einen kleinen Schub zu versetzen. Wie gesagt, an ernster Forschung war zu diesem Zeitpunkt keinem von uns gelegen.
Doch selbst im grauen Licht des darauffolgenden Tags blieb die Idee prinzipiell umsetzbar. Selbst
sinnvolle Anwendungen in der Tastfunkausbildung, in der Jugendarbeit und der Einsatz auf Veranstaltungen schienen denkbar. Also ging ich mit niederer Priorität an die Umsetzung. Seit 2002 sind Server
im Internet „QRV“ und werden sogar dann und wann benutzt.
Lassen Sie uns einmal anschauen, was es mit den Details auf sich hat.
Die Mathematik der Morsezeichen
„Morsezeichen sind aus nur wenigen rhythmischen Zeichenelementen aufgebaut, den kurzen Grundelementen (dit) und den drei Mal so langen (dah) sowie den dazu gehörenden Abständen…“
So ähnlich erklärte die Stimme der unbekannten Sprecherin zu Beginn des „Morsekursus des Deutschen Amateur Radio Clubs“, dessen Schallplatten- und Kassettenversion zahlreichen Funkamateuren geholfen hat, die damals noch notwendige Morseprüfung zu bestehen [MKURS].
Für alle diejenigen unter Ihnen, welche des Morsens nicht mächtig sind, hierzu eine kurze Erklärung:
Normalbürger sagen, Morsezeichen bestünden aus Punkten und Strichen. Insider hingegen sprechen
von den „(dit)“ und den „(dah)“.
Die Übertragung der Morsezeichen selbst beruht auf einem festen Zeitraster.
Buchstabe
Codierung
Anzahl Elemente
gesamt
E
1
1
T
3
3
N
3+1+1
5
Y
3+1+1+1+3+1+3
13
Der „Punkt“, also das „(dit)“ hat dabei die
(Norm)-Länge eins. Der „Strich“, „(dah)“
genannt, erstreckt sich über drei Normlängen.
Anders als beispielsweise ASCII besitzt
der Morsecode Codewörter mit variabler
Länge.
Codes variabler Länge kennen wir aus dem Alltag. Beispielsweise wir der Hufman-Code bei der FaxÜbertragung angewandt. Ein anderer prominenter Vertreter ist der UTF-8-Code für internationale Zeichensätze.
Der Trick bei diesen Codes besteht nun darin, häufig auftretende Codewörter mit kurzen Codes zu
belegen, seltenere hingegen mit längeren. Überträgt man so einen Text mit der passenden Statistik,
so kann man gegenüber festen Codewortlängen Zeit sparen.
In unserem Fall hatten die Erfinder englischsprachige Telegrammtexte analysiert, deren Buchstaben
nach der relativen Häufigkeit ihres Auftretens sortiert und daraus die Zeichencodes festgelegt.
E
I
N
T
E
S
T
10001010001110100000001110001000101010001110000000
= Elementabstand
= Taste gedrückt (Ton)
= Zeichenabstand
= Taste losgelassen
= Wortabstand
Der Buchstabe „E“ besteht demnach
lediglich aus einem kurzen Element (dit).
Ein „T“ hingegen aus einem drei Elementlängen umfassenden (dah). Bei
einem „N“ wird ein (dah) von einem (dit)
gefolgt.
Die beiden Grundelemente trennt der so
genannte „Elementabstand“ der Länge
eins.
Zum nächsten Buchstaben wird eine Pause von drei Elementlängen eingeführt. Diese nennt man –
wie könnte es anders sein - Zeichenabstand. Worte untereinander werden durch den sieben Elementlängen umfassenden Wortabstand getrennt.
Die Morse-Geschwindigkeit misst man ein Europa in „Buchstaben pro Minute“ (BpM). In den U.S.A.
und anderen Ländern gibt man den Wert gerne in „Wörter pro Minute“ (WpM) an.
Doch wie soll man diese Übertragungsrate in der Praxis denn messen? Wie man sofort erkennen
kann, würde die Übertragung einer Folge von „Y“ rund dreizehn Mal länger dauern als eine Folge von
„E“ gleicher Anzahl!
Um dieses Problem zu lösen wurde das Normwort „PARIS“ festgelegt. Es besteht aus exakt 50 Elementen. Probieren Sie es ruhig einmal aus1.
Also gut: Mit 50 Elementen verteilt auf 5 Buchstaben erhält man im Schnitt 10 Elemente pro Buchstaben.
Bei einer Rate von 60 BpM, also 60 Buchstaben pro Minute sind das 600 Elemente pro Minute oder
10 Elemente pro Sekunde. Jedes Element hat demnach eine Länge von 100 msec.
Programmiertechnisch gesprochen können wir die Zeit für ein Element in Millisekunden aus der Rate
in BpM mit folgender einfacher Beziehung ermitteln: t EL
6000
. Bei 60 BpM erhalten wir 100 msec.
R
Echte CW-Hardliner, die 300 BpM hören, müssen demnach mit Elementlängen von 20 msec auskommen. Das ist praktisch Fernschreibgeschwindigkeit!
Handschriftliches
Ein wichtiger Unterschied zwischen der Morseübertragung und Computer-Computer-Kommunikation
ist, dass Morsen für Menschen gemacht ist.
Die Grundidee ist, Morsen wie eine neue Sprache zu lernen. Auch das wird in der Literatur [DJ2PJ]
und in Kursen oft gelehrt.
Betätigt ein Mensch eine Hand-Morsetaste, so wird er im Alltag das ideale Tastverhältnis zwischen
(dit) und (dah) von 1:3 nicht sklavisch einhalten wollen und können. Wie ein Musiker, der den Rhythmus variiert, wird ein Operator die Zeichen und Pausen nach seinem individuellen Befinden unbewusst geringfügig abändern.
Es ist sogar so, dass diese Variationen von Person zu Person unterschiedlich ausfallen. Geübte Hörer
können sogar unterschiedliche Sendestationen an dieser subtilen Normabweichungen, also ihrer
„Handschrift“, erkennen und unterscheiden. In der elektronischen Aufklärung (EloKa) spricht man vom
„Fingerprinting“, das helfen kann, Funknetze zu identifizieren.
In unserer Aufgabe Morsezeichen über Internet zu übertragen wollen wir diese wertvolle und interessante Eigenschaft beibehalten.
Dazu müssen wir eigentlich nur die Zeitdauer messen, für die die Morsetaste am Sender gedrückt ist,
also der Ton hörbar ist bzw. die Zeit, in der sie losgelassen ist, also die Pausenzeit.
Zeichnen wir diese beiden Zeiten in der Art eines Oszillographen auf, so erhalten wir ein Streifenmuster, welches den Zustand der Morsetaste über die Zeit darstellt.
1
Falls Sie auf einen anderen Wert kommen, so haben Sie vermutlich den Wortabstand vergessen, der gedanklich an das Ende
des Worts gehört.
Die durchgezogene Linie charakterisiert den Ton bei gedrückter Taste. Dort wo keine Linie gezeichnet
wird, ist die Taste in Ruhestellung.
Mit einer Handtaste gegebener Morsetext auf Streifenschreiber mit ca. 67 BpM. Zeitachse in Sekunden.
Solche Diagramme werden im Übrigen in der Tastfunkausbildung benutzt, um die „Qualität“ der gegebenen Zeichen zu bestimmen. Diese ist umso höher, je besser es dem Sendenden gelingt, das ideale
Verhältnis 1:3 einzuhalten.
Die Handschrift steckt in der Variation der Zeit. Also müssen wir lediglich die Zeitdauer von Ton und
Pause übertragen, dann können wir die Handschrift auch dann noch erkennen, wenn wir die Morsezeichen über das Internet übertragen haben.
Funktypisches
Funkamateure besitzen ein heute schier unglaubliches Privileg, nämlich sich die Betriebsfrequenz auf
der die Übertragung stattfinden soll, in den zugewiesenen Frequenzbändern selbst auszuwählen. Für
die klassischen Betriebsarten SSB und CW und auf Kurzwelle gilt zudem kein „Raster“, es gibt keine
„Kanäle“ auf denen sie Senden müssten.
Die Frequenzabstimmung erfolgt kontinuierlich bzw. in sehr feinen Schritten mit in der Praxis vernachlässigbarer Stufung.
Je moderner die Übertragungsverfahren sind, umso mehr wird der Bediener von der physikalischen
Schicht – dem Funkkanal – entkoppelt. D-Star beispielsweise ist bereits eher verwandt mit Betriebsarten des kommerziellen und militärischen Funks. In modernen Geräten sitzen zwischen Funkkanal und
Bediener Komponenten der digitalen Signalverarbeitung.
Da die Telegraphieübertragung noch zum funktechnischen Urgestein gehört, haben wir hier im Wesentlichen lediglich einen analogen Mischer, der das HF-Signal in den hörbaren Bereich linear heruntermischt.
„Nähert“ man sich mit einem solchen Überlagerungsempfänger einem Telegraphiesignal, so wird man
ein mehr oder weniger hohes Überlagerungspfeifen hören. Es entsteht – ganz grob gesprochen - aus
der Differenz des HF-Signals mit dem VFO des Empfängers. Würde man den Oszillator genau auf die
Empfangsfrequenz abstimmen, so wäre die Differenz null. Je weiter der Abstand, desto höher der
Betrag der (Differenz-)Frequenz. In der Praxis stellt man eine Differenz von ca. 600 Hz ein. Dort hat
das menschliche Ohr eine gute Empfindlichkeit. Wie gesagt: Morsen ist etwas für Menschen.
Es gibt noch einen Effekt, welcher durch das Filter im Empfangszweig hervorgerufen wird. Morsezeichen belegen aufgrund der geringen Modulationsfrequenz2 eine geringe Bandbreite von, sagen wir
einmal 500Hz. Sprachübertragung erfordert hingegen Bandbreiten von ca. 3 KHz.
Kurzwellenempfänger besitzen daher – häufig auch umschaltbare – Filter, mit deren Hilfe Störsignale,
welche in der Frequenz weiter entfernt liegen, gedämpft und unterdrückt werden.
Beim Abstimmen erscheinen Signale also erst leise, wenn sie sich am Rand des Empfängerfilters
befinden und werden in Filtermitte am lautesten.
Insgesamt wäre es doch schön und erstrebenswert, wenn diese „analogen“ Eigenschaften auch bei
Morseübertragung im Internet erhalten blieben.
Nachrichten aus dem Internet
Die Übertragung von Daten im Internet gehört heutzutage bereits fast zur ingenieurmäßigen Allgemeinbildung.
Lassen Sie uns trotzdem kurz die wesentlichen Eckpunkte rekapitulieren:
Unter dem Sammelbegriff „Internet Protocol“ (IP) sind eine ganze Reihe von Übertragungsvorschriften
zusammengefasst, die letztendlich die Kommunikation im Netz sicherstellen. Eine Reihe davon steu2
Diese ist abhängig von der Morse-Geschwindigkeit. Jedoch existieren nicht vernachlässigbare Frequenzanteile durch die
Anstiegszeit bei der Tastung des Trägersignals.
ern untergeordnete Eigenschaften und dienen der Verwaltung, beispielsweise der Teilnehmeradressen.
Zu diesen untergeordneten Protokollen gehört beispielsweise das IMCP (Internet Management
Control Protocol), zu dem das bekannte PING gehört.
In die Klasse der Datenübertragungsprotokolle gehören UDP und TCP.
Jeder Teilnehmer im Internet benötigt eine eindeutige Adresse, die so genannte IP-Adresse. Sie besteht momentan aus vier 8-Bit-Zahlen, welche durch Punkte getrennt sind. Dies wäre das Adressierungsschema der Version 4 (IP v4).
Hiermit sind (256)4 unterschiedliche Adressen zu formen, eine Zahl, welche groß erscheint, heutzutage jedoch nicht mehr ausreicht. Daher wird Zug um Zug das Internet auf die Adressierung der Version
6 (IP v6) umgestellt, bei der vier 16-Bit-Felder und damit (65536)4 Adressen möglich sind.
Ein Trick bei IP v4 ist es, innerhalb geschlossener Netze „private“ Adressen zu verwenden, beispielsweise den Block 192.168.XXX.XXX. Diese können, beispielsweise innerhalb von Firmennetzen, mehrfach verwendet werden [IPADR]. Nur im „öffentlichen“ Internet müssen die Adressen fest zugeordnet
sein. Teilnehmer mit „privaten“ Adressen werden in den „Gateways“ temporär auf feste Adressen umgesetzt. Nur dadurch funktioniert das Internet heute überhaupt noch, sonst wären IP v4-Adressen
schon längst nicht mehr verfügbar!
Neben der Adresse gibt es noch eine 16-Bit umfassende Port-Nummer. Diese implementiert logische
Kanäle, welche von der gleichen IP-Adresse genutzt werden können.
Das „User Datagram Protocol“ ist sehr einfach zu implementieren und zu verstehen. Hier wird ein
Datensatz quasi en bloc von der Quelle zur Senke übertragen. Der Nutzdatenblock bleibt im Regelfall
immer zusammen. Allerdings besteht keinerlei Garantie dass der Block auch wirklich ankommt.
Schlimmer noch: Es könnte sein, dass der Block versehentlich gleich zwei Mal ankommt.
Sendet man zwei Blöcke hintereinander ab, so könnten sich die beiden sogar überholen, so dass der
zweite Block vor dem ersten eintrifft. Nichts ist hier unmöglich…!
UDP hat überall dort seine Bedeutung, wo übergeordnete Systemanteile dafür sorgen, dass die Datenintegrität trotz dieser scheinbaren Einschränkungen sichergestellt wird.
Auch können UDP Datagramme übertragen werden, ohne dass zuvor eine logische Verbindung zwischen Quelle und Senke hergestellt wird. Die Angabe der IP-Adresse und des Ports genügen. Man
spricht daher auch von einer „verbindungslosen“ Übertragung.
Im Gegensatz dazu ist das „Transmission Control Protocol“ (TCP) verbindungsorientiert. Vor der eigentlichen Datenübertragung wird eine logische Verbindung zwischen Quelle und Senke aufgebaut
(„connect“). Diese Verbindung wird für die Dauer der Verbindung („session“) beibehalten und zum
Schluss wieder ausgelöst („disconnect“). Der Aufwand zur Steuerung der Verbindung, also der „Protocol Overhead“, ist nicht ganz unerheblich.
Dafür verhält sich eine TCP-Verbindung im Betrieb wie ein Stück Draht. Jedes Stückchen an Information, welches man auf der Quellenseite in den logischen Kanal steckt, kommt in der gleichen Reihenfolge an der Senke wieder heraus. TCP setzt also nicht wie UDP auf Datagrammen (Datenblöcken)
auf, sondern ist eher mit einer Fernschreibverbindung zu vergleichen. Die Daten werden Byte für Byte
übertragen. Der Kanal ist automatisch bidirektional, das heißt, er verhält sich wie eine VollduplexVerbindung.
Die Verbindung wird dabei völlig selbständig gehalten. Übertragungsprobleme werden durch Wiederholungen unsichtbar für den Nutzer ausgeführt. Dies bedeutet, dass gesendete Daten bei der Senke
unter allen Umständen ankommen, es sei denn, die Verbindung bricht dauerhaft zusammen. Doch
selbst dann erhält die Quelle darüber Nachricht.
TCP und UDP sind aus der Datenübertragung nicht mehr wegzudenken. Jede UNIX-Implementierung,
jedes WINDOWS sowie zahlreiche Betriebssysteme für Echtzeit- und „Embedded“-Anwendungen
implementieren diese Netzwerk-Protokolle. Diese sind durch Schnittstellen häufig sehr einfach anzusprechen, so dass die Implementierungsdetails auf der Betriebssystemsschicht bzw. im so genannten
Protokoll-Stapel („Protocol Stack“) gekapselt sind und dem Programmierer kein Detailwissen abverlangt!
Eine Frage des Protokolls
Bei der Definition der Morseübertragung hatte ich auf TCP gesetzt, da mir dies zum damaligen Zeitpunkt einfacher erschien. Doch auch UDP hätte wegen des deutlich geringeren Overheads seinen
Charme gehabt.
Eigenschaft
UDP
TCP
„Framing“
Ist bereits rahmenorientiert und benötigt daher
keine Rahmensynchronisation.
Ist „zeichenorientiert“ und benötigt daher eine Rahmensynchronisation.
Integrität
Benötigt Maßnahmen zum Schutz der Datenintegrität
Datenintegrität durch Protokoll gewährleistet
Laufzeit
Erzielt vergleichsweise kurze Laufzeiten, da
deutlich geringerer Overhead.
Durchlaufzeiten durch das System länger und bei
schlechten Verbindungen wegen der inherenten
Datenwiederholung eher undefiniert.
In der täglichen Praxis, vor allem innerhalb eines Netzes in einem Gebäude ist die Datenintegrität
gewöhnlich exzellent. In diesem Fall ist zeigt sich auch das TCP in seinem Zeitverhalten von seiner
besten Seite.
Jedoch implementiert TCP aus Sicht des Nutzers einen kontinuierlichen Datenstrom, vergleichbar
einer seriellen Schnittstelle. Es gibt auf Anwenderebene keine erkennbare Blockung, obgleich auf den
tieferen Schichten selbstverständlich Daten als Datagramme – mithin geblockt – transportiert werden.
Dies gibt, wie wir gleich sehen werden, beim Zeitverhalten ein paar unschöne Nebeneffekte.
FRM
DATEN (optional)
CHK
FRM
FRM: Rahmen-Begrenzungszeichen
CHK: Prüfinformation
Doch erst einmal müssen wir als Programmierer
alt bekannte Tricks anwenden und eine eigene
Rahmenstruktur schaffen. Das ist normalerweise
nicht weiter schwer.
Man führt sogenannte Rahmen-Begrenzungszeichen ein. Der Empfänger wartet einfach auf das Begrenzungszeichen, übernimmt die Daten und hört am Begrenzungszeichen am Ende des Blocks wieder auf. Folgen Blöcke unmittelbar aufeinander, so genügt in manchen Fällen auch nur ein derartiges
Begrenzungszeichen.
Das Problem ist meistens, dass die Begrenzungszeichen nicht durch Daten innerhalb des Blocks imitiert werden dürfen. Sonst kommt der Empfänger durcheinander.
Man kann dieses Problem auf zwei Arten lösen:
a) Man sorgt durch Einfügen von Erweiterungszeichen („Escape“) oder –Bits dafür, dass alle zufällig im Datenblock vorkommenden Begrenzungszeichen so verändert werden, dass sie nicht
mehr stören.
Beispiele hierfür sind die ESC-Folgen im Point-to-Point Protocol (PPP) und die Zero-BitInsertion im HDLC-Protokoll.
b) Man wählt die Codierung des Datenblocks so, dass die Begrenzungszeichen codefremd sind.
Ein sehr simples Beispiel hierfür ist der „Wagenrücklauf“ (Carriage Return, CR) im Fernschreiben. Dieser Code bildet ein nicht-druckbares „Steuerzeichen“ das weder zu Buchstaben
noch zu Ziffern oder Satzzeichen gehört. Die Datenblöcke, d.h. die Zeilen sind durch CR voneinander getrennt.
Ich gebe zu, letzteres Beispiel klingt etwas weit hergeholt, ist aber völlig zutreffend. Es ist simpel, extrem leicht zu implementieren und zu verstehen. Deswegen habe ich mich für einen ähnlichen Ansatz
entschieden.
Es gibt bei der Blockung jedoch noch eine Kleinigkeit zu beachten: Gewöhnlich fügt man den Daten
eine Prüfinformation hinzu. Diese dient zur Versicherung, dass der Dateninhalt korrekt ist und zeigt
damit gleichzeitig auch an, dass die Rahmenerkennung korrekt verlaufen ist.
Dieses Vorgehen wird gerne auf allen Ebenen der Datenübertragung angewandt und ist generell anzustreben. Für die Versuche mit der CW-Übertragung hatte ich allerdings eher Occams Grundsatz der
Einfachheit und weniger Murphys Gesetz beachtet.
Da wir als unterliegendes Protokoll TCP benutzen werden Datenverfälschungen bereits durch die
tiefere Protokollebene verhindert, bzw. sind als unwahrscheinlich zu betrachten. Auch Verfälschungen
durch „Character Insertion“ oder „-Deletion“ können in erster Nährung ausgeschlossen werden.
Der Faktor Zeit
Ein Wort noch zur möglichen Blocklänge.
Je länger wir die Datenblöcke wählen, desto „effizienter“ wird die Übertragung, denn TCP wird versuchen, diese in einem Rutsch auszusenden. Obgleich TCP an der Oberfläche „datenstrom-orientiert“
ist, tickt im Untergrund eine Maschine, welche den Datenstrom wiederum in Pakete zerhackt, da das
Internet eben nur paketorientierte Übertragungen zulässt.
TCP wird daher immer „ein wenig“ warten, ob vom Datenstrom noch Nutzdaten kommen, bis es den
Block abschließt und losschickt.
Im Ernstfall könnte solch ein Paket auf der untersten Ebene nur ein einziges Nutzbyte enthalten, umrahmt von Adressierungs- und Steuerinformation. Das ist zwar nicht effizient, jedoch manchmal unvermeidlich.
Letztendlich wollen wir ja eine „quasi-Echtzeit“-Übertragung erreichen, und da wir nicht wissen wie der
menschliche Benutzer seine Morsetaste betätigt, müssen wir mit diesem Effekt eben leben.
Die Wartezeit ist systemabhängig und gemeinhin sehr kurz.
Das kommt uns entgegen, denn wenn wir einen bk-Betrieb3 simulieren wollen, so würden lange Speicherzeiten stören.
In der Telephonie kennen wir den „Apollo-Effekt“. Durch die Laufzeit der Funksignale zum Mond von
ca. 1,3 Sekunden ist Gegensprechen in Duplex praktisch nicht mehr möglich. Daher hatte die NASA
seinerzeit den „Roger-Pip“ eingeführt um die QSO-Führung im Wechselsprechen zu vereinfachen.
Selbst hier auf der Erde macht sich die begrenzte Ausbreitungsgeschwindigkeit bei Ferngesprächen
über Satellit bemerkbar. Selbst Laufzeiten von 200 ms stören den Gesprächsfluss bereits erheblich.
Bei „Voice-over-IP“ (VoIP) ist es nicht die Signallaufzeit, sondern wie in unserem Fall die „Speicherzeit“ welche durch die paketorientierte Übertragung zwingend auftritt.
Infrastruktur
Die vorliegende Implementierung geht von einer Client-Server-Struktur aus, bei der die „Clients“ die
Teilnehmer darstellen. Der Server im Internet simuliert so etwas Ähnliches wie den Funkkanal.
Der Betriebsablauf stellt sich recht einfach dar: Will ein Teilnehmer sich an einem QSO beteiligen, so
verbindet er sich über TCP mit dem Server. Dadurch entsteht eine logische Zwei-Wege-Verbindung
zwischen dem Server und dem Client.
Nun übermittelt der Client dem Server ein paar Daten zur Verwaltung: Den Namen oder das Rufzeichen des Teilnehmers und die „Frequenz“ auf der man senden möchte.
TEILTEILNEHMNER
TEILNEHMNER
TEILNEHMNER
NEHMNER
SERVER
Erstere Angabe dient ein Wenig der Höflichkeit
und der Statistik. Der Name wird im QSO nicht
verwendet. Romantiker brauchen sich diese
Information von ihrem Client-Programm also
nicht anzeigen lassen und können, wie im der
funktechnischen Alltag, auf den Inhalt der Morsesendung hören.
Die „Frequenz“ ist einfach ein Zahlenwert, den der Server sich merkt.
Liegen diese simulierte Sendefrequenz einer Station „in der Nähe“ der – ebenfalls simulierten - Empfangsfrequenz einer anderen, so wird der Server die Ton/Pause-Zeiten an den Empfänger weiterleiten.
Dazu wird die Differenzfrequenz errechnet und auf Empfangsseite mit einem „Filter“ bewertet. Wäre
diese Differenzfrequenz hörbar, so gibt die Software die Töne in der passenden Tonhöhe frei. Liegen
die Frequenzen jedoch weiter auseinander, so hört man eben nichts. Ich habe zur Demonstration
probehalber eine Lautstärkeabhängigkeit als Funktion der Differenzfrequenz ausprobiert um ein Empfangsfilter zu simulieren. Das hörte sich recht ordentlich an.
Ruft also eine Station auf einer simulierten Frequenz CQ, so kann ein Empfänger „über das Band“
drehen, bis er eine passende Station hört. Jede Veränderung der Betriebsfrequenz muss dem Server
gemeldet werden, so dass dieser entscheiden kann, ob ein anderer das Signal hören kann oder nicht.
3
bk (break). In dieser Betriebsart wird häufig die Übertragungsrichtung gewechselt, ähnlich wie in einem lebhaften Gespräch.
Sind mehrere Teilnehmer am Server angemeldet, so wird der Server die Daten einfach an alle Teilnehmer weiterleiten, die sich zu dem gegebenen Zeitpunkt hören können. Unter LINUX können selbst
einfache Rechner eine große Anzahl derartiger Weiterleitungen völlig problemlos abhandeln.
In unserer Implementierung wird der Server eine Reihe von Verbindungen erlauben, danach den Verbindungswunsch ablehnen
Codierungsfragen
Wie bereits gesagt: Das Verfahren ist bereits recht alt, hat sich aber in der Praxis bewährt, mögen
Telegrammaufbau und Codierung dem einen oder andren auch ein Wenig exotisch erscheinen.
Telegrammstruktur
Alle Telegramme haben folgende prinzipielle Struktur.
CC
CC:
CHK:
BS:
U
DATA
BS
Command Code
User Address
Block Separator
CC steht hierbei für ein aus zwei alphanumerischen Zeichen bestehendes Befehlskürzel. Das erste
dieser Zeichen muss als Großbuchstabe aus dem 7-bit-ASCII-Zeichensatz stammen. Das zweite kann
aus einem Großbuchstaben oder einer Ziffer bestehen. Satzzeichen, nicht druckbare Zeichen oder
Zeichen mit Codierung >127 sind nicht zulässig und führen zum Verwerfen des Telegramms.
Der Server ignoriert alle Telegramme, deren Codierung er nicht kennt. Eine Fehlermeldung erfolgt
nicht. Ein Client sollte ebenfalls so handeln.
U kennzeichnet eine aus einem Zeichen bestehende Benutzeradresse im komprimierten Datenformat
zur Basis 80d (siehe unten!). Dieses wird später näher erläutert. Codefremde Zeichen sind nicht zulässig und führen dazu, dass das Telegramm verworfen wird.
Die Adresse 0 kennzeichnet den Server selbst.
Adresse 1d..79d kennzeichnet einen der am Server angemeldeten Benutzer.
Der Server vergibt diese Adressen selbsttätig. Ein Benutzerprogramm kann die Adressvergabe nicht
steuern. Die Adressen sind während einer gesamten Session konstant. Nach einem Disconnect und
einem späteren erneuten Connect kann der Client eine andere Adresse erhalten.
Das Feld DATA hat eine je nach Befehl variable Länge und kann in Einzelfällen auch ganz entfallen.
Das Datenfeld darf beliebige Zeichen aus dem Vorrat 0x20 >= c >= 0xFF, sowie 0x09 (Tab) enthalten.
Letzteres Zeichen kann bedarfsweise als Feldtrennzeichen dienen. Die Länge des Datenfeldes darf
250 Zeichen nicht überschreiten. Andernfalls wird das Telegramm verworfen.
Diese Begrenzung wurde willkürlich gewählt. Wie wir gleich sehen würde ein Block mit einer Länge
von 250 Byte bereits vier durchschnittliche Fünfergruppen fassen. Das ist bereits das praktisch Limit
für die Durchlaufverzögerung des Systems („Apollo-Effekt“). Die Limitierung dient auch dazu, den
Programmierern von „embedded systems“ das Leben zu erleichtern.
TCP, als datenstrom-orientiertes Protokoll kennt eine derartige Begrenzung nicht. Eventuelle Blockungen auf der Übertragungsstrecke werden durch die so genannte Fragmentierung abgehandelt.
Aus Gründen der Sicherheit gegen Angriffe sollten sowohl auf Server- als auch auf Client-Seite Blockgrenzen sorgfältig überprüft werden.
Jedes Telegramm wird durch den Rahmenbegrenzer BS abgeschlossen. Hierzu dient das newlineZeichen (0x0A, line feed).
Codierung numerischer Werte
Numerische Werte, wie z.B. die Benutzeradresse oder die Ton- und Pauseninformation werden komprimiert als druckbare Zeichen übertragen.
Verwendet wird ein Zahlensystem zur Basis 80 (dezimal), das auf die ASCII-Zeichen 0x21 (‚!‘) bis
0x71 (‚p‘) abgebildet wird. Dem Zeichen ‚!‘ ist hierbei die 0d, dem Zeichen ‚p‘ die 79d zugeordnet. Aus
diesem Zahlensystem können, wie sollte es auch anders sein mit n Stellen 80n unterschiedliche Werte
codiert werden.
Zur Anwendung kommt „big endian“, d. h. die Dezimalzahl 123 würde in die Stellen 801 + 43 zerlegt
und „high digit first“ mit den ‚Ziffernfolge’ 0x22 0x4C bzw. “ L dargestellt.
In vorliegendem Protokoll besitzen derartige „Zahlen“ meist eine implizite, feste Länge von zwei oder
drei Stellen.
Die ASCII-Codes von Leerzeichen, Steuercodes und Sonderzeichen 0x20 sowie ASCIIZeichencodes 0x72 größer gelten als codefremd. Wie gesagt, das mutet exotisch an, ist jedoch sehr
praktisch, da das Rahmen-Begrenzungszeichen 0x0A (oder newline) in den Nutzdaten nicht vorkommen kann uns keine Maßnahmen zur Verhinderung von Imitationen getroffen werden müssen.
Frequenzinformationen
Die Angabe einer Betriebsfrequenz erfolgt in Hertz relativ zum ‚Bandanfang‘. Die niederste Frequenz
ist also 0.0 kHz. Die Frequenzangabe wird als numerischer Wert codiert. Eine Frequenzinformation
besteht aus drei Zeichen. Der Bereich beträgt somit ! ! ! für den Bandanfang 0 kHz, sowie 15d
49d 79d , also 0x30 0x52 0x70 bzw. 0 Z p für die - willkürlich gewählte – Frequenz 99,999 kHz.
Dem größtmöglichen dreistellig codierten Wert p p p ist der dezimale Zahlenwert 511999d zugeordnet. Unser „Frequenzband“ ist also ein wenig mehr als 500 kHz breit und ist dabei frei von QRM, was
jedem Freund der Telegraphie das Herz höher schlagen lässt.
Ton/Pause-Paare
Die Morseelemente werden in Form von „Ton-Pause-Paaren“ in Form zweier aufeinanderfolgender
Zahlenwerte codiert. Das erste Element enthält dabei die Zeit in Millisekunden, in der ein Ton ausgegeben werden soll. Es definiert also die Zeit, in der auf der Sendeseite die Morsetaste gedrückt gehalten wurde.
Der zweite Wert ist die auf den Ton folgende Pause, ebenfalls in Millisekunden.
Die Werte werden als numerische Werte codiert, wobei jedes Element (Ton oder Pause) mit zwei
Zeichen codiert wird. Ein ganzes Ton/Pause-Paar ist demnach vier ASCII-Zeichen lang.
Töne bzw. Pausen sind können also zwischen Null (Codewort ! ! ) und dem codierten Wert p p ,
also dem dezimalen Zahlenwert 6399d Millisekunden lang sein. Der Wertebereich ist mehr als ausreichend und würde sogar die Codierung exotischer 1BpM erlauben.
Hier gibt es zwei Dinge zu beachten:
Ein Datenblock muss zwingend mit einem Pausencode enden. Ggf. wird der Empfangsprozess diesen
„synthetisch“ einfügen, damit bei Übertragungsstörungen der Ton auch wirklich abgeschaltet wird.
Bei Pausen, die länger als 6,4 Sekunden dauern wird einfach kein neues Ton-Pause-Paar nachgesendet. Bleibt die Morsetaste unbenutzt, so wird der Sender einfach keine neuen Daten senden.
Bricht die TCP-Verbindung also zusammen, so kommen einfach keine neuen Morsezeichen mehr an
– genau wie im täglichen Leben.
Es ist zulässig, Ton- und Pausenlängen mit dem Wert Null zu senden. Eine Pause der Länge Null
unterbricht den Ton einfach nicht. Er wird einfach mit einem Ton der Länge des folgenden TonPausen-Paars weiter geführt. Für Pausen gilt dies sinngemäß, jedoch ist das Verfahren nach (2) die
bevorzugte Implementierung.
Telegrammtypen
Der Befehlscode (CC) besteht aus zwei alphanumerischen Zeichen, die die Art der folgenden Daten
beschreiben. Wieder wurde eine sehr einfache Codierung gewählt.
Die Bedeutung der Codes erschließt sich später bei der Beschreibung des Betriebsablaufs.
Mnemonic
Befehl
Richtung
Bedeutung
UC
User Clear
S -> C
Löscht auf dem Rechner des Teilnehmers (Client) die gesamt Liste, in der die auf
dem Server angemeldeten Benutzer (User List) gespiegelt sind.
Kommt in der Regel als Antwort auf US und wird normalerweise durch eine Reihe
von UA-Telegrammen gefolgt.
UD
User Delete
S –> C
Meldet dem Rechner des Teilnehmers, dass sich der bezeichnete Benutzer vom
Server abgemeldet hat
UX
User Reject
S -> C
Der Server kann keine weiteren Clients akzeptieren
US
Get Serverside User
List
C -> S
Veranlasst den Server, dem Client die Liste der momentan angemeldeten Benutzer
zu senden.
Freundlicherweise sendet der Server zunächst ein UC um beim Client die Liste zu
löschen.
Danach folgen eine Reihe aufeinanderfolgender UA-Telegramme, um die momentan
am Server bekannten Teilnehmer beim Client anzumelden.
UA
User Add
beide
Der Client meldet seine Daten mit diesem Telegramm dem Server.
Der Server meldet dem Client, dass ein neuer Benutzer auf dem Server hinzugekommen ist oder dass sich die Daten eines Benutzers auf dem Server geändert
haben.
Der Server sendet dieses Telegramm als Antwort auf die Frage US, bzw. auf ein UA
eines anderen Clients.
FC
Frequency
Change
beide
Der Client informiert den Server über die Veränderung der ‚Betriebsfrequenz‘.
Der Server spiegelt diese Meldung an alle angemeldeten Benutzer zurück.
TP
Tone/Pause
Beide
Der Client schickt einen String mit den Zeiten für Töne und Pausen.
Der Server leitet diese an alle anderen Clients ‚auf dieser Frequenz‘ weiter.
User Code
Der der User Code (U) identifiziert den Benutzer. Der Server kann eine bestimmte Anzahl von Benutzern verwalten, die in der Folge auf dem simulierten Frequenzband zu hören sind. Für den Test habe
ich die Zahl auf MAXUSER gelegt (s. u.).
Jedem Benutzer wird beim Verbindungsaufbau ein Platz in der „Benutzerliste“ zugewiesen, den er so
lange behält, wie er eingebucht ist. Ein Client sollte diesen Listenplatz daher nicht anzeigen, sondern
nur den „Nick-Name“ des Benutzers. Dieser Name, Rufzeichen usw. dient der unverbindlichen Anzeige. Eine Authentisierung ist nicht vorgesehen.
Usercode 0 (Null) kennzeichnet den Server, User Codes 1 bis MAXUSER kennzeichnet die „Listenplätze“ der User auf dem Server.
Betriebsablauf
Will ein Teilnehmer auf einem simulierten Frequenzband teilnehmen, so meldet er sich mit einem
TCP-Connect an dem entsprechenden Server an.
Dieser Verbindungsaufbau besitzt keinerlei Besonderheiten. Hierdurch wird der Stream installiert.
Nach erfolgtem Verbindungsaufbau sollte der neu eingetretene Benutzer gleich zwei Telegramme
senden: Die Detaildefinitionen stehen im Anhang.
1) „User-Add“ (UA) mit einem provisorischen Usercode 1. Der Server ignoriert den User-Code
und weist dem Benutzer einen Platz in der Liste zu.
Sollte der Server bereits die größtmögliche Zahl an Benutzern unter Arbeit haben, so weist er
den Wunsch mit einem „User Reject“ (UX) ab.
Parameter: Der User-Type wird auf UT_USER gesetzt, Frequency und Nickname können
nach Belieben innerhalb der Grenzen gewählt werden.
2) „Get Server-side User List“ (US), ebenfalls mit dem provisorischen Usercode 1. Der Server
gibt nun die Liste allen bereits eingeloggten Users aus.
Genauer gesagt, er sendet erst ein „User Clear“ (UC), gefolgt von einer Reihe aufeinanderfolgender „User Add“ (UA) Telegrammen.
Die Idee dahinter ist, dass es eigentlich gar kein Protokoll gibt. Der Client reagiert einfach auf
UC und UA und muss nicht an irgendeine Vorgeschichte denken. Simple logic is the best4.
In der Server-Liste tauchen nun alle Objekte auf, die sich in dem Frequenzband tummeln können: Bakensender, andere Benutzer und natürlich auch der Neuankömmling selbst. Der Server gibt diesem seinen Status als UT_YOURSELF zu erkennen.
Andere Benutzer werden mit UT_USER, Baken mit UT_BEACON gekennzeichnet. Auf diese
Weise erhält der Client Kenntnis darüber, was sich im Frequenzband so tummelt.
Nun steht dem Datenaustausch nichts mehr im Wege.
Sendet der Client eine Folge von Ton-Pause-Paaren (TP), so werden diese vom Server entgegen
genommen und an alle anderen Benutzer weiter verteilt, sofern diese in der Betriebsfrequenz „nahe
genug“ an dem Client liegen, dass sie auch überhaupt „gehört“ werden können.
4
Mr. Spock u. Capt. Kirk in “Startrek - The Voyage Home”
Der Sender übergibt als User-Code wieder die provisorische 1. Der Server setzt dann den Tatsächlichen User-Code ein. An den sendenden Client (UT_YOURSELF) verteilt der Server die Daten nicht,
damit eine digitale Rückkopplung vermieden wird. Es gibt wieder der Grundsatz: So einfach als möglich.
Ein Ton-Pausen-Paar endet definitionsgemäß mit einer Pause. Wäre das nicht der Fall, so sollte sowohl der Server als auch jeder Client diese „Protokollverletzung“ sinngemäß auflösen.
Ändert ein Teilnehmer seine Betriebsfrequenz, so zeigt er dies dem Server durch „Frequency Change“
(FC) an. Der Server verteilt diese Information wiederum an alle Clients, die bitte reagieren sollen.
Das Vorgehen sollte synchron erfolgen. Ein client-seitiges Fifo wirkt da Wunder…
Verlässt ein Benutzer das Band, so sendet er ein „User Deleted“ (UD) oder er baut einfach die TCPVerbindung ab.
Der Server sendet an die verbleibende Gemeinde das passende UD–Telegramm mit dem korrekten
Index des Verschollenen. Jeder Client muss daraufhin seine Liste wieder aktualisieren.
Das war’s auch schon.
Ausblick
Wir haben hier weder eine neue Betriebsart noch eine neuartige Technologie. Das wäre viel zu weit
gegriffen! Es ist nicht einmal ein Projekt. Mit Augenzwinkern aufgesetzt, sollte Programmierung und
Benutzung vor allem Spaß machen.
Jedenfalls schlägt es den Bogen von Marconi und Morse hin zum Internet.
Und zur Urheberschaft: Wir haben momentan mehr als sechs Milliarden Menschen auf diesem Planeten, da wird „jeder denkbare Gedanke eben schon einmal gedacht“5, oft an vielen Orten gleichzeitig.
Ob ein anderer vor 2001 bereits die gleiche Idee hatte, tja, dann war es eben so. Gerne werde ich
Referenzen auf andere Arbeiten in das Quellenverzeichnis aufnehmen, das gebietet ja die wissenschaftliche Etikette.
Den Servercode habe ich jedenfalls unter GPL gestellt. Vielleicht motiviert dieser Beitrag den einen
oder anderen meiner Leser, wieder selbst einmal Hand anzulegen.
Jedenfalls würde ich mich freuen, wenn jemand einen Client für LINUX oder für MAC schreiben würde
oder einfach einmal Kontakt aufnehmen würde zu einem Gedankenaustauch unter Funkamateuren.
Anhang
Einzelbeschreibung der Datagramme
Telegramm UC
-
User Clear
Richtung:
Server -> Client
Wirkung auf Client:
Löscht die Liste der die auf dem Server angemeldeten Benutzer (User List).
Wirkung auf Server:
Ignoriert
Hinweis:
Der Usercode-Eintrag ist ohne Bedeutung.
Der Server meldet hier Adresse 0 (Quelle ist Server), d.h. 0x21
Befehl
Usercode
Telegrammende
2
1
1
UC
!
0x0A
Telegramm UD
-
Bemerkung
4 Byte
User Delete
Richtung:
Server -> Client
Wirkung auf Client:
Löscht den Eintrag auf Platz <usercode> und sagt so dem Client, dass sich der betreffende User vom
Server verabschiedet hat.
Wirkung auf Server:
Ignoriert
5
frei aus Friedrich Dürrenmatts lesenswertem Werk „Die Physiker“ zitiert
Hinweis:
Befehl
2
UD
Der <Usercode> Eintrag zeigt den Platz des verschwundenen Users an.
0x22 kennzeichnet den ersten Benutzereintrag.
Usercode
1
2
Telegrammende
1
0x0A
Telegramm UX
-
Bemerkung
4 Byte
User 17 ist gerade verschwunden
User Reject
Richtung:
Server -> Client
Wirkung auf Client:
weist diese Anmeldung ab. Der Server kann die Anmeldung nicht akzeptieren.
Wirkung auf Server:
Ignoriert
Hinweis:
Der Usercode-Eintrag ist ohne Bedeutung.
Der Server meldet 0, (Quelle ist Server) d.h. codiert als 0x21.
Befehl
2
UX
Usercode
1
!
Telegrammende
1
0x0A
Telegramm US
-
Bemerkung
4 Byte
Satz mit X, war wohl nix…
Get Server-side User List
Richtung:
Client -> Server
Wirkung auf Client:
Ignoriert
Wirkung auf Server:
Veranlasst den Server, die User-Liste auszugeben
Hinweis:
Der Usercode-Eintrag ist ohne Bedeutung.
Der Client trägt hier normalerweise die provisorische Adresse 1 d.h. 0x22 ein.
Befehl
2
UL
Usercode
1
“
Telegrammende
1
0x0A
Telegramm UA
-
Bemerkung
4 Byte
User Add
Richtung:
beide
Wirkung auf Client:
Trägt die gemeldeten Daten an den durch <usercode> bezeichneten Platz in die client-seitige User-Liste
ein.
Wirkung auf Server:
Meldet die Daten des Clients beim Server an. Der Client schickt das Telegramm unter dem provisorischen Usercode 1 codiert als 0x22.
Bemerkungen:
Die Frequenzinformation enthält die aktuelle Betriebsfrequenz des Users.
Der Wert <type> definiert den User-Type (siehe oben). Ein Client sollte auf den Eintrag UT_YOURSELF
achten. Damit nennt der Server den Listenplatz (Adresse) des Clients am Server.
Schickt der Client diese Meldung, so wird der Eintrag <user-type> vom Server ignoriert.
Der Name kann bis zu MAXNICKNAME Zeichen enthalten. Die Zeichen müssen ‚druckbar‘ sein.
Befehl
2
Usercode
1
Freq.
Parameter
3+1+n
Type
Name
Telegrammende
1
UA
“
!!!
“
HUGO
0x0A
UA
2
!“5
#
ANTON
0x0A
Telegramm FC
-
Bemerkung
8+n Byte
Meldet User-Daten des Benutzers HUGO auf
Frequenz 0 Hz (Bandanfang) an den Server
(von Adresse 1)
Der Server meldet, dass User 17mit dem Namen ANTON auf der relativen Frequenz 100Hz
QRV ist.
Frequency Change
Richtung:
beide
Wirkung auf Client:
Zeigt dem Client die neue ‚Betriebsfrequenz‘ des durch <usercode> bezeichneten Users an.
Wirkung auf Server:
Meldet die geänderte Betriebsfrequenz des Clients beim Server an. Der Client schickt das Telegramm
unter dem provisorischen Usercode 1 codiert als 0x22.
Befehl
2
Usercode
1
Parameter
3
Telegrammende
1
FC
“
!!!
0x0A
Telegramm TP
-
Bemerkung
7 Byte
Meldet neue Frequenz (0 kHz) an den Server (provisorischer Usercode 1)
Tone/Pause
Richtung:
beide
Wirkung auf Client:
Trägt die gemeldeten Daten an den durch <usercode> bezeichneten Platz in die client-seitige User-Liste
ein.
Wirkung auf Server:
Meldet die Daten des Clients beim Server an. Der Client schickt das Telegramm unter dem provisorischen Usercode 1 codiert als 0x22.
Befehl
Usercode
Telegrammende
Telegrammende
2
1
4*n
1
Bemerkung
4 + 4*n Byte für n Ton/Pause-Paare
Ton/Pause-Paar
TP
“
Ton
Pause
“$
4%
0x0A
User-Type
Die Codes werden im Verlauf der Verbindung zur Beschreibung benutzt, von wem die Daten stammen
bzw. wozu sie bestimmt sind.
Codierung
Code
Bemerkung
UT_NONE
0
Ungültig, nicht benutzt
UT_YOURSELF
1
Der Datensatz ist für Dich selbst, lieber Client
UT_USER
2
Der Datensatz kennzeichnet einen anderen ‚normalen‘ Benutzer
UT_BEACON
3
Das ist eine server-seitige Bakensendung
UT_BULLETIN
4
Das ist ein server-seitig simuliertes ‚Bulletin-Board‘
Parameter
Die Codes werden im Verlauf der Verbindung zur Beschreibung benutzt, von wem die Daten stammen
bzw. wozu sie bestimmt sind.
Parameter
MAXNICKNAME
MAXSOCKETBUFFER
Default
16
1024
Bedeutung
max. Anzahl Zeichen im „Nick-Name“, d.h. dem Benutzer-Rufzeichen oder NAmen
max. Anzahl Bytes in einem Datagramm
MAXUSER
30
max. Anzahl gleichzeitig aktiver Benutzer (willkürlich festgelegt)
MAXBEACON
5
max. Anzahl gleichzeitig aktiver Bakensender
Abkürzungen und Begriffe
ASCII
American Standard Code for Intermation Interchange. Wohl der bekannteste 7-Bit-Code aus der
Urzeit amerikanischen Fernschreibens. Er ist einfach (gottlob) nicht umzubringen! Es gibt zahlreiche
nationale 8-Bit Erweiterungen, sowie die recht intelligent gemachte Fortführung durch UTF-8.
BpM
Buchstaben Pro Minute: WpM*5
CQ
Allgemeiner Anruf („An Alle“, „Seek You“) in der Morsetelegraphie
CW
Continous Wave. Aussendung eines konstanten Trägersignals. Oft synonym für Morsetelegraphie
benutzt. In der Morsetelegraphie erfolgt die Aussendung des Trägers im Rhythmus der Zeichen.
EloKa
Elektronische Kampfführung
GPL
(GNU) General Public License.
HF
High Frequency. Hochfrequenz
IP
Internet Protocol. Unterstes Übertragungsprotokoll für Daten im Internet. Höhere Protokolle wie TCP
und UDP bauen darauf auf.
QRM
internationale Q-Gruppe für „Störung durch Fremdsender“ (Man-made interferences)
QRN
internationale Q-Gruppe für „Atmosphärische Störung“ (Natural interferences)
QSO
internationale Q-Gruppe für „Funkverbindung“
SSB
Single Side Band (Modulation). Einseitenbandmodulation. Wird häufig zur Sprachübertragung auf
Kurzwelle benutzt.
TCP
„Transmission Control Protocol“. Es ist ein verbindungsorientiertes Protokoll des IP-Stacks. Die
beiden Endpunkte sind wie durch eine Leitung miteinander (logisch) verbunden. Es besteht Schutz
gegen Datenverlust. Keine kryptologische Funktion. Größerer Overhead.
UDP
„User Datagram Protocol“. Es ist ein verbindungsloses Protokoll des IP-Stacks. Kein Schutz gegen
Datenverlust. Keine kryptologische Funktion. Geringer Overhead.
UTF-8
8-bit Unicode Transformation Format. Codierungsvorschrift für UNICODE-Zeichen, die neben den
lateinischen auch kyrillische, hebräische, arabische, koreanische etc. Schriftzeichen enthält. UTF-8
codierte Zeichen können bis zu 4 Byte umfassen und können durch das trickreiche Codeschema bis
zu 1.114.112 Bedeutungen besitzen.
WpM
Wörter Pro Minute: Bpm/5
VFO
Variable Frequency Oscillator. An diesem stellt man am Empfänger die Betriebsfrequenz ein.
VoIP
„Voice over IP“; Technik zur Übertragung von Sprache über das Internet
AJAX
Asynchronous Javascript and XML. Eine „Technologie“ aus dem Bereich WebseitenProgrammierung die unter Anwendung dieser Sprachen Webseiten nur an den notwendigen Stellen
„asynchron“ aufdatiert.
DNS
„Domain Name Service“; Internet-Dienst, der Domain-Namen in IP-Adressen umschlüsselt.
HTML
Hypertext Markup Language. Sprache zur Beschreibung von Inhalten im Internet.
HTTP
Hypertext Transfer Protocol. Protokoll oderhalb von TCP. Meist genutzt zur Übertragung von HTMLInhalten.
LAMP
Linux, Apache, MySQL, PHP. Eine „Technologie“ aus der LINUX-Welt, die Web-Seiten unter Anwendung eben dieser Programmpakete dynamisch macht.
XML
Extensible Markup Language. HTML-ähnliche Codierung strukturierter Daten.
Private IP-Adressen
Private IP-Adressen können folgenden Bereichen entnommen werden. [IPADR]
Adressbereich
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Quellen
[MKURS]
Müller, Alfred, DL1FL; „Morsekursus des Deutschen Amateur Radio Club e.V.“; 6. Auflage; DARC e.
V., Baunatal
[DJ2PJ]
Teichmann, H.J.; „Morsen“; ehemals Frack-Kosmos, Stuttgart. Häufig zitiert.
[IPADR]
http://de.wikipedia.org/wiki/Private_IP-Adresse