Update including daemon and gossipsub discovery

[notassigned]

I've made quite a few changes under the hood and I would like to get some feedback. The code can be cleaned up a bit but the idea was to make it more reliable and quick.

Changes include:

• Faster LUT for packet switching using ipv4 addrs as uint32 instead of string
• Gossipsub for peer discovery
• Daemon which can be started in foreground with sudo hyprspace daemon up
• Command to get currently connected peers hyprspace peers <interface name>
• Configurable transports (quic, tcp)
• Configurable auto relay (on/off)

https://github.com/notassigned/hyprspace/tree/reliability-connectivity-upgrade

[alecbcs]

@notassigned this looks good!

• Daemon which can be started in foreground with sudo hyprspace daemon up

Any particular reason you changed to this instead of the existing?

hyprspace up --foreground hs0

Also have you done any performance testing of these changes? Both network throughput and reconnect times?

I'd say go ahead and submit this as a PR when you are ready and then we can work on flushing out some of this together.

[alecbcs]

@notassigned Oh interesting! By having multiple interfaces run on the same program does that mean that all of the interfaces share a single internal libp2p node?

[notassigned]

Oh interesting! By having multiple interfaces run on the same program does that mean that all of the interfaces share a single internal libp2p node?

They don't right now, each interface still uses it's own full libp2p node, but what we could do is have the daemon start a full libp2p node with an ephemeral identity which bootstraps the local dht and can join gossipsub topics on behalf of an interface with a bare bones node for discovery which would allow hundreds or thousands of hyprspace interfaces to be run with the same resource usage as a single current one.

Also, I tested my build with iperf and the bandwidth sucks (about 25% that of the main branch) so I ran wireshark and found that there is constant TCP re-transmission going on. I'm still trying to debug why that's happening.

[notassigned]

Some packets are out of order.... I am losing my mind.

This guy has the same issue it seems. If you know how to fix this, lmk.
https://stackoverflow.com/questions/67779021/golang-tun-udp-vpn-very-slow-tcp-connections-with-lots-of-out-of-order-segment

[alecbcs]

Hey @notassigned, out of order packets shouldn't matter? It's common for packets to be delivered out of order on the internet and that's why TCP has built in systems for tracking packet order and re-requesting lost packets. So if any application is using TCP on top of Hyprspace that TCP connection should take care of reassembling the packets not us. Also if any application is using UDP there are no order guarantees and thus the application itself should be able to deal with different packet orders.

If you're getting network slowdowns that might be because packets are actually being lost/taking so long/so out of order that the system is re-requesting them multiple times.

[notassigned]

Yeah, it just seemed a bit excessive but I guess it's ok. I'll open a PR.