Future work
Network changes
Most production software has a way to detect network changes. Events like disconnects, IP changes, gateway changes, or default NIC changes– make the program more robust. I’d like to eventually have code to detect these changes for all major operating systems. Then give pipes handlers for such events.
Firewall bypass
Windows-based systems include firewalls that can interfere with some programs. Mac OS X has similar security measures. It would be a good idea to automatically setup rules to allow aionetiface to use the Internet on various platforms.
Pushing sockets
One common criticism against Python is that ‘it’s slow.’ I don’t believe this is the case but let’s suppose it is. Let’s suppose that an engineer has a very good reason not to use something like aionetiface for their peer-to-peer networking code e.g. they may have already written highly optimized networking code themselves. Well, it’s possible to pass a socket from one process to another. What this means is aionetiface could specialize in the initial process of opening connections to peers and then passing those bound sockets to other processes to use as they see fit.
I think this could be a cool option because it would allow engineers to reuse existing networking code. Maybe they have a different event loop. Maybe they use a model based on threads and polling. If you could pass sockets around an engineer could use any networking features they’re already familiar with.
Error recovery code
As I sit here reflecting on this project I’m reminded how many ways networking code can fail. As an example: on Windows if you switch between wireless networks there can be a delay until being able to use that interface for Internet traffic. I don’t know why that is. It may be an issue with router advertisements and ARP. But what I know is any code that runs shortly after the network is changed is likely to fail despite having ‘correct’ addressing information.
I think it would be worthwhile making a list of common failure scenarios and writing code to prevent it from occurring. Really, only the most basic networking features are provided in most programming languages. There are many other ways sessions can fail and most developers manually handle the edge-cases themselves (badly e.g. reconnect loops.)
Other ideas
Send duplicate signaling msgs in case a MQTT server goes down.
Ability to restart broken TCP connections after disruptions in Internet. Many simple servers start a fresh state per connection and in some scenarios (like multiplayer games – it can mean being unable to rejoin sessions.)