Possibly a dumb and outsider question, but my knowledge in the basics of computer networks is terrible.

Imagine the possibly not too original concept, that humanity somehow manages to transmit data instantaneously, defeating the vast distances of space - however, it is possible for very small data packets only.

Now make it a bit more specific: the transmitter and the receiver are the same machine, so if two such machines are deployed, contact between them can happen instantaneously and without any loss, but the speed itself is slow - let's say, being able to send 5 to 10 bytes (10 to 20 hexadecimal codes) per second.

Does it differ from the early days of the internet - in another sense, would it be possible to handle with any protocols ever developed in the field of computer networks?

If no, what makes it impossible to handle?

  • 27
    $\begingroup$ Any restriction on how many of these devices you can construct and sit next to each other? If I can run 100,000 of these in parallel, I just need an inverse multiplexer to get 5 Mb bandwidth. $\endgroup$ – John Feltz Nov 17 '16 at 16:40
  • 6
    $\begingroup$ It's your world. Use handwavium as necessary. But that's the kind of thing a smart network engineer would try in your world. $\endgroup$ – John Feltz Nov 17 '16 at 17:10
  • 16
    $\begingroup$ (1) As John Feltz points out, the word you’re looking for is bandwidth.  The speed is instantaneous (or, at least, FTL); the bandwidth is 5 to 10 bytes per second. (2) If the device is constructed from platinum-plated unobtanium, with interface ports made of handwavium, cost may be a factor in scaling the solution.  If it’s as big as NASA’s Vehicle Assembly Building, then size might be an issue. $\endgroup$ – Peregrine Rook Nov 17 '16 at 17:34
  • 10
    $\begingroup$ @BlueRaja-DannyPflughoeft some of us actually are - I mean, there's a tag, [hard-science] that is for expert help. I think [science-based] tag applies for this, too. Worldbuilding can have very special questions that can be deconstructed to IRL technical issues. EDIT: you know, I'm not even sure this question would be welcome on those sites. $\endgroup$ – Zoltán Schmidt Nov 17 '16 at 21:15
  • 9
    $\begingroup$ I agree it wouldn't be welcome on NE or SF. You're talking about fictional computers with fictional interfaces in a fictional world... not what either of those two sites deal with. WB, on the other hand, frequently deals with #FictionalWorldProblems that have roots in real life disciplines. $\endgroup$ – Doktor J Nov 17 '16 at 21:52

19 Answers 19


Contrary to the OP’s concern at the start, this is not a dumb question; it is actually a very good one. Most of the answers this post has received are pretty much wrong, and in this group that means that you must have asked a question that relies on a bunch of really technical underpinnings. So kudos!

The Common Mistake

The common mistake among answers so far is that they speak to what are commonly referred to as “layer 3” protocols, or even proper “layer 2” protocols. To understand the answer we need to understand why this is the wrong way to look at the problem.

In today’s terrestrial (and, to a lesser extend, orbital satellite) network infrastructure data that is to be transmitted from a computer undergoes the following process (at a high level):

  1. The data stream is identified
  2. The data stream is broken into transmission segments by the sender
  3. The segments are encapsulated (wrapped) inside a "Layer 3" packet, which provides all the necessary source/destination/errata information necessary to make the packet routable through a large number of network segments
  4. The packets are encapsulated (wrapped) inside a “Layer 2” frame, which provides information about the source, destination, protocol in use, and other errata. This encapsulation defines how the frame is routed through a single network segment.
  5. After the framing is worked out, the packet is encoded on to the wire (or wirelessly). This encoding defines, for example, how to distinguish a “1” from a “0”. So stating “high voltage = 1”, “low voltage = 0” and similar.

The contextual issue here that defeats this operation method is that you are talking about very LOW data streams with presumably relatively few targets communicating. According to your premise, you are also talking about a system which is known to be lossless where the source and destination are already known ahead of time. Those are not the expectations and situations that the protocols most people are exposed to on a daily basis were tailored toward.

The Solution

If the sender and receiver are known ahead of time and loss is not a problem, there is no reason at all to bother with any encapsulation. All you need at that point is an encoding method, like Manchester Encoding. Encoding methods define basically what a 0 and a 1 is (both in time and amplitude), and provide systems with a mechanism to ensure that they are both on the same page.

To keep things simple I probably would just use Manchester encoding, as used in many of today’s wired connections. Yes, there are other types of encoding that may work better for specific transmission characteristics, but given your “instant/flawless” portal delivery system I think we can draw a pretty good analogue to having that portal be equivalent to just an infinitely small segment of a wired network connection.

Also Note

Due to the very slow speeds involved, if you have any data you want to use to help route your info to its final destination you would be better off leaving that to higher level (non-network) protocols. Your data transfer speed is so trivially slow that it would mean very little to have your equipment on both ends reassemble the full data stream and analyze the presented data to understand where it should be headed.

