Because connectivity is becoming less a convenience and more often a necessity, if not a criticality, there will be a built-in demand for 24×7 connectivity to/from data sources and targets.
In professional audio, wireless mics used to be a particular problematic technology – while allowing free-roaming around the stage, they were subject to drop-outs and interference from multiple sources, causing unacceptable interruptions in the audio signal quality of a performance. The manufacturers got together and created multi-channel multiplexing allowing transmission of the same signal over multiple channels simultaneously, so that if one channel were interrupted, the other(s) could continue unimpeded and guarantee interruption-free signals.
Now we need the same thing applied to network technology – in particular, the ever-expanding Internet. Conventional Transmission Control Protocol/Internet Protocol (TCP/IP) addresses single source and single destination routing. Each packet of data has sender and receiver information with it, plus a few extra bytes for redundancy and integrity checking, so that the receiver is guaranteed that it receives what was originally sent.
The problem occurs when that primary network connection is lost. The protcol calls for re-transmit requests and allows for re-tries, but effectively once a connection goes down, it is up to the application to decide how to deal with the disconnection.
The answer may be the same as applied to those wireless microphones. Imagine two router-connected devices, for example a computer and it’s internet DSL box. Usually only one wire connects the two and if the wire is broken, lost, disconnected, the transmission halts abruptly.
Now imagine having 2 or 4 Cat-5 cables between the devices, along with a network-layer appliance that takes the original TCP/IP packet from the sender and adds rider packets with it to include a path number (i.e. cable-1 to cable-4), plus a timing packet (similar to SMPTE code) that allows the receiver appliance to ensure packets received out-of-order due to latency in different paths, are re-assembled back in the sequential order as they were transmitted.
Then run these time-stamped and route-encoded duplicate packets through a standard compression and encryption algorithm to negate the effects of the added time and channel packet overhead.
[Addendum: 22-MAY-2015] Think of this time+route concept similar to how BitTorrent operates. There are already companies working on channel aggregation appliances, but usually for combining bandwidth. This approach is focused on the signal continuity aspect of the channel communication.
Reverse the process at the receiving end, and repeat the algorithm for the reverse-data path.
Transmitter] — [data+time+channelID] — [compression/decompression ] => (multiple connection routes) => [resequencer] — [Receiver
Time for some creative geniuses to make this happen, yesterday. Banks need it. Companies need it. Even the communication carriers need this.
@jhlui1 #DreamBig #ChangeTheWorld