OoMrFlibble
commented
4 days ago Some thoughts. Largely based around how huge the Twisted documentation is, and how it's let us down on the Mac, being too opaque to easily debug between the layers. It's very clever, granted, but perhaps too vast to be easy to manage unless using it regularly in a variety of ways.
On deeper inspection of the situation, all the interesting stuff happens on top of a bog standard TCP stream, and we're effectively serving only one client per port.
If no server responds at startup, Oolite will wait until "pause and hit 'c'". So no reason for console to care about other clients on a given port after one client is connected.
I'd assume that it's wrong to listen for SYN on 'any port at all' while a client is connected. What would the console do with two connections at once?
I speculate that there's little reason to employ Twisted for this simple task. Python's native networking tools have improved over the last few years, and if we're sticking with >=python3 for this version, it may be time to simplify the network core of it.
I get that twisted can handle some of the higher level protocol stuff, but given the simplicity of the Oolite debug console protocol, it'd probably be just as easy to handle that in native python.
There's a choice between terse code, using complicated libraries that bury one in documentation, or slightly longer code that is based on terse, comprehensible documentation.
I'll look into this down the line, or as needs must.
Earlier investigations caused by the MacOS issue, lead me to observe that a new listener popped up on a port despite it being alreaady connected.
Should that happen? How does twisted (and indeed the console) cope with it if another Oolite connects.