[tor-dev] Connection, Channel and Scheduler - An Intense Trek

[teor]

> On 31 Oct 2017, at 06:57, David Goulet <dgoulet at ev0ke.net> wrote:
> 
> * I believe now that we should seriously discuss the relevance of channels.
>  Originally, the idea was good that is providing an abstraction layer for the
>  relay to relay handshake and send/process cells related to the protocol. But,
>  as of now, they are half doing it.
> 
>  There is an important cost in code and maintanance of something that is not
>  properly implemented/finished (channel abstraction) and also something that
>  is unused. An abstraction implemented only for one thing is not really useful
>  except maybe to offer an example for others? But we aren't providing a good
>  example right now imo...
> 
>  That being said, we can spend time fixing the channel subsystem, trying to
>  turn it in a nicer interface, fixing all the issues I've described above (and
>  I suspect there might be more) so the cell scheduler can play nicely with
>  channels. Or, we could rip them off eliminating lots of code and reducing our
>  technical debt. I would like us to think about what we want seriously because
>  that channel subsystem is _complicated_ and very few of us fully understands
>  it afaict.

It depends what the goal of the channel layer is.

Do we seriously think we will use another protocol in place of TLS?

Even if we are serious about non-TLS connections, do we want to rip out
this code now, and write something better when we know what we
actually need?

Is the channel layer the right place to hide the differences between
TLS-over-IPv4 and TLS-over-IPv6?
(I don't think it is, but it's worth thinking about how much work it
was to add IPv6 support, and using that as a guide for how much work
it would be to add address/port/keys/etc. for another protocol.)

T

-- 
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------