[Twisted-Python] Supporting a two-part client protocol.

[Colin Dunklau]

On Tue, Feb 4, 2020 at 1:18 AM Go Luhng <goluhng at gmail.com> wrote:
>
> > Colin Dunklau wrote:
> >
> > Assuming the header has a fixed length,
>
> It does. The header is just a serialized C struct, so it's
> fully-specified for length and offset of each field.
>
> > OTOH, that's for stream protocols, so if you want to eventually handle
> > UDP, it's probably nicer to do the full sans-io thing
> > (https://sans-io.readthedocs.io/) and wire it up with a more-basic
> > Twisted protocol.
>
> Could you elaborate on this?  I'm new to Twisted, and also unfamiliar
> with sans-io.
>
> Specifically, I'm wondering what type of "more-basic" Twisted protocol you mean.

The sans-io pattern is described well at that site, including a link
to Cory Benfield's great talk
(https://www.youtube.com/watch?v=7cC3_jGwl_U). The idea is to keep
your protocol logic strictly separate from anything that does IO (like
a Twisted Protocol's `dataReceived` and its transport's `write`
method, or an asyncio thing, or blocking socket operations, etc), to
make it easier to test and reuse.

By "more-basic" I mean twisted.internet.protocol.Protocol and
twisted.internet.protocol.DatagramProtocol.

If you don't go full sans-io, I'd still strongly recommend splitting
up you protocol implementation into distinct pieces. Twisted protocols
can become hard to reason about when they become implicit state
machines... avoid it by making a separate, explicit state machine and
use that in the Protocol, instead of dumping the bits on the protocol
instance itself. This way you at least still get the testability.