And no, that does not mean looking at an IMAGE, for example, and understanding what pictures mean - computers have plenty of higher-protocol languages that users never see. Such information could, for example, be included as part of an XML package. I wouldn't worry about the technical particulars at that point though.

  • $\begingroup$ Very nice explanation, I'm actually even astonished after googling Manchester Encoding. This is indeed very low-level and can be accomplished by a simple electronic connection, if I could understand it properly. I thought the simplest solution is listening to radio waves, like in reality, but this kind of internal communication started forming in head while reading the answers. Extra thanks for mentioning that routing should work on the higher levels. $\endgroup$ – Zoltán Schmidt Nov 17 '16 at 20:56
  • 3
    $\begingroup$ You have the layers backwards in your description. A layer 3 IP packet gets 'encapsulated' by a layer 2 ethernet (or ATM) frame header and footer, just as application layer data is broken up into layer 4 TCP or UDP packets and then get an IP header stuck onto them when they are passed to layer 3. $\endgroup$ – kingledion Nov 18 '16 at 3:41
  • $\begingroup$ You got the layers wrong. In the OSI model, layers 1 to 3 are physical, link, and network. $\endgroup$ – v7d8dpo4 Nov 18 '16 at 13:36
  • 4
    $\begingroup$ Manchester encoding is horrifically inefficient. We moved away form it years ago. $\endgroup$ – Peter Green Nov 18 '16 at 13:42
  • $\begingroup$ @kingledion, v7d8dpo4 - Well spotted. Very bad mental processing on my part... I blame the fact that I had been up for 54 hours straight when I wrote the response. I'll go ahead and make the needed updates. What's highly amusing about this to me is that in the first 8 hours of that awake period I actually passed a written Routing & Switching exam to renew my multiple CCIE certs :) I'm very glad I scheduled that test for Wednesday and not Thursday! $\endgroup$ – GrinningX Nov 18 '16 at 14:42

Asynchronous Transfer Mode (ATM)

I like both the other answers, but I think a better solution, given the problem set, is ATM. A TCP/IP interface is best for a distributed network, but the question specified point-to-point communication. Internal computer transfer bus 'protocols' don't have the same robust ability to merge different channels of incoming information into one stream, and the checksums to ensure correct delivery.

ATM was more or less wiped out in common usage by TCP/IP because the latter is better for distributed networks, but ATM is still used in satellite networks. Infact, this is the very application that is most applicable to your situation.

To explain simply, if a ships at sea wants to communicate to the rest of the internet, they will use ATM to send TCP/IP packets to a hub on land via a satellite. The satellite merges multiple possible incoming ATM streams coming up from ships and sends them back down to the hub, where the packets are taken out of the ATM stream and sent on their merry way on the regular internet.

There is much more to it than that, if you want to read up on Wikipedia, or the specification. But I imagine that this is the capability you envision for FTL communication.


I wanted to clarify my answer a little bit. ATM is a layer 2 protocol, and TCP/IP is a layer 3/4 protocol. So there is no reason they cannot be used together. My point is the protocol of interest that best suits FLT communication like that is ATM, and you can send either IP or something else that might be better for low bandwidth over that.


More responses to criticism. I edited the first section on bus protocols to reflect what they can't do that I think they need to do.

Also, @Navin; You want an L2 protocol because you will have more than one carrier going back and forth between two different star systems. Why stick with one carrier at 10 bytes/sec when you could install 10 carriers at that speed? In this case, you need your packets split among several carriers and then re-merged at destination. ATM does that. You still will want an L3 carrier to disperse your message over potentially millions of network nodes at the destination.

Also, if you transfer this way, a 50 byte ATM frame transfers on one carrier in 5 secs; a 9000 byte ethernet frame in 15 minutes. That means a 1000 byte message split into 20 frames can be transmitted in 10 secs on 10 different carriers with ATM, while a 1000 byte message in one 1000 byte frame will transmit in 100 seconds. Surely you can see the advantage of smaller frame size to a low bandwidth application.

  • 2
    $\begingroup$ Internal computer interconnects most definitely have protocols, it's just that we commonly lump the protocol together with the physical interconnect. For example, USB and SATA both specify both the electrical and physical interfaces as well as what constitutes valid data and how it should be encoded on the wire (for example, SATA specifies 10b8b). If not all of these are specified, then it would be highly unlikely to be interoperable, which would nullify the whole point. Compare Plug 'n' Play Technology (warning: TV Tropes). $\endgroup$ – a CVn Nov 18 '16 at 8:34
  • 1
    $\begingroup$ Even something as simple as SDRAM memory busses have protocols and commands. The Wiki article has a good summary of them (and still applies to DDR4). The command set is much simpler than SATA, of course, and doesn't need a microcontroller to decode it. (SSDs have fairly powerful CPUs to run their firmware, but even magnetic HDs have a microcontroller (often ARM) to handle SATA commands and copy data between their cache, the SATA interface, and the read/write heads.) $\endgroup$ – Peter Cordes Nov 18 '16 at 10:10
  • $\begingroup$ If you're going to run IP on it, why use an L2 protocol at all? You don't need L2 addresses on a point-to-point link. Oh and ATM is horribly inefficient because it uses fixed-size 53 byte frames, each with a redundant header! In contrast, any Ethernet switch can forward 9000 byte frames. $\endgroup$ – Navin Nov 18 '16 at 10:38

This is a point to point communication so you would never bother with the
routing, timing and checksum overhead of networking packets. If the ftl transmission is subject to loss or corruption you might want error correction and a notion of connection orientation. Rather than re-using an existing technology you should tune your protocol for the actual corruption and loss profile of your new medium.

enter image description here

