[tor-dev] Stem ORPort protocol support

[meejah]

Damian Johnson <atagar at torproject.org> writes:

> Thanks meejah! Took a peek but they both look pretty old and it's
> unclear to me how complete either got. If there's something in
> particular you think is worthwhile integrating I'm all ears.

I haven't looked closely enough to know the answer to that ;) but as I
understand it had (2 years ago) enough to bootstrap and make circuits.

>> For any of these efforts, writing a "Tor protocol library" that
>> *doesn't* do any I/O would be the most useful; then other Python tools
>> can benefit from the protocol support without being tied to "threads" or
>> to a particular async framework.

> Actually, this uses a similar pattern as the rest of Stem in that cell
> packing/unpacking is independent of the threaded socket. Just as you
> could use stem.response for controller message parsing in txtorcon,
> you can use stem.client.cell for cell packing/unpacking with a twisted
> application too.

Interesting, okay! Last time I looked, I had to re-assemble the whole
"response" to feed it into stem.response -- so I ended up needing to
keep most of the protocol state-machine anyway (i.e. to figure out which
bytes constituted "a response"). I should probably look again if this
has changed :)

The way Hyper/h2 works is it just gets fed bytes and "interesting
events" come out (essentially), as I understand it. So, the
corresponding thing here would be: set up some Stem 'protocol' object
with an "interesting event happend" callback. Then, feed bytes into some
single API on this object and it calls the "event happened" callback
every time enough bytes have been fed in for a complete parsed response
object to be generated. (This is just the one side of the protocol; the
other side would be similar)

-- 
meejah