Entgegen der anfänglichen Befürchtung des OP ist dies keine dumme Frage; es ist eigentlich ein sehr gutes. Die meisten Antworten, die dieser Beitrag erhalten hat, sind ziemlich falsch, und in dieser Gruppe bedeutet das, dass Sie eine Frage gestellt haben müssen, die auf einer Reihe wirklich technischer Grundlagen beruht. Also großes Lob!

Der gemeinsame Fehler

Der häufigste Fehler bei den bisherigen Antworten ist, dass sie sich auf das beziehen, was gemeinhin als „Layer 3“-Protokolle oder sogar richtige „Layer 2“-Protokolle bezeichnet wird . Um die Antwort zu verstehen, müssen wir verstehen, warum dies die falsche Betrachtungsweise des Problems ist.

In der heutigen terrestrischen (und in geringerem Umfang orbitalen Satelliten) Netzwerkinfrastruktur durchlaufen Daten, die von einem Computer übertragen werden sollen, den folgenden Prozess (auf hoher Ebene):

1. Der Datenstrom wird identifiziert
2. Der Datenstrom wird vom Sender in Übertragungssegmente zerlegt
3. Die Segmente sind in einem "Layer 3"-Paket eingekapselt (verpackt), das alle notwendigen Quell-/Ziel-/Errata-Informationen bereitstellt, die erforderlich sind, um das Paket durch eine große Anzahl von Netzwerksegmenten routen zu können
4. Die Pakete werden in einen „Layer 2“-Rahmen gekapselt (verpackt), der Informationen über Quelle, Ziel, verwendetes Protokoll und andere Errata enthält. Diese Kapselung definiert, wie der Frame durch ein einzelnes Netzwerksegment geleitet wird.
5. Nachdem das Framing ausgearbeitet ist, wird das Paket auf dem Draht (oder drahtlos) codiert. Diese Codierung definiert beispielsweise, wie eine „1“ von einer „0“ zu unterscheiden ist. Also "Hochspannung = 1", "Niederspannung = 0" und ähnliches.

Das kontextuelle Problem hier, das diese Betriebsmethode zunichte macht, besteht darin, dass Sie über sehr NIEDRIGE Datenströme mit vermutlich relativ wenigen kommunizierenden Zielen sprechen. Nach Ihrer Prämisse sprechen Sie auch von einem bekanntermaßen verlustfreien System, bei dem Quelle und Ziel bereits im Voraus bekannt sind. Das sind nicht die Erwartungen und Situationen, auf die die Protokolle zugeschnitten sind, denen die meisten Menschen täglich ausgesetzt sind.

Die Lösung

Wenn Absender und Empfänger im Voraus bekannt sind und ein Verlust kein Problem darstellt, gibt es überhaupt keinen Grund, sich um eine Kapselung zu kümmern. Alles, was Sie zu diesem Zeitpunkt benötigen, ist eine Codierungsmethode wie Manchester Encoding . Codierungsmethoden definieren grundsätzlich, was eine 0 und eine 1 ist (sowohl in Zeit als auch in Amplitude) und bieten Systemen einen Mechanismus, um sicherzustellen, dass sie sich beide auf derselben Seite befinden.

Um die Dinge einfach zu halten, würde ich wahrscheinlich nur die Manchester-Codierung verwenden, wie sie in vielen der heutigen Kabelverbindungen verwendet wird. Ja, es gibt andere Arten der Codierung, die für bestimmte Übertragungseigenschaften besser funktionieren, aber angesichts Ihres „sofortigen/fehlerfreien“ Portalbereitstellungssystems können wir meiner Meinung nach ein ziemlich gutes Analogon dazu ziehen, dass dieses Portal nur einem unendlich kleinen Segment entspricht eine kabelgebundene Netzwerkverbindung.

Beachten Sie auch

Wenn Sie Daten haben, die Sie verwenden möchten, um Ihre Informationen an ihr endgültiges Ziel zu leiten, sollten Sie dies aufgrund der sehr langsamen Geschwindigkeiten besser Protokollen auf höherer Ebene (Nicht-Netzwerk) überlassen. Ihre Datenübertragungsgeschwindigkeit ist so trivial langsam, dass es sehr wenig bedeuten würde, wenn Ihre Geräte an beiden Enden den vollständigen Datenstrom wieder zusammensetzen und die präsentierten Daten analysieren würden, um zu verstehen, wohin sie geleitet werden sollten.

Und nein, das bedeutet nicht, zum Beispiel auf ein BILD zu schauen und zu verstehen, was Bilder bedeuten – Computer haben viele höhere Protokollsprachen, die Benutzer nie sehen. Solche Informationen könnten beispielsweise als Teil eines XML-Pakets enthalten sein. Über die technischen Details würde ich mir jetzt aber noch keine Gedanken machen.

Asynchroner Übertragungsmodus (ATM)

Ich mag die beiden anderen Antworten, aber ich denke, angesichts des Problems ist ATM eine bessere Lösung. Eine TCP/IP-Schnittstelle ist am besten für ein verteiltes Netzwerk, aber die Frage spezifizierte Punkt-zu-Punkt-Kommunikation. Interne Computerübertragungsbus-'Protokolle' haben nicht die gleiche robuste Fähigkeit, verschiedene Kanäle eingehender Informationen zu einem Strom zusammenzuführen, und die Prüfsummen, um eine korrekte Lieferung sicherzustellen.

ATM wurde im allgemeinen Gebrauch durch TCP/IP mehr oder weniger ausgelöscht, weil letzteres besser für verteilte Netzwerke ist, aber ATM wird immer noch in Satellitennetzwerken verwendet. Tatsächlich ist dies genau die Anwendung, die für Ihre Situation am besten geeignet ist.