The most important limitation here is the excruciatingly slow transmit speed. You'd minimize the amount of non-message overhead (or eliminate it entirely) and use the best compression you can. If you do need to send routing or delivery information, you'd probably use a hash table and send the hash of the destination instead of full delivery info. A comment below mentions TDMA which is an interesting thought. Given the maximum bandwidth of the entangled photons (or whatever) it might make sense to bundle multiple channels together.

  • 1
    $\begingroup$ I imagine you need a checksum to ensure delivery over many light-years, and I imagine you need timing (TDMA or something) if you want to pass multiple channels. $\endgroup$ – kingledion Nov 17 '16 at 17:46
  • $\begingroup$ Note: Time To Live in the packet header does not actually have any relevance to time in the temporal sense. It's a hop-count mechanism. $\endgroup$ – GrinningX Nov 17 '16 at 19:49
  • 1
    $\begingroup$ @GrinningX Technically it was originally meant to be used in the temporal sense, they just never changed the name when it was found that it worked better to use the field for hop-counting instead. $\endgroup$ – JAB Nov 18 '16 at 4:01

If it's A to B with no middleman and virtually guaranteed no data loss/corruption or disconnect, you're basically dealing with the same mindset of communication between internal computer components, just much, much, much slower. There's no network transfer protocol between the CPU and platter drive, because you just don't need one.

Being that this society has this technology, I'm assuming they're at our level of general computing power or (more realistically) beyond. This means with this slow rate the bottleneck is painfully obviously the transfer not the computers on either side.

You're going to want to focus on data compression (not transfer protocols), and a markup that helps reduce metadata. The concept behind MessagePack seems quite fitting for you:

MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it's faster and smaller. Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves.


You won't want to stop there, but think along these lines. You could also expand the efficency if you know what sort of traffic you're pushing over this connection, and the CPUs on the receiving side can extrapolate from the baseline, similar to vector graphics (a few definitions are used to calculate the larger concept)

Your best solution will be a proprietary format, since you don't need compatibility, you just need efficiency.

  • $\begingroup$ Null-terminated strings require only one extra byte in addition to the strings themselves.  The only benefit I can see to prepending a byte count is that it lets you embed null bytes in the strings, and how often is that needed?  And it looks like it breaks down for strings longer than around 34 bytes. $\endgroup$ – Peregrine Rook Nov 17 '16 at 18:34
  • $\begingroup$ I like your direction, but with respect I disagree ever so slightly. I would definitely want a standard format for how the data is encoded on the wire. With regards to what happens to the data after that, I would probably want a standardized message format - though it doesn't have to be an existing message format. For the distances and timing involved, wouldn't it be great if you could use some hardware / software that you didn't have to build yourself? History is largely against the long-term use of proprietary protocols for a reason. $\endgroup$ – GrinningX Nov 17 '16 at 19:55
  • 2
    $\begingroup$ There's no network transfer protocol between the CPU and platter drive There's a protocol with checksums, it's just not a network protocol. See comments on another answer. SATA specifically has a 3 layer protocol, with CRC for error detection. $\endgroup$ – Peter Cordes Nov 18 '16 at 10:20
  • $\begingroup$ You will still want some kind of low-level protocol, but that's part of how the machine works internally in the process of getting bits from point A to point B. So you're right that an efficient high-level protocol is important. If this FTL link is going to be part of a larger communication system that can also send messages to other places, or to different possible receivers on the other side, then you do need some kind of routing info. $\endgroup$ – Peter Cordes Nov 18 '16 at 10:24
  • $\begingroup$ @PeregrineRook, so, msgback has a list of byte counts dedicated to short strings, and then a range used for non-string types. (You have a longer string? Then you get to have a multi-byte sigil). This means that you can in the common case use the same one-byte sigil for both type and length. It's a kludge, but it's a kludge that works well in practice, and that makes it valuable. $\endgroup$ – Charles Duffy Nov 20 '16 at 16:17

"Data packets" are a concept applied to networking, when data must be routed around and through multiple devices to reach its destination; e.g., a network or the Internet. If it's just a point-to-point communication, then it's like a serial link (like old school printers/keyboards) and it doesn't need to be packetized.

Any modern protocol can deal with slow transmit rates when configured for it, so a few bytes a second is workable for TCP/IP or UDP as long as the "time to live" is high enough; your needs will determine the specific protocol.

TCP/IP and UDP are appropriate for large mesh type networks because they contain all the addressing information needed to get from anywhere to anywhere when there is a large number of destinations and routers. If you're dealing with a small network of only a few computers, then there are more efficient protocols out there.

For a direct connection, one computer talking to only one other computer, a packet is not optimal, because some of the transmission will be taken up by address information. For point-to-point the address can be assumed.

Addendum for "TCP-IP/UDP lossy-ness":

The TCP protocol has something built into it called "guaranteed delivery" which means every packet sent will get to the destination....eventually. UDP does not make this guarantee. Packet loss does not happen just in transmission, although it is common(ish); routers can crash or overflow and the packet they were holding onto to transmit can be lost, or a stray photon can hit the microchip it's being stored in and flip a bit, corrupting the data. Corruption and loss don't happen only in transmission.

The "guaranteed delivery" part means that, if a packet, which are individually numbered (part of the overhead that these packets take in terms of data), is missing, the recipient will go back to the source and request that packet be sent again. This is good for if you MUST have all the data, completely. This is bad for network bandwidth.

UDP, or connectionless, or "no guarantee", style protocols are what you use when you stream data (e.g., YouTube). It would kill the network if you had to go grab every bit of that last frame of animation you missed, and at that point it doesn't matter anyway. You don't actually lose that many packets this way either, and it's much easier on the bandwidth side for transmitting data.

For both these off-the-shelf protocols, however, you're dealing with upwards of 60 bytes for just the header information in each packet. That could be a significant portion of time taken for a simple point-to-point talk, especially when the data get broken up into thousands of packets.

