QSP Vermittlung QTC und QUA

Hi,

Mir schwirrt schon ne weile eine Idee im Kopf rum, wie man Mail und Kurznachrichtenverkehr
ala PSKMail etwas effizienter, mit weniger Hardwareaufwand und deutlich mehr Spaß betreiben
kann. Zum Beispiel in Telegrammform, und zwar gezielt. Also wenn ich ne Nachricht bekomme,
bekomme ich die sobald ich das nächste mal am Funkgerät bin, und ich kann antworten wem
auch immer ich antworten will.

Beispiel nehmen wir mal an der EA6/OE1SRC/p führt ein QSO mit DF2OK (sorry dein call ist mir grade so
eingefallen, es ist nur beispielsweise!) Nach dem Austausch des (langweiligen) rapports von 599 eventuell
noch der Namen: Michael und Hans und den Stationsdaten, passiert folgendes:

Michael hat mich bereits geloggt und gibt mir aufgrund der Daten in seinem Logbuch ein:

EA6/OE1SRC/p de DF2OK - QTC 2 - QUA OE1XGB Hallo Hans, gd frm wagenplatz gaensebluemchen, hier ist alles ruhig. wann bist du wieder in wien? - QUA OE1MVA habe qrl muss montagrunde plus 1h verschieben - hw? EA6/OE1SRC/p de DF2OK

DF2OK de EA6/OE1SRC/p - QSL 1 2 - QTC 2 - QAS OE1MVA QSL montagrunde plus 1h - QAS OE1XGB hallo zusammen, ich hoffe euch gehts gut, wx sonnig, bin in zwei wochen wieder da - DF2OK de EA6/OE1SRC/p

Michael bestätigt das ich die Nachrichten bekommen habe, und läd die neu aufgenommenen Nachrichten in die Datenbank hoch. Im Idealfall macht das das Logprogramm automatisch, sobald der Call eingetragen ist.

Ich hoffe ich hab die richtigen Q gruppen rausgesucht.

Die Nachrichten wandern in eine öffentliche Datenbank (ala twitter), die im idealfall mit dem jeweiligen Log Programm verbunden ist, die man aber auch, online per Webseite einsehen kann, das heist man kann auch eine beliebige Station bitten da mal reinzusehen. Die eigentliche Funkübertragung geschieht manuell, das heist das geht in CW, PSK31, RTTY und soar in SSB gleichermaßen, und die Portabel station braucht keinen Computer, keine Frequenzlisten, und keine Wartezeit bis die einzige automatische station wieder auf der QRG hört.

Das ist jetzt nur mal so ein Gedanke.....

Feedback? PS: Über Diplome könnte man natürlich auch nachdenken dabei. =)

grüße
Hans

Hi Daniel,

Ohne Zentralrechner geht unter umständen, wenn die Datenbank und das Protokoll entsprechend designed sind. Bis ich eine bessere
Idee habe, bedeutet Multiserver unterstützung das alle Nachrichtenserver exakt den gleichen Datenbestand haben. Und für die Benutzer
selber hab ich grade keine Idee wie ich das machen soll. Oh und ich muss den Servern vertrauen, das die kein mist machen.

Ohne Internet wird das nicht Praktikabel gehen fürchte ich. Die Hams müssen ja auch Zugriff auf die Daten haben.
Die Einzelsysteme müssen untereinander sämtliche Nachrichten und bestätigungen austauschen, und lokal vorhalten.
Bei Multiserver Betrieb müsssen auch doppelte Bestätigungen behandelt werden können. Das bedeutet gewisse Anforderungen
an die Bandbreite und zuverlässigkeit der Anbindung zwischen den Servern, also Hamnet.

Oh und dann gibts call aliase. Also OE1SRC aka DL/OE1SRC aka DD5?? aka EA6/OE1SRC und Clubs, mit Call Sign Managern.

Ganz wichtig ist der Zugriff auf die daten, der muss absolut unkompliziert sein! Am idealsten über eine App, die sich an das
verwendete Log Programm hängt, oder die vielleicht sogar schon im Logprogramm integriert ist, wobei es wurscht sein sollte
ob die App über Internet/HamNet oder PR oder PSK31 kommuniziert. Zusätzlich eine Webseite die alle die jenigen verwenden
können die keine App haben.

Ich hab mir mal ansatzweise Gedanken gemacht welche Daten da so gebraucht werden, alles erstmal völlig undokumentiert:

Datenfelder in der Nachrichten Tabelle:

• ServerID
• MsgNumber
• MsgDate
• DlvryDate
• AccountCall
• DlvryCall
• FromCall
• ToCall
• Message
• LogbookReference

Datenfelder Call Aliases:

• Call
• Alias

Datenfelder Accounts:

• Call
• Email
• Passwd
• LastSeen

Ein registrierter Call kann für beliebige (auch nicht registrierte calls nachrichten verfassen) Wenn kein alias für einen Call hinterlegt ist, wird generisch einer angelegt.

Soweit erstmal....

grüße
Hans

Waren Signaturen im Amateurfunk jetzt eigentlich erlaubt oder nicht? Oder einfach machen?

Hallo Daniel,

Das war zwar auch eine richtige Antwort auf meine Frage, aber nicht die die ich hören wollte. Ich sprach von Digitalen Signaturen, der
QSP.net server untereinander.

Die Idee ist bei der Interserverkommunikation einfach jeden Datensatz zu signieren.
Wenn einer der Server mist baut, wird die Signatur auf die Blocklist gepackt, gleichzeitig gibts eine trusted liste, von Servern
denen ich vertraue. Die Summe aus geblockten, vertrauten und blockaden von Systemen denen ich vertraue gibt einen Index
über den ein System mitsamt seiner Datensetze aus dem Netz fliegen kann. Auf diese weise kann aber jeder ohne aufwand
einen vollwertigen Knoten zufügen.

Die Frage ist, ob eine digitale Signatur als öffentlich zu sehen ist. Man kann sie ja mit dem öffentlichen Public key entschlüsseln,
also lesen und der Algorythmus ist bekannt. Das würde die Möglichkeit bieten, qsp.net systeme auch über AFU-leitungen zu
vernetzen. Aber wir haben ja auch D-Star also wird eine Signatur wohl kein Problem darstellen.

Ein Server muss mindestens zwei Schnittstellen liefern, eine für den Transfer zwischen den Systemen, und eine für den Transfer
zwischen Pilotstation und Server.

Tshuldigung wenn ich etwas wirr schreibe, ich bin noch mitten am Brainstormen.

grüße
Hans

Es wächst langsam, im kopf.

Dezentrales Automatisches Verteilernetzwerk - Signaturgeschützt per OpenSSL - Flexible Clients per XMLRPC angebunden - Callsign aliasses - Bulletin Lists.
Ich schreibs grad in ein großes TXT File damit ich nix vergesse, oder übersehe.

Ich nehm mir mitte März ein bis zwei Wochenenden Zeit für die Implementierung, das solte reichen um was vorzuzeigen, aber ich werd mich da im Zeitaufwand wieder Grandios verschätzen. also einen DB server XMLRPC Schnittstelle Interserver Kommunikation, erstmal SQLite basiert.

Ich brauch noch nen Namen / Domain. Hat wer Ideen? qsp.net ist ja schon weg.

Ich bin nicht besonders Fit was Webdesign angeht, also wenn sich wer am Frontend vergnügen will, kann er das gerne tun, ich werde sonst
quickndirty was hinbauen, sind ja nur 3-4 Basis Dialoge, das sollte mit einem CGI noch machbar sein. Hauptsache ist erstmal was benutzbares
zu mit den Basisfeatures bekommen. =)

Feedback? Ein "Gibts schon, schau mal: da!" hör ich übrigens auch gerne.

gruß
Hans

EDIT: Ich hab ne webseite angefangen noch nicht viel, ein Visio und ein ewig langes Text File bis jetzt http://www.fnordpol.de/qtc

Es gibt derweil eine Webseite: http://www.qtc-net.org
den Quellcode gibts auf GitHub: https://github.com/zem/qtc-net

Nach kurzer Absprache mit OE1GIS haben wir uns auf die Wordings: Telegram und Message geeinigt.

- Ein Telegramm ist die eigentliche Nutznachricht (300 Zeichen Teloegrafierbar) die übermittelt werden soll.
- Eine Message ist das was im QTC Netz veröffentlicht wird, also auch Steuerungsnachrichten und sowas.
- Eine gültige Message wird im Netz Veröffentlicht und kann damit verbreitet werden.

Ein erstes Telegramm hab ich auf meinem Rechner lokal schon versendet und bestätigt bekommen.

Zur Zeit baue ich an einem Binärformat für die Nachrichten, nur falls wer auf die Idee kommen sollte
qtc Messages über HF zu veröffentlichen. Ursprünglich hab ich da XML verwendet, das produziert
nur leider Traffic und ist nur begrenzt signierbar, jedenfalls nicht so das man die Daten in einer Datenbank
oder einem objekt abspeichern kann und hinterher wieder genau so ein XML zusammengesetzt bekommt. Das
gleiche Problem trifft auch für Hilfsformate wie Base64 zu. Selbst ebml hat (dank des headers) noch zuviel
overhead also werd ich wieder mal Cherry Picking betreiben.

Also es bewegt sich was...

grüße

Hans

Hi,

http://www.qtc-net.org/