Um es einfach zu erklären: Wenn ein Schiff auf See mit dem Rest des Internets kommunizieren möchte, verwendet es ATM, um TCP/IP-Pakete über einen Satelliten an einen Hub an Land zu senden. Der Satellit führt mehrere mögliche eingehende ATM-Streams zusammen, die von Schiffen kommen, und sendet sie zurück zum Hub, wo die Pakete aus dem ATM-Stream herausgenommen und auf ihrem fröhlichen Weg über das reguläre Internet gesendet werden.

Es steckt noch viel mehr dahinter, wenn Sie auf Wikipedia oder der Spezifikation nachlesen möchten . Aber ich kann mir vorstellen, dass dies die Fähigkeit ist, die Sie sich für die FTL-Kommunikation vorstellen.

Bearbeiten:

Ich wollte meine Antwort ein wenig präzisieren. ATM ist ein Schicht-2-Protokoll und TCP/IP ist ein Schicht-3/4-Protokoll. Es gibt also keinen Grund, warum sie nicht zusammen verwendet werden können. Mein Punkt ist das Protokoll von Interesse, das am besten für die FLT-Kommunikation geeignet ist, z. B. ATM, und Sie können entweder IP oder etwas anderes senden, das für niedrige Bandbreiten besser geeignet ist.

Edit2:

Weitere Reaktionen auf Kritik. Ich habe den ersten Abschnitt über Busprotokolle bearbeitet, um zu zeigen, was sie nicht können, was sie meiner Meinung nach tun müssen.

Auch @Navin; Sie wollen ein L2-Protokoll, weil Sie mehr als einen Träger haben werden, der zwischen zwei verschiedenen Sternensystemen hin und her geht. Warum bei einem Träger mit 10 Byte/s bleiben, wenn Sie 10 Träger mit dieser Geschwindigkeit installieren könnten? In diesem Fall müssen Sie Ihre Pakete auf mehrere Träger aufteilen und dann am Zielort wieder zusammenführen. Das macht der Geldautomat. Sie möchten immer noch, dass ein L3-Carrier Ihre Nachricht über möglicherweise Millionen von Netzwerkknoten am Zielort verteilt.

Wenn Sie auf diese Weise übertragen, wird ein 50-Byte-ATM-Rahmen auf einem Träger in 5 Sekunden übertragen; ein 9000-Byte-Ethernet-Frame in 15 Minuten. Das bedeutet, dass eine in 20 Frames aufgeteilte 1000-Byte-Nachricht in 10 Sekunden auf 10 verschiedenen Trägern mit ATM übertragen werden kann, während eine 1000-Byte-Nachricht in einem 1000-Byte-Frame in 100 Sekunden übertragen wird. Sicherlich können Sie den Vorteil einer kleineren Framegröße gegenüber einer Anwendung mit geringer Bandbreite erkennen.

Dies ist eine Punkt-zu-Punkt-Kommunikation, sodass Sie sich nie mit dem
Routing-, Timing- und Prüfsummen-Overhead von Netzwerkpaketen herumschlagen müssen. Wenn die ftl-Übertragung verloren geht oder beschädigt wird, möchten Sie möglicherweise eine Fehlerkorrektur und eine Vorstellung von der Verbindungsausrichtung. Anstatt eine vorhandene Technologie wiederzuverwenden, sollten Sie Ihr Protokoll auf das tatsächliche Beschädigungs- und Verlustprofil Ihres neuen Mediums abstimmen.

Die wichtigste Einschränkung ist hier die unerträglich langsame Übertragungsgeschwindigkeit. Sie würden die Menge an Nicht-Nachrichten-Overhead minimieren (oder vollständig eliminieren) und die bestmögliche Komprimierung verwenden. Wenn Sie Routing- oder Zustellinformationen senden müssen, verwenden Sie wahrscheinlich eine Hash-Tabelle und senden den Hash des Ziels anstelle der vollständigen Zustellinformationen. Ein Kommentar unten erwähnt TDMA, was ein interessanter Gedanke ist. Angesichts der maximalen Bandbreite der verschränkten Photonen (oder was auch immer) könnte es sinnvoll sein, mehrere Kanäle zu bündeln.

Wenn es von A nach B geht, ohne Mittelsmann und praktisch garantiert ohne Datenverlust/-beschädigung oder -unterbrechung, haben Sie es im Grunde mit der gleichen Denkweise bei der Kommunikation zwischen internen Computerkomponenten zu tun , nur viel, viel, viel langsamer. Es gibt kein Netzwerkübertragungsprotokoll zwischen der CPU und dem Plattenlaufwerk, weil Sie einfach keins benötigen.

Da diese Gesellschaft über diese Technologie verfügt, gehe ich davon aus, dass sie sich auf unserem Niveau der allgemeinen Rechenleistung befinden oder (realistischer) darüber hinaus. Das bedeutet, dass bei dieser langsamen Geschwindigkeit der Engpass schmerzlich offensichtlich die Übertragung ist, nicht die Computer auf beiden Seiten.

Sie sollten sich auf die Datenkomprimierung (nicht Übertragungsprotokolle) und ein Markup konzentrieren, das hilft, Metadaten zu reduzieren. Das Konzept hinter MessagePack erscheint Ihnen recht passend:

MessagePack ist ein effizientes binäres Serialisierungsformat. Damit können Sie Daten zwischen mehreren Sprachen wie JSON austauschen. Aber es ist schneller und kleiner. Kleine Ganzzahlen werden in ein einzelnes Byte codiert, und typische kurze Zeichenfolgen erfordern nur ein zusätzliches Byte zusätzlich zu den Zeichenfolgen selbst.

Sie werden hier nicht aufhören wollen, aber denken Sie in diese Richtung. Sie können die Effizienz auch erweitern, wenn Sie wissen, welche Art von Datenverkehr Sie über diese Verbindung schieben, und die CPUs auf der Empfangsseite können von der Basislinie extrapolieren, ähnlich wie bei Vektorgrafiken (einige Definitionen werden verwendet, um das größere Konzept zu berechnen).