For such low data rates I would look at old serial style (COM port) techniques, and go ahead and restrict it to one-computer to one-computer communication (even if multi-talking was available), and if you need a network just use a standard network between these FTL computers.

  • $\begingroup$ Now, again, my knowledge is very restricted, but I've heard about that TCP sends the desired data even if portions are lost, while UDP has no check for it. Doesn't it mean a difference if this case? I mean, I defined a system where there's no data loss at all, as receiving is instantaneous. In my view, it may imply that checking for loss is unnecessary and might be a waste of resources. $\endgroup$ – Zoltán Schmidt Nov 17 '16 at 16:45
  • 1
    $\begingroup$ @Katamori Ill talk about this in an edit above, its a bit long for a comment $\endgroup$ – Marky Nov 17 '16 at 16:47
  • 1
    $\begingroup$ @Katamori Possibly. The address can be written into the code itself (hard-coded), physically limited (there is exactly one connection at all times, to exactly one place), or dynamic (read a file). The last is a common standard in modern networking (e.g., /etc/hosts on Unix). $\endgroup$ – Frostfyre Nov 17 '16 at 16:53
  • 1
    $\begingroup$ @Katamori when I do software development for clients, sometimes they say "I have device a, and device b, and there going to be connected only to each other and never anything else." In that case, I can throw out a lot of the overhead that usually is necessary. I can make my own format, and just have a sequence for a "stay alive" signal and a "wake up" signal. If they say "...and sometimes the internet..." I have to have all that other overhead stuff for the 'just in case' scenario. $\endgroup$ – Marky Nov 17 '16 at 17:02
  • 1
    $\begingroup$ I don't think there is any need for multiple encapsulation. IP is an encapsulation method that encapsulated (typically) Ethernet. But even then, many of the characteristics of even Ethernet are redundant for this application. Reliability can be left entirely to the applications at both ends to sort out, especially for data rates as low as this. Consider the Internet of Things (IOT) - most IoT devices send UDP messages because reliable overhead is a totally unnecessary burden at the network protocol level for the extremely low bandwidth available for such systems. $\endgroup$ – GrinningX Nov 17 '16 at 19:47

Does it differ from the early days of the internet - in another sense, would it be possible to handle with any protocols ever developed in the field of computer networks?

No, that's not possible, on a fundamental level.

A protocol is a set of rules defining how one thing communicates with another thing in a standardised way. That can be two parts of an application on the same computer (for example, one part of my app sends data to another part by saving JSON to a file), or it can be two wildly different machines in different corners of the globe (for example, I here in the UK can send an email to my friends in New Zealand because someone defined POP and SMTP - some email protocols).

Fundamentally, you cannot engage in any form of communication with anything unless you have a defined protocol. That doesn't have to be a written-down, RFC-numbered, IETF-approved, MDN-documented Protocol protocol, but it's still a protocol.

So: no, you must define a networking protocol before your computers can communicate with one another.

  • 1
    $\begingroup$ I don't see how this is relevant. The question is not about whether a protocol is necessary, but about which protocol(s) to use. $\endgroup$ – Jacob Raihle Nov 17 '16 at 21:27
  • $\begingroup$ @JacobRaihle In part, yes, but it also directly asks if it's possible to communicate without a protocol - the quote at the top of my answer is lifted directly from the question. Don't place too much emphasis on the title. $\endgroup$ – ArtOfCode Nov 17 '16 at 21:55
  • $\begingroup$ It is without a doubt possible. Any existing protocol could be used, but it's more likely that better ones would be developed (or are being developed in the author's timeframe) to take advantage of this new communication technology. For example, Morse code that used to be transmitted over telegraph wires can still be transmitted over an Ethernet cable or satellite link, but there are myriad newer protocols that transmit more efficiently and with better functionality. Modern communication protocols are faster, but that doesn't make them useless. $\endgroup$ – Suncat2000 Nov 18 '16 at 16:40
  • $\begingroup$ @Suncat2000 I disagree. You must define a protocol of some sort before you can communicate - even if you define it only by writing the code that controls it. Or even if you use an existing protocol. You're still using a protocol; you have to have one before you can communicate. $\endgroup$ – ArtOfCode Nov 18 '16 at 16:43
  • $\begingroup$ You mention RFC. Well, they have already thought about this problem: tools.ietf.org/html/rfc6921 $\endgroup$ – Arturo Torres Sánchez Nov 18 '16 at 18:12

A preset based compressed data protocol is what you need. A preset based compression allows sender to select protocol which have a fixed dictionary based on intent. For instance, if you want to translate text, it is best to use low bit counts for highly repeated text. Some words could also be removed automatically. Most of the time skipping a "the" will not cause any issues but it would save quite a bit. Apply Huffman or similar coding to a lot of plain text documents to get the dictionary. Since dictionaries are large, it is best not to resend them. Something similar could be used for other protocols.


The answer to this question is 100% dependent on the traffic which goes over the network. There's a good reason we have so many protocols today. Each operates well in its own niche. If you need synchronous communication, protocols like ATM have value. If your FTL system has behaviors similar to fibre optics, SONET may be useful. If your system is a broadcast system, neither of those would work at all, and you'd want to use something like 802.11b or perhaps one of the other lower bandwidth wireless protocols like Zigbee.

Every one of those protocols I just mentioned are in use today, in one form or another. Each one is used because it fits the roles that it needs to fit.

A big question might be military vs. civilian use. If your system is used by the military only, protocols like LINK-16 have been designed for decades to function well in limited bandwidth environments. Meanwhile, protocols built on top of Turbo Codes were chosen for the Mars Reconnaissance Rover because it made the best use of the limited bandwidth available, and we could spare the resources it takes to decode turbo codes.


