Future work
Network changes
What most production software has is some kind of logic to detect network changes. Events like disconnects, external IP changes, changes to the gateway, or active NIC, allow the program to react to changes. I’d like to eventually have code to detect such changes on all major operating systems. Then give pipes the ability to add handlers for such events. This would make it very easy to engineer highly reliable networking software.
Firewall bypass
Windows-based operating systems include firewalls that will prompt the user if they want to allow an application to use the Internet. Mac OS X has similar security measures. A user without much experience may not know what to do. It would be a good idea to automatically setup rules to allow P2PD to use the Internet on various platforms. I’d also like to put some work into packaging in the future so that this software is as easy to use as possible.
Pushing sockets
One common criticism against Python is that ‘it’s slow.’ I don’t believe this is the case but let’s suppose that it is. Let’s suppose that an engineer has a very good reason not to use something like P2PD 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 could mean is that P2PD could specialize in the initial process of opening up connections with remote peers and then passing those bound sockets to other processes to use as they see fit.
I think this could be a really cool option because it would allow engineers to reuse their existing networking code. Maybe they have a different event loop. Maybe they use a model based on threads and polling. They would be able to use the networking features they’re already familiar with for their respective software stacks. I think it’s an interesting idea.
Error recovery code
As I sit here reflecting on this project I’m reminded of just how many ways networking code can fail versus regular algorithms. 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 programming languages. There are many other ways sessions can fail and most developers manually handle the edge-cases themselves (like reconnect.)
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.)