Hallo Knut, \r\n\r\nAusgekoppelt aus dem Vorstellungsthread..... \r\n\r\n

DC7FL schrieb: \r\nDu hast richtig erkannt, daß es eigentlich am ARRS liegt, wenn Nachrichten nur bei beidseitiger Verfügbarkeit übermittelt werden.\r\nDann sollte man doch dieses auch via APRS ausbügeln und nicht andere Programme verbiegen.

\r\n\r\nDito, hier kommen die doch etwas unterschiedlichen Ansätze von QTC und APRS zum Tragen.\r\n\r\nAPRS ist ein Echtzeit Reporting System, eher mit einem Live Chat zu vergleichen, während QTC vom Aufbau her eher mit Instant Messagern zu vergleichen ist.\r\n\r\nDamit APRS Store so ein and Forward macht müsste man mindestens mal eine Datenbank ähnlich der der eines QTC Processors bauen, damit hast du schon zu 90 % QTC Net, die Konfiguration und die Vermittlung von Telegrammen als Aliases und Listen wird innerhalb des QTC-Net ebenfalls durch Messages bewerkstelligt, die auf dem Knoten gezielt abrufbar sind. \r\n\r\nEin rein APRS Basiertes Verfahren währe natürlich auch einfach einen \r\nsyncronen Eintrag in so eine eine eigene Datenbank zu schreiben. Aber: \r\n\r\nZum einen existiert QTC-Net bereits und es implementiert so nebenbei auch eine Signaturinfrastruktur als Zugangskontrolle die bedeutend besser ist als ein Kennwort das man aus dem Callsign herraus errechnen kann. Wir sind ja ein Experimentalfunk, es ist in keinem Gesetz verboten im Funk mit elektronischen Signaturen zu experimentieren. \r\n\r\nZum anderen kann ich über diese Art der QTC-Net Vermittlung auch einen lokalen Nachrichten aufnehmen und bestätigen und so verhindern das die GATEWAYS immer den kompletten APRS Traffic mit allen Bakenmeldungen verarbeiten müssen sehen. \r\n\r\nEine Nachricht von europa nach übersee zum beispiel kann dann ganz elegant über QTC verbreitet und syncronisiert werden. Ob das einen Vorteil bringt weis ich nicht, ich habs so jedenfalls gelöst.\r\n\r\nDie QTC net Server syncronisieren sich vollständig aber nicht in Echtzeit, das heist wenn es mal einen Netsplit (zwei Teilnetze) geben sollte, gehen keine Daten verloren. Die Informationsunterschiede beider Teilnetze werden bei der nächsten Verbindungsmöglichkeit wieder zusammengebracht. Bei APRS verlierst du halt ein paar Informationen AFAIK. \r\n\r\n

\r\nWenn z.B,. unter QTC_NET ein Überprüfungsverfahren aktiviert werden kann, das die Verfügbarkeit via PING testet und dann die Nachricht zustellt,hat man doch schon gewonnen.

\r\n\r\nDu brauchst da im APRS nix pingen, die Stationen melden sich schon von selbst wenn sie on air sind, da kenne ich bislang keine Ausnahme. \r\n\r\n

\r\nUm seine Nachricht durch dieses Verfahren verwaltet zu wissen, eignet sich eine Zeichenkombination am Beginn der Nachricht, die vom QTC_NET dauernd geprüft wird.

\r\n\r\nIm Augenblick läuft das so: \r\n\r\nWenn eine APRS mit Ack gesendet wird, würfeln die APQTC1 gateways untereinander aus, wer die APRS ins qtc net stellen darf, die höchste prüfsumme gewinnt. Freigeschaltet wird das ganze durch Konfiguration des Calls im QTC-Net, und gecancelt wird das Würfelverfahren sobald ein Ack da ist. \r\n\r\nDas braucht ungefähr eine Minute, wenn die Nachricht bis dahin nicht bestätigt wurde, wird sie ins QTC net gestellt und ein Ack dafür versendet, um den Timer auf dem APRS Client zu canceln, ab hier ist das QTC-Netz verantwortlich für die Zustellung. \r\n\r\nSobald ein APRS Gate einen call sieht für den Nachrichten vorliegen, werden diese zugestellt. Bei Empfang des Acks werden die zugehörigen QSPs im QTC Net veroeffentlicht. Da der Weg QTC2APRS genormt ist, kommt von allen QTC Gates das gleiche, was die Loop Detection von APRS dann passend filltern sollte. (muss noch getestet werden) \r\n\r\nIch hoffe ich hab da jetzt keinen Denkfehler aber bis dahin schauts aber schonmal gut aus in meinen Tests. \r\n\r\n

\r\nAber vielleicht sollte dieses Thema in die entsprechende Rubrik verschoben werden...\r\n

\r\n\r\ndone. \r\n\r\nWahrscheinlich werfe ich mit dieser wirren Mail doch mehr neue Fragen auf als ich Beantwortet habe, ich freu mich jedenfalls schon auf die Diskussion. \r\n\r\ngrüße \r\n\r\n Hans