First, great question. Second, not to contradict or argue with any of the excellent answers already here, but to offer a very situational alternative: Depending on the technology, if you're envisioning something like quantum entanglement you may not even need to worry about a protocol. If you're picturing something more traditional as far as communications go, then stop reading. : )

With a QE-like system, there is always a direct connection that is always on no matter what, so "communicating" could be more like copying a file from one part of your hard drive to another. There's no such thing as dropped or out-of-sync packs, and no security risks insofar as getting the data from one point to the other. So, even if there's different software running at each end, you only have to send the raw data.

The important thing would just be compressing the data to the smallest size possible given the tight bandwidth restrictions. As long at the compression algorithm is known at both ends, you don't have a problem.

Again, this is just one approach for a certain type of scenario.

  • $\begingroup$ The quantum entanglement is a great idea, but I was not talking about it by reason: I'd like to utilize FTL transmission by means that are custom for my world's "magic". | Thanks for your answer anyway, all of these matter! $\endgroup$ – Zoltán Schmidt Nov 18 '16 at 0:01
  • $\begingroup$ @Katamori Thanks! Maybe it will give someone else some ideas someday. $\endgroup$ – Dan Nov 18 '16 at 0:03
  • 2
    $\begingroup$ @Katamori: your custom magic could still be working like quantum-entanglement. one person's magic is another person's science. $\endgroup$ – eMBee Nov 18 '16 at 14:20
  • $\begingroup$ Did you ever have a failing hard drive? :) $\endgroup$ – AnoE Nov 20 '16 at 9:30
  • $\begingroup$ Even if QE looks like a shared (multi-writable) memory buffer, that doesn't mean you don't need a protocol -- it's still important to be able to determine which content has been written, who's writing now, etc. That might be something as simple as a ring buffer and some flags to determine ownership and completion, but it's still a protocol. $\endgroup$ – Charles Duffy Nov 20 '16 at 16:20

Does it differ from the early days of the internet - in another sense, would it be possible to handle with any protocols ever developed in the field of computer networks?

It absolutely differs from early days of Internet, and here's why.

By the time the Internet was invented, communication speeds were already much faster than your specifications, while procesors were much slower than they are today. You describe a situation, in which the ratio of (computing power) / (bandwidth) is vastly larger than ever before.

So, while it certainly would be possible to use (m)any already invented protocols by adjusting timeouts, that's not what would be done in this situation. Instead, new protocols, optimized for this specific situation, would be invented.

FTL protocol v1 would have concise framing not dissimilar to HDLC or Ethernet II. Some answers named ATM, which is good, except for valuing latency more than bit efficiency, which, I suspect, might be tuned. Directly ontop of that, with no extra layers, would come highly-compressed application protocol data. First, short and expensive military/financial messages with usage not unlike the old telegraph. Then, news and personal messaging.

The layers of contemporary protocols are made to improve separation between the concerns of carrying, routing and using the data, making it easy to replace one without affecting the other. For them to exist, this incentive must prevail over the incentive to make the maximum use of the minimum number of bits. I don't think this would be your case until well into FTL-networked universe, if ever.

If no, what makes it impossible to handle?

Nothing. But the usage would not resemble contemporary Internet until the bandwidth is improved.


I would like to answer @JohnFeltz' comment question:

Any restriction on how many of these devices you can construct and sit next to each other? If I can run 100,000 of these in parallel, I just need an inverse multiplexer to get 5 Mb bandwidth

Unfortunately, if you put two or more of these devices next to each other, they will interfere.

Not only is this a problem for scaling up bandwidth, but also allows jamming of messages you don't want an enemy to send/receive.

Minimum safe distance between transceivers is up to you, just be consistent about it. It might also be a problem only on the sending or receiving side.

"The brave hero sneaks into the palace grounds disguised as a gardener. While replanting a bush she also buries a small box under its roots. Later a timer activates it and communication becomes impossible. The communication officer can tell the emperor that the box is somewhere on the east side of the palace, but actually finding it takes a long search. Meanwhile, the communication crew is relocated to the top of the west tower, trying to listen for messages in the noise."


since the transfer is "instantaneous" you could encode the information not in the bytes you send (as with normal networking protocols), but rather in the amount of time between bits. so, if you want to send the number 255, you wouldn't use a whole byte (8 bits) as with a normal internet packet. rather, you would send 1 bit exactly 255 nanoseconds after the preceding bit. your total realized bandwidth would be limited only by the precision of your clocks and your desired latency. for example, you could say "i will send 1 bit every 10 million nanoseconds. the value that bit represents is equal to the number of nanoseconds since the previous bit was sent". that protocol would give you a maximum 1-way latency of 10 milliseconds, and a minimum data transfer rate just under 300 bytes/second. doubling the maximum latency also doubles the effective transfer rate. more sophisticated protocols could be built on top of this one to negotiate the transfer rate on-the-fly, or to use short-code encoding to maximize thru-put by ensuring the most common data blocks have many leading zeros (so bits are sent faster). you might also want to limit the maximum block size to ensure the clocks stay in sync depending on relative clock drift.

  • $\begingroup$ You can be pretty sure that the term "instantaneous" in the question means that the delivery time of the signal does not depend on the distance between two nodes. Even if the actual FTL transfer is really, really, "instantaneous" (for whatever definition that may be, considering there is not even a true concept of "before/after" for FTL stuff), as soon as you attach even the smallest amount of copper trace at either side, it is not instantaneous anymore. Hence, you can handle the FTL part of the transfer as simply a piece of your copper wire of length 0. The rest of the classical ... $\endgroup$ – AnoE Nov 20 '16 at 10:10
  • $\begingroup$ ... parts of information theory (Shannon-Nyquist) still applies; and as there has been given a fixed upper limit for transfering symbols, there is no more trickery to applied (c/f relationship between sample rate and bandwidth). $\endgroup$ – AnoE Nov 20 '16 at 10:11
  • $\begingroup$ nyquist–shannon sampling theorem only applies to encoding digital information on an analogue signal. there is no reason to believe there is an analogue carrier wave involved here. given the hand-wavy premise of instantaneous information transfer, it seems reasonable (and fun) to put that premise to best use. it's true that the timing and reading circuits would have a max clock speed, but i called that out in my answer as clock precision. $\endgroup$ – james turner Nov 21 '16 at 16:17
  • $\begingroup$ this is clever, i like this very much. creative, fun, and pulls off what the OP is looking for. kudos $\endgroup$ – Ryan McCoy Feb 3 '17 at 7:29

