Q: use case for caching proxy

[ivanjaros]

I will be making a caching proxy soon where user sends a HTTP/S request and i either serve the locally cached content or fetch it from origin, cache it and serve it. So I am wondering if this would be a good library to use instead of built-in net package to yield some more performance?

Secondly, HTTPS/TLS is a must and I saw that you do not use tidwall's evio, at least not any more, which does not support TLS. But also this looks like #16 TLS might still not be supported here, so what is the situation?

[xscode-auto-reply]

Thanks for opening a new issue. The team has been notified and will review it as soon as possible.
For urgent issues and priority support, visit https://xscode.com/panjf2000/gnet

[panjf2000]

I will be making a caching proxy soon where user sends a HTTP/S request and i either serve the locally cached content or fetch it from origin, cache it and serve it. So I am wondering if this would be a good library to use instead of built-in net package to yield some more performance?

I think gnet would be a good choice for developers to implement a proxy server.

Secondly, HTTPS/TLS is a must and I saw that you do not use tidwall's evio, at least not any more, which does not support TLS. But also this looks like #16 TLS might still not be supported here, so what is the situation?

Supporting TLS is a gigantic feature for gnet, which takes lots of effort and I currently don't have time for this, also I had been wondering if making a full implementation of TLS in gnet is a good idea, maybe I ought to design it as a plug-in architecture where developers are able to implement their plugins for their custom requirements.

[ivanjaros]

ok, thanks for the info. i know tidwall said that he does not support tls because core tls library depends on net.Conn, iirc. if the tls "plugin" would be a simple ReadWriter like compressors and marshallers can be, that would be the most universal solution, i think. i will probably look into it once i begin the work, though it is highly possible that due to this i will have to take the go std route for now and look at gnet for v2 later on. since getting the working solution out as fast as possible will be priority.

[ivanjaros]

actually, i have a better idea. it might sound a bit too crazy but i think it would make more sense to just fork Go and simply replace the std net package's internals with gnet. That way there would be no compatibility issue and no need to write tls/http/http2/http3/quic plugins. and maybe in time it could be merged into Go if it proves to be "worthy".

[panjf2000]

actually, i have a better idea. it might sound a bit too crazy but i think it would make more sense to just fork Go and simply replace the std net package's internals with gnet. That way there would be no compatibility issue and no need to write tls/http/http2/http3/quic plugins. and maybe in time it could be merged into Go if it proves to be "worthy".

I don't think that will work, gnet has a completely different interface design than go and a lot less functionality, they are totally incompatible, so there is no way that gnet can be a substitute for go std net.

[ivanjaros]

ok, you know best. thanks for the info.