Ihre beste Lösung wird ein proprietäres Format sein, da Sie keine Kompatibilität benötigen, sondern nur Effizienz.

„Datenpakete“ sind ein Konzept, das auf Netzwerke angewendet wird, wenn Daten um und durch mehrere Geräte geleitet werden müssen, um ihr Ziel zu erreichen; zB ein Netzwerk oder das Internet. Wenn es sich nur um eine Punkt-zu-Punkt-Kommunikation handelt, ist es wie eine serielle Verbindung (wie Drucker/Tastaturen der alten Schule) und muss nicht paketiert werden.

Jedes moderne Protokoll kann mit langsamen Übertragungsraten umgehen, wenn es dafür konfiguriert ist , daher sind einige Bytes pro Sekunde für TCP/IP oder UDP brauchbar, solange die "Lebensdauer" hoch genug ist; Ihre Bedürfnisse bestimmen das spezifische Protokoll.

TCP/IP und UDP eignen sich für große Maschennetzwerke, da sie alle Adressierungsinformationen enthalten, die erforderlich sind, um von überall nach überall zu gelangen, wenn es eine große Anzahl von Zielen und Routern gibt. Wenn Sie es mit einem kleinen Netzwerk mit nur wenigen Computern zu tun haben, gibt es effizientere Protokolle.

Für eine direkte Verbindung, bei der ein Computer nur mit einem anderen Computer kommuniziert, ist ein Paket nicht optimal, da ein Teil der Übertragung durch Adressinformationen belegt wird. Bei Punkt-zu-Punkt kann die Adresse angenommen werden.

Nachtrag zu "TCP-IP/UDP-Verlust":

Das TCP-Protokoll hat etwas eingebaut, das als "garantierte Zustellung" bezeichnet wird, was bedeutet, dass jedes gesendete Paket das Ziel erreicht .... schließlich. UDP übernimmt diese Garantie nicht. Paketverlust tritt nicht nur bei der Übertragung auf, obwohl es üblich ist (ish); Router können abstürzen oder überlaufen und das Paket, das sie zur Übertragung festgehalten haben, kann verloren gehen, oder ein verirrtes Photon kann den Mikrochip treffen, in dem es gespeichert ist, und ein wenig umkippen, wodurch die Daten beschädigt werden. Korruption und Verlust passieren nicht nur bei der Übertragung.

Der Teil „Garantierte Zustellung“ bedeutet, dass, wenn ein Paket fehlt, das individuell nummeriert ist (Teil des Overheads, den diese Pakete in Bezug auf Daten verursachen), der Empfänger zur Quelle zurückkehrt und anfordert, dass das Paket erneut gesendet wird . Dies ist gut, wenn Sie alle Daten vollständig haben MÜSSEN. Dies ist schlecht für die Netzwerkbandbreite.

UDP- oder verbindungslose oder "keine Garantie"-Stilprotokolle sind das, was Sie verwenden, wenn Sie Daten streamen (z. B. YouTube). Es würde das Netzwerk zerstören, wenn Sie jedes Bit des letzten Frames der Animation, das Sie verpasst haben, holen müssten, und an diesem Punkt spielt es sowieso keine Rolle. Sie verlieren auf diese Weise auch nicht so viele Pakete, und es ist auf der Bandbreitenseite viel einfacher, Daten zu übertragen.

Bei diesen beiden handelsüblichen Protokollen haben Sie es jedoch mit über 60 Byte allein für die Header-Informationen in jedem Paket zu tun. Dies kann ein erheblicher Teil der Zeit sein, die für ein einfaches Punkt-zu-Punkt-Gespräch benötigt wird, insbesondere wenn die Daten in Tausende von Paketen aufgeteilt werden.

Für solch niedrige Datenraten würde ich mir alte Techniken im seriellen Stil (COM-Port) ansehen und sie auf die Kommunikation von einem Computer zu einem Computer beschränken (selbst wenn Multi-Talking verfügbar wäre), und wenn Sie nur ein Netzwerk benötigen Verwenden Sie ein Standardnetzwerk zwischen diesen FTL-Computern.

Unterscheidet es sich von den Anfängen des Internets - in einem anderen Sinne, wäre es möglich, mit allen Protokollen umzugehen, die jemals im Bereich der Computernetzwerke entwickelt wurden?

Nein, das ist grundsätzlich nicht möglich.

Ein Protokoll ist eine Reihe von Regeln, die definieren, wie ein Ding mit einem anderen Ding auf standardisierte Weise kommuniziert . Das können zwei Teile einer Anwendung auf demselben Computer sein (z. B. sendet ein Teil meiner App Daten an einen anderen Teil, indem JSON in einer Datei gespeichert wird), oder es können zwei völlig unterschiedliche Maschinen in verschiedenen Teilen der Welt sein (z Zum Beispiel kann ich hier in Großbritannien eine E-Mail an meine Freunde in Neuseeland senden, weil jemand POP und SMTP definiert hat - einige E-Mail-Protokolle).

Grundsätzlich können Sie mit nichts in irgendeiner Form kommunizieren, es sei denn, Sie haben ein definiertes Protokoll. Das muss kein niedergeschriebenes, RFC-nummeriertes, IETF-genehmigtes, MDN-dokumentiertes Protokollprotokoll sein, aber es ist immer noch ein Protokoll.

Also: Nein , Sie müssen ein Netzwerkprotokoll definieren, bevor Ihre Computer miteinander kommunizieren können.