I would use the link directly as a 7 bit dumb serial line and resurrect the ancient UUCP protocols. These things actually have less overhead than modern ones and are better designed to deal with the stupid slow transmit times. The only significant change is replacing uuencode with one of the base85 variants.

  • $\begingroup$ Nice one and thanks for the "blast from the past". :) $\endgroup$ – AnoE Nov 20 '16 at 9:32

I am assuming this machine, which I call The Link, is rare. That is, there won't be enough of them running in parallel to improve bandwidth.

I will offer a different view. The Link would not be on a network in the normal sense. There would be no point to it.

First, due to its importance and the low bandwidth, use of The Link would be tightly controlled so people didn't transmit cat pictures. There would be firewalls to prevent unauthorized access.

Second, due to the low bandwidth, The Link can be though of more as a telegraph than something on a modern computer network. A telegraph (barring the need for repeaters) offers speeds comparable to lightspeed thanks to the magic of copper wire. You close the telegraph key, the other end goes "click". Sure the electromagnet is slow, but the human keying the signals is even slower. It is effectively instant. Consider an underwater cable between the US and the UK. Each country might have a sophisticated telegraph network, and for a small fee Sally in Florida can tell grandma in Maine about her new cat, but which messages would be considered for communications over the underwater cable? Probably not the cat telegram. Instead, it would probably be used for information relevant to politics and high finance.

Of course in 2016, we're not going to have a couple of people tapping out messages on our interstellar link. But it's still like a telegraph. You'd have a computer at each end of The Link. The sender would read from a buffer of messages (encoded, then compressed maximally) and tap them out. The machine at the other end would receive, decompress, and decode.

So while there would not be a network protocol, there would probably be some manner of message protocol so the receiver would know when it was appropriate to decompress the message. A short message would be a 'barn burner' to be sure because the compression per character would be smaller and thus less efficient.

Given how controlled the use of The Link would be, it is unlikely that the messages would be particularly interesting to the normal person just the way in our international example above the normal person would not be too concerned about matters of high finance.

But exactly what messages would be sent over The Link?

Say a sub-light colony ship has reached its destination after 300 years and is beginning to build their new home. The Link is set up.

The first messages sent go something like this:

Hello Earth, we have arrived safely and everything is proceeding according to plan.

(This will be a few characters, perhaps, because of encoding), and answered by,

It's damned good to hear from you, cheerio!

(another 2 or 3 characters)

After pleasantries and diagnostics, what relevance does anything on Earth have to the colony? Help is 300 years away, barring some shocking new discovery. Politics waxes and wanes over the centuries. Countries change. Would the country that sent the ship still exist? Would the World Order that sent the ship be recognizable? What relevance would the colony have to the people of Earth, 15 generations removed from those brave daring souls who boarded the colony ship?

It could be that a cat jpeg might indeed be as useful as any other message.

EDIT - Given the lack of any importance between the day-to-day lives of the people on Earth and the colonists, it would seem The Link in this case would generally be used for low-grade science communications. Observations about the star being orbited, and that sort of thing. I don't know why that would be particularly relevant but it's better than dead air, assuming The Link doesn't wear out from use.

A more likely use of The Link doesn't involved people at all. Instead, the ship housing The Link is purely robotic. These ships are sent by the score to different star systems. They watch, silently and stealthily, for the signals of other races. The data sent back, ever so slowly, is designed to allow humans on Earth some glimpse into the technology of the aliens and hopefully their intent. Sinister, indeed.


Consider this: Luke 17:11 or this: Quran 2:4-5, Oxford World's Classics edition, or even this: "rule 5". They are all references to more extended phrases or texts. The limiting factor in this type of encoding is the availability of the reference(s) to both sender and receiver. English is a highly redundant language, far more efficient languages are known. The typical college graduate has a vocabulary of <20,000 words or word families. One byte allows 65k words to be encoded. So, 5 to 10 bytes/second is faster than speaking and would not be limiting in verbal (as contrasted with visual) data transfer.

  • 3
    $\begingroup$ One byte allows 65k words to be encoded. - sir, that's definitely impossible. One byte equals to eight bits, and one bit has two states. Thus, one byte can have only 2^8 = 256 possibilities. $\endgroup$ – Zoltán Schmidt Nov 17 '16 at 18:11
  • $\begingroup$ Two bytes allows 65k values. $\endgroup$ – Brian Nov 17 '16 at 18:24
  • $\begingroup$ True! He said one byte initially, though. I also think that in the case of 5-10 bps, it is very efficient to send only 2-5 numbers indicating various words/sentences, though. Nice idea, but computation theory is much more advanced even today, than that. $\endgroup$ – Zoltán Schmidt Nov 17 '16 at 18:40
  • 3
    $\begingroup$ There are a lot of limitations with this approach. One is that it basically assumes a text-only relay. Another is the idea of a standard, agreed-upon English dictionary and that it's OK to have to re-load drivers whenever a word changes meaning. Oh, plus that dictionary needs to include obscure/technical words or corporate product names. A third is that adding an "s" to make something plural basically doubles the number of words you need to capture in this system... and that's just one example of how a letter or two can be commonly added to result in significant changes. $\endgroup$ – GrinningX Nov 17 '16 at 19:43
  • $\begingroup$ One byte may well allow 65k words if we stipulate textbook grammar. $\endgroup$ – Joshua Nov 18 '16 at 16:56

