On Tue, Feb 4, 2020 at 1:18 AM Go Luhng <golu...@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. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