Ein voreingestelltes komprimiertes Datenprotokoll ist genau das, was Sie brauchen. Eine auf Voreinstellungen basierende Komprimierung ermöglicht es dem Absender, Protokolle auszuwählen, die ein festes Wörterbuch basierend auf der Absicht haben. Wenn Sie beispielsweise Text übersetzen möchten, ist es am besten, niedrige Bitzahlen für häufig wiederholten Text zu verwenden. Einige Wörter könnten auch automatisch entfernt werden. Meistens wird das Überspringen eines "the" keine Probleme verursachen, aber es würde einiges sparen. Wenden Sie Huffman oder eine ähnliche Codierung auf viele Klartextdokumente an, um das Wörterbuch zu erhalten. Da Wörterbücher sehr groß sind, sollten Sie sie am besten nicht erneut senden. Etwas Ähnliches könnte für andere Protokolle verwendet werden.

Die Antwort auf diese Frage hängt zu 100 % vom Datenverkehr ab, der über das Netzwerk fließt. Es gibt einen guten Grund dafür, dass wir heute so viele Protokolle haben. Jeder funktioniert gut in seiner eigenen Nische. Wenn Sie eine synchrone Kommunikation benötigen, haben Protokolle wie ATM einen Wert. Wenn Ihr FTL-System ein ähnliches Verhalten wie Glasfaser aufweist, kann SONET nützlich sein. Wenn Ihr System ein Broadcast-System ist, würde beides überhaupt nicht funktionieren, und Sie würden etwas wie 802.11b oder vielleicht eines der anderen drahtlosen Protokolle mit geringerer Bandbreite wie Zigbee verwenden wollen.

Jedes dieser Protokolle, die ich gerade erwähnt habe, wird heute in der einen oder anderen Form verwendet. Jeder wird verwendet, weil er zu den Rollen passt, die er erfüllen muss.

Eine große Frage könnte die militärische vs. zivile Nutzung sein. Wenn Ihr System nur vom Militär verwendet wird, sind Protokolle wie LINK-16 seit Jahrzehnten darauf ausgelegt, in Umgebungen mit begrenzter Bandbreite gut zu funktionieren. In der Zwischenzeit wurden für den Mars Reconnaissance Rover Protokolle ausgewählt, die auf Turbo-Codes aufbauen, weil sie die begrenzte verfügbare Bandbreite optimal nutzen und wir die Ressourcen sparen konnten, die zum Decodieren von Turbo-Codes erforderlich sind.

Erste, große Frage. Zweitens, um den hervorragenden Antworten, die hier bereits vorhanden sind, nicht zu widersprechen oder zu argumentieren, sondern um eine sehr situative Alternative anzubieten: Wenn Sie sich je nach Technologie so etwas wie Quantenverschränkung vorstellen, müssen Sie sich möglicherweise nicht einmal um ein Protokoll kümmern. Wenn Sie sich etwas Traditionelleres vorstellen, was die Kommunikation betrifft, dann hören Sie auf zu lesen. :)

Bei einem QE-ähnlichen System gibt es immer eine direkte Verbindung, die immer aktiv ist, egal was passiert, also könnte "Kommunizieren" eher dem Kopieren einer Datei von einem Teil Ihrer Festplatte zu einem anderen gleichen. Es gibt keine verworfenen oder asynchronen Packs und keine Sicherheitsrisiken insofern, als die Daten von einem Punkt zum anderen übertragen werden. Selbst wenn also an jedem Ende unterschiedliche Software läuft, müssen Sie nur die Rohdaten senden.

Wichtig wäre nur, die Daten angesichts der engen Bandbreitenbeschränkungen auf die kleinstmögliche Größe zu komprimieren. Solange der Komprimierungsalgorithmus an beiden Enden bekannt ist, haben Sie kein Problem.

Auch dies ist nur ein Ansatz für eine bestimmte Art von Szenario.

Unterscheidet es sich von den Anfängen des Internets - in einem anderen Sinne, wäre es möglich, mit allen Protokollen umzugehen, die jemals im Bereich der Computernetzwerke entwickelt wurden?

Es unterscheidet sich absolut von den frühen Tagen des Internets, und hier ist der Grund.

Als das Internet erfunden wurde, waren die Kommunikationsgeschwindigkeiten bereits viel höher als Ihre Spezifikationen, während die Prozessoren viel langsamer waren als heute. Sie beschreiben eine Situation, in der das Verhältnis von (Rechenleistung) / (Bandbreite) ungleich größer ist als je zuvor.

Während es also sicherlich möglich wäre , (viele) bereits erfundene Protokolle zu verwenden, indem man Timeouts anpasst, würde man das in dieser Situation nicht tun. Stattdessen würden neue, für diese spezifische Situation optimierte Protokolle erfunden.

Das FTL-Protokoll v1 hätte ein prägnantes Framing, das HDLC oder Ethernet II nicht unähnlich ist. Einige Antworten namens ATM, was gut ist, außer dass die Latenz höher bewertet wird als die Biteffizienz, die, wie ich vermute, möglicherweise optimiert wird. Direkt darauf , ohne zusätzliche Schichten, würden hochkomprimierte Anwendungsprotokolldaten kommen. Erstens, kurze und teure Militär-/Finanznachrichten mit einer Verwendung, die der alten Telegrafie nicht unähnlich ist. Dann Nachrichten und persönliche Nachrichten.

Die Schichten moderner Protokolle wurden entwickelt, um die Trennung zwischen Transport, Routing und Verwendung der Daten zu verbessern, wodurch es einfach ist, die eine zu ersetzen, ohne die andere zu beeinträchtigen. Damit sie existieren, muss dieser Anreiz gegenüber dem Anreiz, die minimale Anzahl von Bits maximal zu nutzen, überwiegen. Ich glaube nicht, dass dies bis weit in das FTL-vernetzte Universum hinein Ihr Fall wäre, wenn überhaupt.

Wenn nein, was macht es unmöglich, damit umzugehen?