I am a bit of stickler MeeSeeks.

I feel like we should be discussing the paradox that your technology presents when trying to resolve it within known modern data transmission conventions.

"humanity somehow manages to transmit data instantaneously"

This element of your world's FTL networks, in particular, renders a lot of what defines modern data transmission conventions (and by extension, how we measure them) effectively useless to you.

With your technology, there is zero-latency. In other words, when I send something, it is received on the other side at the EXACT same time I send it. Not before, not nano-seconds afterwards, but at the exact same time in some distant place. If resolving this situation within modern networks, your data throughput would be off the charts. In essence, you could cram an infinite amount of information through this network as there is theoretically no limitation. At least not yet...

"but the speed itself is slow - let's say, being able to send 5 to 10 bytes (10 to 20 hexadecimal codes) per second."

Here is where your situation gets a bit unique. Thought experiment if you will:

When I post this answer, you will receive a notification. Pretend for the sake of our discussion that we are operating on your world's tech. When I press this "Post your Answer" button, your device will ping you with this notification - both of these events will happen simultaneously. BUT how much data was sent?

The main conundrum here is that IF data is sent instantaneously, then measuring data throughput over a period of time is pointless. And if bandwidth measurements don't apply, then how and/or why is your technology so limited?

My Answer:

Given your technology's facts, and sticking to within context of your question, if I were you I would not worry about defining the transmission of information with modern networking principles. I would focus on defining why things are the way they are in the simplest of ways.

For example:

  • Data transmission is instantaneous because of {insert preferred theoretical instant information transmission concept here, ie. quantum entanglement}
  • The technology is limited to an on-and-off state (similar to binary systems), providing you a limitation to the data that can be transmitted, as well as providing a rationale for resolving the limitation of the amount of data that can be "sent" over a given period of time despite the "sending" of that data being instantaneous. Explanation: the data itself is in both places at the same time, but the system state can not be both ON and OFF at the same time. Meaning the lag in information transmision is not due to latency or bandwidth, which as we discussed don't necessarily apply, but instead is limited by a functional limitation of the system in place.
  • Optional: Systems are male-female, with communication only being possible between paired systems. No real reason, I just like this as a further limitation, since the context of your question really boils down to: "If data can be transmitted instantaneously, how do I rationally limit the technology for the inhabitants of my world?"

Conclusion: As with anything of the imagination, do with all of this as you please. Because hey, its your world. And thank you, this was probably more fun for me to write than it was for you to read.

  • 1
    $\begingroup$ I thought you were going to say use the timing of the message as the main information channel. My understanding of the OP's description is that when a packet is sent, all bytes go simultaneously (i.e. as an atomic operation), but there is a hard upper limit on packet size. There's also a very high inter-packet delay to cycle the equipment. And given the OP's limited familiarity with networking, I was actually assuming not simultaneous transmission of all bits in the packet, but just that it went in a burst and the time didn't scale with distance. It doesn't have to be instantaneous. $\endgroup$ – Peter Cordes Nov 18 '16 at 9:59
  • $\begingroup$ @PeterCordes Safe assumptions to make, though assumptions none the less. Since his familiarity with networking is indeed limited, I chose to take his words literally as that was the safest bet. And again, because it presented a logical paradox, was the most entertaining angle to explore haha $\endgroup$ – Ryan McCoy Nov 18 '16 at 10:35
  • 1
    $\begingroup$ Squint a little. It may be possible in the OP's world to send a bit instantly, but that doesn't mean that bit is distinguishable from the noise. Instead, the bit has to be sent instantly perhaps 1000 times in order to distinguish the value with a suitable level of certainty. Of course, that conflicts with the OP's 'lossless' requirement, but the OP may not even know about error correction. $\endgroup$ – Tony Ennis Nov 19 '16 at 17:52
  • $\begingroup$ @tonyennis valid counter-arguments, but like Peter above you are making your own assumptions that are not explicitly covered in the OP's question content, and in fact contradict the information he does provide explicitly. All of this is however completely irrelevant, because my friends, we are on a board discussing make-believe concepts. To argue in support of your idea is kind of pointless, don't you think? $\endgroup$ – Ryan McCoy Nov 21 '16 at 10:09

What kind of information do you wish to transmit? If its just plain text then implement something like the Library of Babel on both ends. Then you just have to transmit positional information of the desired message.

This assumes that in this world of FTL communication processing power and data-storage are essentially non-issues.