ist gestartet! *froi* das ist ne pre alpha
und nur das Webfrontend soweit, und ich hab sicher irgendwo einen Bock geschossen.
aber wurscht, es rennt mal!

beschäftigt euch doch mal damit es ist mehr als nur das offensichtliche web-frontend

73 Hans

Ahoi,

Grade hab ich die letzten Zeilen Code für den APRS Gateway geschrieben. Ich muss noch ein paar Tests machen, und vermutlich ein paar dinge reparieren, und dann kann der starten. Der Vorteil ist: Mit dem QTC-Net APRS Gateway werden auch APRS
Nachrichten zugestellt wenn der empfänger sein Funkgerät nur
vorrübergehend eingeschaltet hat, und der Sender sein Funkgerät längst
ausgeschaltet hat.

Der Intensivtest erfolgt dann während meines Englandurlaubes vom 23.5. -3.6. wo ich unter M/DD5TT arbeiten werde. Ich freue mich über Mitteilungen und Urlaubsgrüße.

Ich hab ne liste eingerichtet: qst/dx/m wo ich oefter mal updates und infos hinsenden werde. Ich freue mich über Antworten.

grüße
Hans

Es tut sich was.... derweil habe ich timelines im Netz so das QTC Telegramme ähnlich zu wie tweets in ein Blog wandern
können siehe http://blog.fnordpol.de/ ganz rechts.

Den APRS-Gate gehe ich mit einem Struktur enhancement nochmal an. Im Augenblick müssen sich die APRS Gateways auswürfeln wer
die QTC Nachricht veröffentlicht. Wenn alle APRS Gates für eine Nachricht innerhalb eines Zeitraumes die selbe Prüfsumme erzeugen
brauchen sie sich die Gates nicht mehr gegenseitig zu unterhalten.

Ich plane ne PSK Mail unterstützung zu bauen in zwei wochen.

Edit: Und gegen die mindestens 1024 bit langen RSA Signaturen habe ich auch wohl eben eine Lösung gefunden, wenn ich richtig gelesen habe.

Es geht weiter....

Ich hab mittlerweile ein auf Linux installierbares packet geschnürt, das entspannt auf hardware wie zum Beispiel der eines RaspberryPI vergessen werden kann.
Nicht mehr benötigte Nachrichten wandern nach 200 Tagen zunächst in ein /old Verzeichnis und dann weitere 200 Tage später wird die Nachricht dann gelöscht.

QTC Net kann seit neuestem auch Threads, und hin und wieder purzelt eine APRS message rein, zuletzt von Mike, oe3mzc-9. Store n Forward von APRS Kurznachrichten
ist ja sozusagen ein abfallprodukt von QTC-Net.

Ich glaube ich habs bald soweit das ich den Admins auch zutrauen kann QTC-Net neben den gepatchten DXSpider und PSKMail Servern zu installieren.
grade denke ich darüber nach wie man so ein Netz über funk effizient syncronisieren kann ohne dabei eine Punkt zu Punkt aussendung machen zu müssen.
Erste Hochrechnungen haben heute morgen ca 811 bits pro sekunde für so eine Syncronisation unter wiedrigen umständen errechnet. Also vielleicht kann man
QTC-Net Knoten sogar über ein bis zwei PSK 500 Verbindungen auf HF syncronisieren wenn man sich geschickt anstellt.
Eine Codebasis für sowas ist jedenfalls mal da.....

Was das alles bringen soll?
Naja, wann immer ein System welches auch immer eine Telegram-Nachricht an ein Call hat, kann es die einfach auf dem nächsten QTC-Net
Knoten veröffentlichen, die QTC-Net Knoten verteilen diese Telegramm-Nachrichten dann untereinander. So kann eine Nachricht von jedem Knoten
abgerufen und wenn möglich zum Empfänger weitervermittelt werden.

Wenn ein Knoten mal ne Weile ausfällt, syncronisiert er sich halt nach, es geht keine Nachricht verloren, damit ist QTC-Net vermutlich auch für den
Katastrophenschutz sehr interessant.

grüße
Hans

Hab einen Netzknoten im HamNet aufgebaut erreichbar unter http://qtc.oe1.ampr.at/ sowie zur syncronisation unter http://qtc.oe1.ampr.at/qtc-if.cgi

Außerdem rennt ein gepatchter DXSpider auf telnet://qtc-net.org:7300 der zu jedem gespotteten Call anzeigt ob es neue QTC Net Telegramme gibt. Natürlich kann man auch von dort telegram-nachrichten verschicken und empfangen.

Per Web kommt man über https://www.qtc-net.org/ ans QTC Net (ich habe es allerdings immernoch nicht fertiggebracht das Zertifikat zu reparieren, bevor fragen kommen)

grüße
Hans