Nichts. Aber die Nutzung würde nicht dem heutigen Internet ähneln, bis die Bandbreite verbessert wird.

Ich möchte die Kommentarfrage von @JohnFeltz beantworten:

Irgendeine Einschränkung, wie viele dieser Geräte Sie konstruieren und nebeneinander platzieren können? Wenn ich 100.000 davon parallel betreiben kann, brauche ich nur einen inversen Multiplexer, um 5 MB Bandbreite zu erhalten

Wenn Sie zwei oder mehr dieser Geräte nebeneinander stellen, stören sie sich leider.

Dies ist nicht nur ein Problem für die Skalierung der Bandbreite, sondern ermöglicht auch das Jamming von Nachrichten, die ein Feind nicht senden/empfangen soll.

Der Mindestsicherheitsabstand zwischen Transceivern liegt bei Ihnen, seien Sie einfach konsequent. Es kann auch nur auf der Sende- oder Empfangsseite ein Problem geben.

„Die tapfere Heldin schleicht sich als Gärtnerin verkleidet auf das Schlossgelände. Während sie einen Busch umpflanzt, vergräbt sie auch eine kleine Kiste unter den Wurzeln. Später wird sie durch einen Timer aktiviert und die Kommunikation wird unmöglich. Der Kommunikationsoffizier kann dem Kaiser mitteilen, dass die Kiste irgendwo ist auf der Ostseite des Palastes, aber um ihn tatsächlich zu finden, ist eine lange Suche erforderlich. In der Zwischenzeit wird das Kommunikationsteam auf die Spitze des Westturms verlegt und versucht, im Lärm nach Nachrichten zu lauschen.

Da die Übertragung "sofort" erfolgt, können Sie die Informationen nicht in den von Ihnen gesendeten Bytes (wie bei normalen Netzwerkprotokollen) codieren, sondern in der Zeit zwischen den Bits. Wenn Sie also die Nummer 255 senden möchten, würden Sie nicht wie bei einem normalen Internetpaket ein ganzes Byte (8 Bit) verwenden. Stattdessen würden Sie 1 Bit genau 255 Nanosekunden nach dem vorhergehenden Bit senden. Ihre gesamte realisierte Bandbreite wäre nur durch die Präzision Ihrer Uhren und Ihre gewünschte Latenzzeit begrenzt. Sie könnten beispielsweise sagen: "Ich werde alle 10 Millionen Nanosekunden 1 Bit senden. Der Wert, den dieses Bit darstellt, entspricht der Anzahl der Nanosekunden seit dem Senden des vorherigen Bits." Dieses Protokoll würde Ihnen eine maximale 1-Wege-Latenz von 10 Millisekunden und eine minimale Datenübertragungsrate von knapp unter 300 Bytes/Sekunde geben. eine Verdoppelung der maximalen Latenz verdoppelt auch die effektive Übertragungsrate. Ausgeklügeltere Protokolle könnten darauf aufgebaut werden, um die Übertragungsrate on-the-fly auszuhandeln oder Kurzcode-Codierung zu verwenden, um den Durchsatz zu maximieren, indem sichergestellt wird, dass die häufigsten Datenblöcke viele führende Nullen haben (also Bits gesendet werden Schneller). Möglicherweise möchten Sie auch die maximale Blockgröße begrenzen, um sicherzustellen, dass die Uhren je nach relativer Uhrendrift synchron bleiben.

Ich würde den Link direkt als dumme 7-Bit-Serienleitung verwenden und die alten UUCP-Protokolle wiederbeleben. Diese Dinger haben tatsächlich weniger Overhead als moderne und sind besser darauf ausgelegt, mit den dummen langsamen Übertragungszeiten fertig zu werden. Die einzige wesentliche Änderung ist das Ersetzen von uuencode durch eine der base85-Varianten.

Ich gehe davon aus, dass diese Maschine, die ich The Link nenne, selten ist. Das heißt, es werden nicht genug davon parallel laufen, um die Bandbreite zu verbessern.

Ich werde eine andere Ansicht anbieten. Der Link würde sich nicht in einem Netzwerk im normalen Sinne befinden. Es hätte keinen Sinn.

Erstens würde die Nutzung von The Link aufgrund seiner Bedeutung und der geringen Bandbreite streng kontrolliert, sodass die Leute keine Katzenbilder übertragen würden. Es würde Firewalls geben, um unbefugten Zugriff zu verhindern.

Zweitens kann The Link aufgrund der geringen Bandbreite eher als Telegraf denn als etwas in einem modernen Computernetzwerk betrachtet werden. Ein Telegraf (abgesehen von der Notwendigkeit von Repeatern) bietet Geschwindigkeiten, die dank der Magie des Kupferdrahts mit Lichtgeschwindigkeit vergleichbar sind. Sie schließen die Telegrafentaste, das andere Ende macht "Klick". Sicher, der Elektromagnet ist langsam, aber der Mensch, der die Signale eingibt, ist noch langsamer. Es ist praktisch sofort. Betrachten Sie ein Unterwasserkabel zwischen den USA und Großbritannien. Jedes Land mag ein ausgeklügeltes Telegrafennetz haben, und gegen eine geringe Gebühr kann Sally in Florida Oma in Maine von ihrer neuen Katze erzählen, aber welche Nachrichten kommen für die Kommunikation über das Unterwasserkabel in Betracht? Wahrscheinlich nicht das Katzentelegramm. Stattdessen würde es wahrscheinlich für Informationen verwendet werden, die für Politik und Hochfinanz relevant sind.

Natürlich werden wir 2016 nicht ein paar Leute haben, die Nachrichten auf unserer interstellaren Verbindung abhören. Aber es ist immer noch wie ein Telegraf. Sie hätten an jedem Ende von The Link einen Computer. Der Absender würde aus einem Puffer von Nachrichten lesen (codiert, dann maximal komprimiert) und sie abgreifen. Die Maschine am anderen Ende würde empfangen, dekomprimieren und decodieren.

