Information Exchange In Space

Something I realized not too long ago about a spacefaring society is that while a lot of technology is going to feel advanced, a lot more is going to feel ancient just because of all the hurdles it has to overcome in order to work in the first place. One example of this is communication.

The way I'm currently explaining it in my world is that in order to travel faster than light, your ship has to go into quickspace (hyperspace, slipspace, you know, that alternate dimension where physics lets us do whatever we want). Quickspace works a lot like an ocean, where there are currents and winds that can either help or hinder a ship as it travels. The thing is, in order to use quickspace, you need a viable method to enter and exit it (otherwise, you're pretty much stuck there for good). This means that a signal sent through quickspace will go way faster than any ship, but it's never going to know when or where to stop unless it's contained within some sort of ship capable of pulling it back into realspace. This means that information travels only as fast as ships do, and we're talking anywhere from days to years for intersolar travel.

So, then, my question is how would our modern communication systems adapt to handle this lag? Considerations for how news/messages travelled across oceans in the past would be great, but I'm also concerned about how we deal with things like the Internet with an average ping of a couple months.

• So how do you handle the terrible, horrible, no-good causality paradoxes that come from FTL? Feb 17, 2015 at 16:31
• @SerbanTanasa Honestly, I still can't believe that those exist. But say I liken quickspace travel to teleportation, with some travel time based on distance? And the travel time takes place in a smaller universe that may not have a speed limit? Basically, I remove relativity and the hard limit of c from the equation? Feb 17, 2015 at 16:38
• Well, easy. If an alien ship from a enters your system and fires a doommaker at Earth, all you gotta do is find a capital ship moving such that it is in a spacetime frame where the ship hasn't entered the system, communicate FTL with it and make it launch a laser at where the enemy ship will be (from their perspective). This destroys the enemy ship before it fires, so how did you send the message? Feb 17, 2015 at 16:49
• Okay, this time I've got it. Quickspace offers four-dimensional travel perceived as three-dimensional travel. Basically, since going faster than c makes you go back in time, travelling in quickspace makes you go forward in time to offset it. To you, you get places faster, but to any observer, you get there after you left. Travelling forward in time doesn't violate causality, so I win. Right? Feb 17, 2015 at 17:18
• @DaaaahWhoosh, sure, but that means that 100,000 years pass on Earth as you take a quick trip to the galactic core and back. As long as you're fine with that, no paradoxes. Feb 18, 2015 at 3:00

Actually, even with contemporary communication protocols today, latency is not really an issue as long as the link is reasonably reliable. This is a delay-tolerant network. Note that in the real world, with long-range communications you are going to have to add a good chunk of forward error correction so that the majority of errors can be repaired without requiring re-requests and retransmission of the data.

There was even an Internet Draft published some years ago that discussed how an "interplanetary Internet" could function. I would have to go and dig it out, which I am not terribly inclined to do at the moment, but the gist was that yes, it would work quite well with only minor alterations to the low-level protocols. IP would be fine. UDP, ICMP and friends wouldn't fare too poorly. TCP wouldn't do great in a high-latency environment with its roundtrips, but that wouldn't necessarily be a showstopper if the latency can be kept to a reasonable level (think perhaps minutes; the limiting factor would probably be a combination of how long you're willing to wait, and your ability to track both endpoints in space).

The real killer was when you started applying the high latency to higher-level protocols, and contemporary implementations of those. Something like plain HTTP, with a single request followed by its associated response, wouldn't be too bad. A protocol designed to be used interactively, like FTP or SMTP, however would not work very well as currently designed because the latency would be multiplied by the number of roundtrips. DNS would definitely have problems because it is relatively latency-sensitive. This is not an insurmountable problem, but it is something some of our current protocols are not well equipped to handle being designed for an environment where a latency of one second is extremely high.

Since this I-D was written in the context of our real world, with our real world physics, they also had to deal with the fact that not all nodes would be visible (radio link wise) from all other nodes, or even any given nearby node, at all times. So how do you solve all this? Well, it turns out an easy solution is to design a network using

store and forward

Store-and-forward is a very old technique for building computer networks. Technically at some level all switched or routed networks are store-and-forward, but the forwarding is done so quickly we don't normally think of them as such. In a real store-and-forward network, you may hold on to packets for hours or days until they can be transmitted to the next node, bringing them closer to the destination endpoint. For two examples of store-and-forward networks, consider Usenet and FidoNet. Internet e-mail also used to work in the same manner.

