"Can we descend to flight level 100: I'm only getting one bar"...
The amount of handoffs between cell towers would be pretty hardcore at low altitude, even with good range.
🇳🇱
@skanman It actually is a fundementally limiting problem.. by all known algorithms so far it is a unsolvable problem.. though some do debate the topic often.
@freemo Algorithms can't solve it, it's a protocol problem. The towers handshake with the device, but the towers are actually proxies. This is why your IP on your phone isn't actually your real IP, it's your ISP proxy. The real IP on your phone changes when it connects to a new tower, and the proxy updates to the new IP, but to the rest of the world, you're on the same IP. The problem is the proxy only has access to a certain array of IP, and all the towers can't go assuming you're gonna connect and reserve the IP. Algorithm writers can try all day long to make these predictions, and even add VPN tunneling to hide the hand off. But the solution already exists, with IPv6, don't need the proxy anymore. Just update the routing table each hand off. Problem solved. This problem will fix itself as the world slowly deprecates IPv4
@skanman The issue is deeper than that.. when messages have to go many hops through a mesh network without some big long distance hop.pipe to supplkement it then you get bottlenecks where the network simply can not carry the volume of data.
As you point out there are plenty of other issues on top of that though.
@freemo ooooh yeah, I didn't think about that. I had that exact same problem when making this p2p video conferencing app like 8 years ago. Took 3 years for me to fix. I ended up creating client side encoding. Person A to Person B, Person C connects to Person B and and Person Bs client downsizes encodes A&B together to send to C, if person D connects, C's client encodes ABC together. This distributes the work of encoding on all clients, and reduces the mesh network to a pipeline. Every 10 seconds the encoding priorities update by ping time and dropped frames, after 2 cycles you'd never know. If someone drops out of the pipeline, the client fetches the previous pipeline order from the server and reconnects the broken link. I wonder if something like this might be possible for the cell tower problem.