Obwohl es also kein Netzwerkprotokoll geben würde, würde es wahrscheinlich eine Art Nachrichtenprotokoll geben, damit der Empfänger weiß, wann es angebracht ist, die Nachricht zu dekomprimieren. Eine kurze Nachricht wäre allerdings ein "Scheunenbrenner", da die Komprimierung pro Zeichen geringer und damit weniger effizient wäre.

In Anbetracht dessen, wie kontrolliert die Verwendung von The Link wäre, ist es unwahrscheinlich, dass die Nachrichten für den Normalbürger besonders interessant wären, genauso wie in unserem obigen internationalen Beispiel der Normalbürger sich nicht allzu sehr um Angelegenheiten der Hochfinanz kümmern würde.

Aber welche Nachrichten genau würden über The Link gesendet werden?

Angenommen, ein subleichtes Kolonieschiff hat nach 300 Jahren sein Ziel erreicht und beginnt mit dem Bau seines neuen Zuhauses. Der Link ist eingerichtet.

Die ersten gesendeten Nachrichten sehen in etwa so aus:

Hallo Erde, wir sind gut angekommen und alles läuft nach Plan.

(Dies werden vielleicht wegen der Codierung ein paar Zeichen sein) und beantwortet von

Es tut verdammt gut, von dir zu hören, Cheerio!

(weitere 2 oder 3 Zeichen)

Nach Höflichkeiten und Diagnosen, welche Bedeutung hat irgendetwas auf der Erde für die Kolonie? Hilfe ist 300 Jahre entfernt, abgesehen von einigen schockierenden neuen Entdeckungen. Die Politik wächst und schwindet im Laufe der Jahrhunderte. Länder wechseln. Würde das Land, das das Schiff geschickt hat, noch existieren? Wäre die Weltordnung, die das Schiff geschickt hat, erkennbar? Welche Bedeutung hätte die Kolonie für die Menschen auf der Erde, 15 Generationen entfernt von jenen tapferen, wagemutigen Seelen, die das Kolonieschiff bestiegen?

Es könnte sein, dass ein Katzen-JPEG tatsächlich genauso nützlich ist wie jede andere Nachricht.

BEARBEITEN – Angesichts des Mangels an Bedeutung zwischen dem täglichen Leben der Menschen auf der Erde und den Kolonisten scheint es, dass The Link in diesem Fall im Allgemeinen für minderwertige Wissenschaftskommunikation verwendet wird. Beobachtungen über den Stern, der umkreist wird, und solche Sachen. Ich weiß nicht, warum das besonders relevant wäre, aber es ist besser als tote Luft, vorausgesetzt, The Link nutzt sich nicht durch den Gebrauch ab.

Eine wahrscheinlichere Verwendung von The Link betrifft überhaupt keine Personen. Stattdessen ist das Schiff, in dem The Link untergebracht ist, rein roboterhaft. Diese Schiffe werden von der Partitur zu verschiedenen Sternensystemen geschickt. Sie halten still und heimlich Ausschau nach den Signalen anderer Rassen. Die Daten, die sehr langsam zurückgesendet werden, sollen den Menschen auf der Erde einen Einblick in die Technologie der Außerirdischen und hoffentlich ihre Absicht geben. Wirklich finster.

Betrachten Sie dies: Lukas 17:11 oder dies: Koran 2:4-5, Oxford World's Classics Edition, oder sogar dies: "Regel 5". Sie alle sind Verweise auf längere Sätze oder Texte. Der einschränkende Faktor bei dieser Art der Verschlüsselung ist die Verfügbarkeit der Referenz(en) sowohl für den Sender als auch für den Empfänger. Englisch ist eine hochredundante Sprache, weitaus effizientere Sprachen sind bekannt. Der typische Hochschulabsolvent hat einen Wortschatz von <20.000 Wörtern oder Wortfamilien. Ein Byte ermöglicht die Codierung von 65.000 Wörtern. So sind 5 bis 10 Bytes/Sekunde schneller als Sprechen und würden die verbale (im Gegensatz zur visuellen) Datenübertragung nicht einschränken.

Ich bin ein bisschen MeeSeeks-Sticker.

Ich denke, wir sollten das Paradoxon diskutieren, das Ihre Technologie darstellt, wenn Sie versuchen, es innerhalb bekannter moderner Datenübertragungskonventionen zu lösen.

"Die Menschheit schafft es irgendwie, Daten augenblicklich zu übertragen"

Insbesondere dieses Element Ihrer weltweiten FTL-Netzwerke macht vieles von dem, was moderne Datenübertragungskonventionen definiert (und im weiteren Sinne, wie wir sie messen), für Sie effektiv nutzlos.

Mit Ihrer Technologie gibt es Null-Latenz. Mit anderen Worten, wenn ich etwas sende, kommt es auf der anderen Seite GENAU zur selben Zeit an, zu der ich es sende. Nicht vorher, nicht Nanosekunden danach, sondern zur exakt gleichen Zeit an einem entfernten Ort. Wenn Sie diese Situation in modernen Netzwerken lösen, würde Ihr Datendurchsatz aus den Charts fallen. Im Wesentlichen könnten Sie eine unendliche Menge an Informationen durch dieses Netzwerk stopfen, da es theoretisch keine Begrenzung gibt. Zumindest jetzt noch nicht...

"Aber die Geschwindigkeit selbst ist langsam - sagen wir, 5 bis 10 Bytes (10 bis 20 Hexadezimalcodes) pro Sekunde senden zu können."

Hier wird Ihre Situation etwas einzigartig . Gedankenexperiment, wenn Sie so wollen:

Wenn ich diese Antwort poste, erhalten Sie eine Benachrichtigung. Geben Sie für unsere Diskussion vor, dass wir mit der Technologie Ihrer Welt arbeiten. Wenn ich auf diese Schaltfläche „Antwort posten“ drücke, wird Ihr Gerät Sie mit dieser Benachrichtigung anpingen – beide Ereignisse finden gleichzeitig statt. ABER wie viele Daten wurden gesendet?

Das Hauptproblem dabei ist, dass IF-Daten sofort gesendet werden und es sinnlos ist, den Datendurchsatz über einen bestimmten Zeitraum zu messen. Und wenn Bandbreitenmessungen nicht zutreffen, wie und/oder warum ist Ihre Technologie dann so begrenzt?

Meine Antwort:

Angesichts der Tatsachen Ihrer Technologie und um im Kontext Ihrer Frage zu bleiben, würde ich mir an Ihrer Stelle keine Gedanken darüber machen, die Übertragung von Informationen mit modernen Netzwerkprinzipien zu definieren. Ich würde mich darauf konzentrieren, auf einfachste Weise zu definieren, warum die Dinge so sind, wie sie sind.

Zum Beispiel:

• Die Datenübertragung erfolgt aufgrund des {bevorzugten theoretischen Konzepts der sofortigen Informationsübertragung hier einfügen, d. h. Quantenverschränkung}
• Die Technologie ist auf einen Ein- und Aus-Zustand beschränkt (ähnlich wie bei binären Systemen), was Ihnen eine Begrenzung der zu übertragenden Daten sowie eine Begründung für die Aufhebung der Begrenzung der zu übertragenden Datenmenge bietet. gesendet" über einen bestimmten Zeitraum, obwohl das "Senden" dieser Daten sofort erfolgt. Erläuterung: Die Daten selbst befinden sich gleichzeitig an beiden Orten, aber der Systemstatus kann nicht gleichzeitig EIN und AUS sein. Das bedeutet, dass die Verzögerung bei der Informationsübertragung nicht auf Latenz oder Bandbreite zurückzuführen ist, was, wie wir besprochen haben, nicht unbedingt zutrifft, sondern durch eine funktionale Einschränkung des vorhandenen Systems begrenzt ist.
• Optional: Systeme sind männlich-weiblich, wobei die Kommunikation nur zwischen gepaarten Systemen möglich ist. Kein wirklicher Grund, ich mag das nur als weitere Einschränkung, da der Kontext Ihrer Frage wirklich darauf hinausläuft: "Wenn Daten sofort übertragen werden können, wie schränke ich die Technologie für die Bewohner meiner Welt rational ein?"

Fazit: Wie bei allem der Vorstellungskraft, tun Sie dies alles nach Belieben. Denn hey, es ist deine Welt. Und danke, es hat mir wahrscheinlich mehr Spaß gemacht, das zu schreiben, als dir, es zu lesen.

Welche Art von Informationen möchten Sie übermitteln? Wenn es nur einfacher Text ist, implementieren Sie an beiden Enden so etwas wie die Bibliothek von Babel . Dann müssen Sie nur noch Positionsinformationen der gewünschten Nachricht übermitteln.

Dies setzt voraus, dass in dieser Welt der FTL-Kommunikation Verarbeitungsleistung und Datenspeicherung im Wesentlichen keine Probleme sind.

Klarstellung: Was ich mit dem Verweis auf die Bibliothek von babel gemeint habe, ist eine Art Nachschlagetabelle. Diese Mitteilung wäre aus einem bestimmten Grund erstellt worden. Meine Vermutung ist, dass dies eher für die interstellare Kommunikation als für das Senden von etwas ein paar Meilen entfernt ist. Daher würde es eine Form der Codierung geben, um sicherzustellen, dass die Absicht der Nachricht gesendet wird, ohne dass möglicherweise die wörtlichen Informationen gesendet werden müssen. Warum 30.000 Bytes senden, wenn ich 10-20 dieser Punkte an eine Nachschlagetabelle senden kann, die die gesamte Nachricht übermittelt.

Ich wollte dieselbe Beobachtung wie James Turner posten, also habe ich stattdessen seine Antwort positiv bewertet und über einen Einwand nachgedacht (was auch den Störeffekt und die Langsamkeit der Übertragung erklären könnte).

Wenn die Übertragung fehlerfrei und augenblicklich wäre, könnte ich mich darauf einigen, dass ein Signal alle 1,048576 ms (höchstens) mit einer Verzögerung von 0 ns gesendet wird, was 1111111111 und einer Verzögerung von 1048575 ns bedeutet, wenn es möglich wäre, die Zeit mit Nanosekunden-Präzision aufzulösen also 0000000000. Zehn Bits pro Millisekunde und schon sind wir im 10-kbit/s-Bereich (und im Durchschnitt besser).

Ich gehe also davon aus, dass die Übertragung des Signals zwar augenblicklich erfolgt, die Auflösung des Signals jedoch ein probabilistischer Prozess ist. Analysieren Sie ein 1-ns-Fenster, und die Chancen, ein "Signal" oder "Fehlen davon" zu unterscheiden, sind gleich Null. Um eine Sicherheit von 99 % zu erreichen, müssen Sie die Übertragung einer ganzen Sekunde analysieren.

Daher haben die Ingenieure natürlich einen Kompromiss gefunden und kürzere Zeiten mit Komprimierungs- und Fehlerkorrekturschemata kombiniert, um die Bandbreite auf 40-80 Bit/s zu erhöhen.

Wenn wir zwei Sender in der Nähe platzieren, sendet einer etwa 50% der Zeit eine 0, während der andere eine 1 sendet, was die Fehlerrate am Empfängerende erhöht und eine niedrigere Geschwindigkeit erzwingt. Das Skalieren des Geräts bringt Ihnen also nichts.