Store-and-forward networks do not provide real-time communication services, but lend themselves very well to batch- and message-oriented communications. E-mail (both personal as well as in the form of discussions) works well in such a network. Web browsing as we know it wouldn't work as well, simply because of the delays involved, but there is nothing in principle that prevents it from working. Delivering batch requests to be processed and the results later returned works fine. And so on.

So you'd have to design your communications systems to account for this latency. That means no video screen showing a faraway higher-ranking commander for a two-way chat. Depending on how much bandwidth you have and the needs of the story, you could either have audiovisual, just audio, or just text, with or without separate channels for data for computers to process. Just text is where it would most likely start out, since that requires by far the least bandwidth (and as an added bonus is possible to skim through and get the general gist of, unlike a video message which must be played back at normal speed). It also means communications more like e-mail or perhaps even postal letter, or something like what we're doing right here on Stack Exchange with the question and answers format, and much less like a telephone conversation.

The actual data could then be carried by specialized vessels, or piggybacked on ships already enroute to the destination area, or carried through a quickspace network like someone mentioned and carried into normal space near the endpoint. But the above allows you to deal with the latency introduced by the fact that the message must be carried somehow.

• While UDP might work, it would be pointless to use it: its goal is to reduce ping to allow real-time applications, so if ping is too high anyway, it doesn't have any real use. (unless you plain to build an alternative TCP-like protocol on top of it, of course)
– o0'.
Feb 22, 2015 at 0:07
• @Lohoris Your comment doesn't make much sense. UDP and TCP are good at different things. In a low-latency environment, UDP is used for example where packet loss can be tolerated and the potential unpredictability in delivery time of TCP cannot. Audio and video streaming are two common examples (DNS is another, but DNS can fall back to TCP for large packets); losing an IP packet's worth of streamed AV data doesn't significantly impair understandability, but stuttering while the TCP stack is reconstructing the stream with the packets in the proper order can significantly impact usability.
– user
Feb 22, 2015 at 12:03
• Using TCP for something like DNS which can be done over UDP and which works with mostly small amounts of data would increase the number of packets several times over. (Also in a high-latency environment), UDP has the advantage that it avoids the SYN/SYN-ACK/ACK roundtrip for connection establishment of TCP, which is not particularly significant for large transfers in an environment where roundtrips are measured in hundreds of milliseconds or less, but can be a quite significant difference in an environment where roundtrips are measured in potentially hundreds of hours or more.
– user
Feb 22, 2015 at 12:03

What about having comm stations inside quickspace? So you send a bunch of them into quickspace, create a network of communication and when you need to send a message, you'll send it to that network, the message's data will contain the coordinates of it's destination and once it reaches the closest comm station within QS that can send it out into normal space, it does.

Yes, there is the obvious issue of wanting to send a message further than what the QS comm network can reach. In that case the message would travel faster than light up to one point and then it would continue going through normal space at the speed of light until reaching it's destination.

• This. Very unexciting and technical, so pretty much as realistic as it gets. For an observer you would just have normal stations in RS somehow sending messages between each other in QS. The fact that they have a counterpart in QS and a proxy that goes between spaces at 1000 times per second transferring info between the 2 parts of the station is implementation details. And even if the frequency of such transfers is limited - it's only a constant latency overhead. Feb 18, 2015 at 13:42

Pony express Information is uploaded to high capacity media with high speed read and write (SSD disk could be great example of this) and then sent via ship to its final destination. There would be small (one person?) ships designed for speed.

Fun side note. Even nowadays it is faster to send information via post than via internet

Tube post Lets go even smaller: Have a fully automated capsule programmed to go directly from point A to point B. That ship would probably consist only of:

• A computer able to go only from point A to point B through quickspace (the smaller, the better)
• Quickspace drive just big enough to get you from A to B (getting the hint?)
• Payload, aka the SSD disc (or anything with really high speed read and write access)
• Fuel (I dont have to specify how much you need, right?)

Basically, the setup you would go this way:

1. Pony express companies would arise. Small ships would take care of sending information from there to here and back
2. Someone would work hard on automating the whole process as much as possible. The smaller, the better (tube post)
3. Add accuracy to tube post. Whoever can manage the tube to re-enter into normal space at exactly given point wins
4. Outposts arise. You would send tube post to well connected centers of information
• I considered something like this tough i was in to something like writing on paper again, but yes, if ships travels just as fast as radio signals, there will mostlikely be carrier ships. Just like old fashion mail. Most likely using harddrives or SD-cards. Feb 17, 2015 at 15:50
• I got excited with the idea of one-person message ships, then you reminded me that robots are better than humans (as they are for just about everything). Oh well, I guess if we can't have space ponies we might as well just use robots. Feb 17, 2015 at 16:16
• Sad news is: Why use robots when all you need is one computer chip? Feb 17, 2015 at 16:34
• @DaaaahWhoosh Some stories use some variant on biological brains being special and AI's being unable to handle navigation of their version of FTL. (like Andromeda) This allows for more interesting stories. Feb 17, 2015 at 16:35
• @PavelJanicek I meant the ship was the robot, with the chip as its 'brain'. I guess I should have called it a drone? I keep forgetting it's important to be politically correct when talking about synthetic life forms :) Feb 17, 2015 at 16:45

I'm going to make a few suppositions, the first is that you can send a signal in the Quickspace even if can't leave.

2nd you have some ability to direct the signal, since you can direct a ship.

So What I would expect to speed up communication would be to have relay stations, some permanently in the Quickspace boosting and relaying messages like a router and at end points machines that can pop in and out of quickspace to send/receive messages from real space. It might be cost prohibitive to use it to call family every night but it would allow much better and faster communications.

There will still likely be lag, but it will be much more manageable. However, the lag will be the primary restriction on how far 'Earth' could extend it's influence to other colonies. The farther away less, and the less the colony needs anything from earth or other systems it will also reduce their need to appease.

But for how the average person would handle the lag look back to the US and Europe and the rest of the world through the 19th century until the telegraph started connecting the world.

• I imagine relay stations would be hard to place/sync/manage, but their benefit is obvious. They probably would be used for nearby/important colonies. Great answer. Feb 17, 2015 at 16:07

It's a little bit frivolous, but high latency 'internet' has been tried - the protocols support very high latencies, although you do have a pretty fundamental problem with retransmission and error correction.

http://en.wikipedia.org/wiki/IP_over_Avian_Carriers

But pretty fundamentally - the internet protocols as they exist have reliability and retransmission built in. That's just horrible when you've got high latency burst communications.

What I'd imagine you'd get instead is basically what we have with email - email was designed for an era when the average user dialed up to a local point of presence via a modem. Internet comms weren't 'always on' for businesses either. You send your mail to a local gateway, and it'd attempt to deliver later.

This would work in your scenario. Electronic mail packets containing emails being shipped back and forth. You may also want to look at older protocols like Archie, Gopher and NNTP as well. These are also from an era of 'not always on'.

I think what you'd end up with is multiple similar, replicated and synchronised internets. Maybe you'd ship a large 'internet backup' back and forth on each courier, and resync the differences between each, sort of like rsync would.

• Interesting answer, and as I'm currently taking a Networking class looking into older protocols may prove a useful experience. Feb 17, 2015 at 20:58
• In all honesty - probably not. The older protocols are built on a load of assumptions that don't really apply any more. That internet is intermittent links, and so data must pretty much all by store-and-forward. The ones that hold value today are still (just about) in service. Feb 17, 2015 at 22:11

Another solution (which also breaks laws of physics, but in a different way) is something like Ansible instantaneous or superluminal communication.

To make it more limited, make it that every pair of ansibles can communicate only with each other (coupled quantum atoms or similar handwavium), so to talk to 1000 different world you need 1000 ansibles. Yes, a hassle, but certainly worth it.

• That's an option, but my question was more about dealing with the lag rather than removing it entirely. The Fellowship could have used the Eagles to get to Mordor, but they had much more fun walking. Feb 17, 2015 at 16:24

The RPG Traveller (1st edition in 1977) has a communications model for interstellar communication - The Express Boat Network. http://wiki.travellerrpg.com/Express_Boat_Network

The express boat (also called an xboat) is a small, fast ship filled with a pilot compartment, message data banks, and jump drives. The fit is so tight that there is no room even for maneuver drives. Each is capable of jump-4 (four parsecs per week); it jumps, relays its messages to the station on arrival, and then waits to be picked up by a tender, to be refueled and sent on its way with a new load of messages. The local station, meanwhile, accepts messages, encodes them, and transmits them to a tender at the edges of the stellar system. Messages brought by the arriving xboat and intended for further down the line are consolidated with the new data and all are sent on to another xboat already fueled and standing ready to leave. The entire network operates like the pony express — messages are always moving at top speed. Transfer time for messages from one xboat to another can be as short as ten minutes, and is rarely more than an hour.

Note: a jump in the Traveller setting takes one week, regardless of jump length.