Clarification: What i was meaning by referencing the library of babel is a lookup table of sorts. This communication would have been created for a specific reason. My assumption is that this is for interstellar communication rather then to send something a few miles away. Therefore there would be some form of encoding to ensure that the intent of the message is sent without possibly the need of sending the literal information. Why send 30,000 bytes when I can send 10-20 that point to a lookup table that conveys the entire message.

  • 2
    $\begingroup$ I don't think either of those are serious considerations here. If you need a fix point, start from the assumption that processing power and storage space are AT LEAST as developed as today, in late 2016. Maybe even better, but in my view, even today we CAN solve this issue if ever occurs. $\endgroup$ – Zoltán Schmidt Nov 17 '16 at 21:21
  • $\begingroup$ The thing with a "library of babel" type system is the pigeonhole principle. At some point the positional information is as large as the information you are trying to send. Compression programs work because you already know what type of data is to be compressed (simple patterns with repetitions), but they may make files larger if used incorrectly. $\endgroup$ – DOS4004 Nov 18 '16 at 6:22
  • $\begingroup$ Technology exists to fill a need. It is our overcoming a challenge. So the implementation to make this FTL usable is relative to the role it is trying to fill. $\endgroup$ – Tribmos Nov 18 '16 at 13:19

I was going to post the same observation as James Turner, so I instead upvoted his answer and thought of an objection (which also might explain both the jamming effect and the slowness of the transmission).

If the transmission was flawless and instantaneous, then if it was possible to resolve time with nanosecond precision, I could agree on a signal being sent every 1.048576 ms (at most), with a delay of 0 ns meaning 1111111111 and a delay of 1048575 ns meaning 0000000000. Ten bits every millisecond and we already are in the 10 kbit/s range (and, on average, better).

So I posit that while the transmission of the signal is instantaneous, resolving the signal is a probabilistic process. Analyze a 1 ns window, and the chances of telling apart a "signal" or "lack thereof" are nil. To reach a certainty of 99% you need to analyze a whole second's worth of transmission.

So of course the engineers reached a compromise, and combining shorter times with compression and error correction schemes, they raised the bandwidth to 40-80 bits/s.

If we place two transmitters nearby, about 50% of the time one will transmit a 0 while the other will transmit a 1, which will increase the error rate at the receiving end, forcing a lower speed; so scaling the device avails you nothing.

On the other hand, how far need the transmitters be from each other to stop interfering appreciably? Say it's 500 meters; in space, you might build an enormous communication array, a wireframe cube ten kilometers in size, made up of 500 m "wires" holding in place some eight thousand transmitters, coordinated through normal sub-light signaling. Planets might communicate between them using surface networks; ships would be much more limited. The consequences seem interesting.


This discussion seems very narrow – I'd look at the question from a few steps back.

I assume the context is an interstellar civilisation, since otherwise it's hard to see the advantage over existing communications technology. If this civilisation has FTL travel, then it would be more effective to ship data physically: a single Micro SD card could hold more than 500 years' worth of transmissions.

If you have FTL communications, but travel is slower than light, then it becomes more interesting. For all of history, people have been able to travel about as fast as information; recently we have instantaneous communication, but it also doesn't take more than a day to travel anywhere if you're in a hurry.

If distant worlds could talk in real time, but travel between them took decades, that would be a completely new type of reality. Launching a weekly thimbleful of memory chips would still offer greater bandwidth than the FTL radio (by many orders of magnitude), but the latency would be decades vs. minutes. There are interesting implications.

Suppose the people of Earth were obsessed with Omicron Persei VIII's version of Shakespeare. Thimbles would deliver all the plays and movies and interviews Earth could consume, but they'd arrive long after Space Shakespeare's death. A wealthy Terran could rent 15 minutes of FTL radio time for a live chat, but the best they could do would be a chat with Spacespeare's grandchildren. Or, you could chat with a living Omicronian celebrity, but only your grandchildren would get to see what they were famous for.

Economically speaking, it's hard to see the real-time communications playing much role in cultural trade. People might pay to watch movies from Space Hollywood, but they'd just consume the 200-year-old movies that arrive by thimble, and treat the 200-year-old version of Space Hollywood as "the present day".

The FTL radio would only really be good for spoilers. Which is not very important for trade, but would obviously be useful for warnings of massive invasion fleets / supernovas / etc. In fact, that service might be an important guarantee for trade; if you don't pay your Space HBO bill for the shows they sent 200 years ago, they won't warn you about that asteroid next March.

(vaguely related, the Nobel laureate Paul Krugman once wrote a paper on the economics of sublight trade).


Some of the answers above touch on the idea of encoding vast amounts of data using giant dictionaries; this idea has a long history, from at least the 17th century right up to the 1950s, when it was dismantled in the course of creating Information Theory.

The idea is that you write out every possible book, put them all in order, and then just refer to them by number. The problem is, a book is already just a sequence of bytes, i.e. a long number, and giving a number to every book means the number will be as long as the book itself; in fact they will be the exact same sequence of bytes.

Of course, most strings of bytes aren't "real" books, and if you just include valid English texts, you can skip most numbers. That does indeed lead to significant data compression. But it also requires an algorithm to generate every possible "meaningful" text, which is to say, an algorithm that can enumerate every thought a human could ever have. That is... challenging... and requires a lot of disk space.

Practical compression algorithms do use this kind of "dictionary coding", but it's much more basic. The trick is actually to leave as much as possible out of the dictionary, so that only very common strings are replaced by very short codes, so for example the cat sat on the mat reduces to 1 c2 s2 on 1 m2. If you used a prearranged dictionary that included every known word, you might end up making the message longer (23 4954 3430 109 23 908078).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.