Andererseits, wie weit müssen die Sender voneinander entfernt sein, damit sie sich nicht nennenswert stören? Angenommen, es sind 500 Meter; Im Weltraum könnte man ein riesiges Kommunikationsfeld aufbauen, einen zehn Kilometer großen Drahtgitterwürfel, der aus 500 m "Drähten" besteht, die etwa achttausend Sender an Ort und Stelle halten und durch normale Unterlichtsignale koordiniert werden. Planeten könnten über Oberflächennetzwerke miteinander kommunizieren; Schiffe wären viel begrenzter. Die Folgen scheinen interessant.

Diese Diskussion scheint sehr eng zu sein – ich würde die Frage von ein paar Schritten zurück betrachten.

Ich gehe davon aus, dass der Kontext eine interstellare Zivilisation ist, da es sonst schwierig ist, den Vorteil gegenüber bestehender Kommunikationstechnologie zu erkennen. Wenn diese Zivilisation FTL -Reisen hat, wäre es effektiver, Daten physisch zu versenden: Eine einzige Micro-SD-Karte könnte Übertragungen im Wert von mehr als 500 Jahren speichern.

Wenn Sie FTL - Kommunikation haben, aber die Reise langsamer als das Licht ist, wird es interessanter. Seit jeher konnten sich Menschen so schnell fortbewegen wie Informationen; Seit Kurzem haben wir eine sofortige Kommunikation, aber es dauert auch nicht länger als einen Tag, um irgendwohin zu reisen, wenn Sie es eilig haben.

Wenn ferne Welten in Echtzeit miteinander sprechen könnten, aber Reisen zwischen ihnen Jahrzehnte dauern würden, wäre das eine völlig neue Art von Realität. Die Einführung eines wöchentlichen Fingerhuts voller Speicherchips würde immer noch eine größere Bandbreite bieten als das FTL-Radio (um viele Größenordnungen), aber die Latenz würde Jahrzehnte gegenüber Minuten betragen. Es gibt interessante Implikationen.

Angenommen, die Menschen auf der Erde wären besessen von Omicron Persei VIIIs Version von Shakespeare. Thimbles würde alle Theaterstücke, Filme und Interviews liefern, die die Erde konsumieren könnte, aber sie würden lange nach Space Shakespeares Tod eintreffen. Ein wohlhabender Terraner könnte 15 Minuten FTL-Funkzeit für einen Live-Chat mieten, aber das Beste, was er tun könnte, wäre ein Chat mit den Enkelkindern von Spacespeare. Oder Sie könnten sich mit einer lebenden omikronischen Berühmtheit unterhalten, aber nur Ihre Enkelkinder würden sehen, wofür sie berühmt waren.

Aus wirtschaftlicher Sicht ist es schwer vorstellbar, dass die Echtzeitkommunikation im Kulturhandel eine große Rolle spielt. Die Leute zahlen vielleicht, um Filme aus Space Hollywood zu sehen, aber sie würden einfach die 200 Jahre alten Filme konsumieren, die per Fingerhut ankommen, und die 200 Jahre alte Version von Space Hollywood als „die Gegenwart“ behandeln.

Das FTL-Radio wäre eigentlich nur für Spoiler gut. Was für den Handel nicht sehr wichtig ist, aber offensichtlich nützlich wäre für Warnungen vor massiven Invasionsflotten / Supernovas / etc. Tatsächlich könnte dieser Service eine wichtige Garantie für den Handel sein; Wenn Sie Ihre Space-HBO-Rechnung für die Sendungen, die sie vor 200 Jahren gesendet haben, nicht bezahlen, werden sie Sie im nächsten März nicht vor diesem Asteroiden warnen.

(Vage verwandt, schrieb der Nobelpreisträger Paul Krugman einmal eine Abhandlung über die Ökonomie des Sublichthandels ).

NB

Einige der obigen Antworten berühren die Idee, riesige Datenmengen mit riesigen Wörterbüchern zu kodieren; Diese Idee hat eine lange Geschichte, mindestens seit dem 17. Jahrhundert bis in die 1950er Jahre, als sie im Zuge der Schaffung der Informationstheorie demontiert wurde.

Die Idee ist, dass Sie alle möglichen Bücher aufschreiben, sie alle ordnen und sie dann einfach durch Nummern ansprechen. Das Problem ist, dass ein Buch bereits nur eine Folge von Bytes ist, dh eine lange Nummer, und wenn Sie jedem Buch eine Nummer geben, bedeutet dies, dass die Nummer so lang ist wie das Buch selbst; Tatsächlich handelt es sich um genau dieselbe Folge von Bytes.

Natürlich sind die meisten Byte-Strings keine "echten" Bücher, und wenn Sie nur gültige englische Texte einfügen, können Sie die meisten Zahlen überspringen. Das führt tatsächlich zu einer erheblichen Datenkomprimierung. Aber es erfordert auch einen Algorithmus, um jeden möglichen „sinnvollen“ Text zu generieren, das heißt, einen Algorithmus, der jeden Gedanken aufzählen kann, den ein Mensch jemals haben könnte. Das ist ... herausfordernd ... und erfordert viel Speicherplatz.

Praktische Komprimierungsalgorithmen verwenden diese Art der "Wörterbuchcodierung", aber sie ist viel grundlegender. Der Trick besteht eigentlich darin, so viel wie möglich aus dem Wörterbuch herauszulassen, sodass nur sehr häufig vorkommende Zeichenfolgen durch sehr kurze Codes ersetzt werden, also zum Beispiel the cat sat on the matauf reduziert werden 1 c2 s2 on 1 m2. Wenn Sie ein vorgefertigtes Wörterbuch verwendet haben, das alle bekannten Wörter enthält, wird die Nachricht möglicherweise länger ( 23 4954 3430 109 23 908078).