TLS support ? about evio HOT 13 OPEN

Thanks and respect for your job of evio!

Here is one of my repo llib which includes a fork of crypto/tls that implemented non-blocking tls, and has been used in my another async-io lib nbio(support tls/http1.x/websocket).

Here is some example using llib's non-blocking tls, it may help other async-io frameworks to support non-blocking tls:
tls-server
tls-client

For more details and examples:
https://github.com/lesismal/nbio/blob/master/nbhttp/server.go#L375
https://github.com/lesismal/nbio/tree/master/examples

Some benchmark compared with std:
lesismal/nbio#62 (comment)

I don’t know if mentioning my own project in your project will offend you. I just want to communicate with you more widely. If you think this is inappropriate, I will delete the message here.

Thanks and respect again!

from evio.

I don't currently have plans for built-in TLS support.

from evio.

@tidwall would you accept a PR for to support it?

from evio.

@dspasibenko Perhaps. It depends on the implementation. As long as it's clean, doesn't use goroutines, avoids context-switching, and doesn't slow down the existing non-tls library.

from evio.

@tidwall just curious..why did you specifically mentioned "no goroutines"? bad for performance ?

from evio.

@vishal-uttamchandani i would prefer to avoid the go scheduler as much as possible, but I suppose if the implementation is well crafted then maybe it’s fine. I’m open to ideas.

from evio.

@tidwall I played with the code today and could only to make it works for tcp-net (stdserver), which probably doesn't make sense. The commit is here: dspasibenko@021bf85

The problem with crypto/tls implementation is it uses tls.Conn which wraps *net.TCPConn or any other implementation of net.Conn and relies on the underlying a net.Conn instance. Eventually the tls.Conn works like a filter on top of the TCP traffic, so seems like the existing schema with firing events to a user's functions like events.Data doesn't work straight-forward cause the TCP traffic should be passed through tls.Conn. Another problem with the tls.Conn implementation it is supposed to be used synchronously. It will not work if we just pass whatever we read from the wire to the tls.Conn immediately trying to read TLS-transcoded data from it. Due to handshake and the implementation the read from tls.Conn could be blocked due to insufficient data. It will not return n==0 from the Read(), but will block it. So, to support TLS we either need to have the net.Conn instance and run the tls.Conn events in a separate of the loops go-routine taking into account its synchronous implementation or modify the tls code for supporting asynchronous calls, what doesn't seem reasonable. Do you have any ideas?

from evio.

@dspasibenko

Early on in my development of evio I did add the ability to use TLS. I didn't add tls directly into evio, but rather added a translation layer that could be used to for tls, compression, or protocol translations.

https://github.com/tidwall/evio/tree/v0.1.0#data-translations

My solution was to basically wrap an evio context inside of a net.Conn-like interface using (now defuct) evio.NopConn and evio.Translate functions. It was very flexible and it worked but underperformed compared to using the stdlib net package.

The problem I ran into was basically what you mentioned, that in order to use anything cool in the standard Go packages like crypto/tls or compress/gzip, you'll need to conform to a net.Conn or io.ReadWriter. Which in turn locks you into the Go synchronous model. I had to use goroutines and channel-like messaging to move data between the evio loop and the translator. This is where the performance fell off the cliff. Also don't forget that goroutines use like 4KB. So my fast and lightweight networking library was now slow and bloated.

Right now the only idea that I have is to reimplement the crypto/tls and compress/gzip to use a block reads/writes like the C OpenSSL and zlib libraries. Where you feed chunks of data at a time.

Or (cringe) use cgo.

from evio.

@tidwall yep, you are right. It seems to have an asynchronous implementation for both of the packages is what will fit into evio design organically. I will take a look closer to the TLS implementation and will try to work it around if it is possible. Thanks.

from evio.

Any progress here?

from evio.

I don't have any plans for adding TLS to evio.
I recommend looking into using stunnel as a front-end.

from evio.

Probably @dspasibenko has something to add?

from evio.

@UladzimirTrehubenka yep couple cents. The problem is in standard Go TLS implementation. It doesn't have an event-based idea mechanism and actually it can block calls like Reader.Read() during handshake, what is actually not accurate by the io.Reader contract. I would say to support TLS in evio, the whole TLS module should be implemented, what is not trivial. I would probably consider to make it, but not now, some other time. Another option could be to adopt any other TLS implementation, but not from the standard Go one.

from evio.