Feature request. Websocket compression about nbio

[lesismal]

I do not want to support permessage-deflate before, because it's easy to be implemented by the application layer and not all ws clients support it and the server could decide to not compress.
But since you have proposed it, we make it on the road map.

[lesismal]

have implemented decompress for the server in a new branch:
9e4b46f

examples: server, client

I'll go on to implement compress after some rest

[acgreek]

I ran auto_bahn against it. There are a few failures to work through but good start.

…

On Sun, Jul 4, 2021, 8:21 AM lesismal ***@***.***> wrote: have implemented decompress for the server in a new branch: 9e4b46f <9e4b46f> examples: server <https://github.com/lesismal/nbio/blob/compress/examples/websocket/server/server.go#L24>, client <https://github.com/lesismal/nbio/blob/compress/examples/websocket/client/client.go#L24> I'll go on after some rest — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJSWEUBHGS5GIE4IAUTALTTWBN7HANCNFSM47YF2A6Q> .

[lesismal]

I ran auto_bahn against it. There are a few failures to work through but good start.

Done with all the compression, and the newest Autobahn WebSocket Testsuite report:
https://lesismal.github.io/nbio/websocket

It cost 2 hours on my laptop, such a long run, my laptop has a fever 😂 ......

Please try it yourself and enjoy it 😄 .

[acgreek]

Thanks. I can't today but will check it out over the next few days. Next thing we need to do is a performance comparison between the most popular golang websocket apis. I can get this done over the next few days. We also need to track and increase code coverage.

[lesismal]

Next thing we need to do is a performance comparison between the most popular golang websocket apis

we may focus on some points:

1. the performance and memory reduction in high concurrency service
2. not limited to a simple echo service, hard to explain, it's kind of about the cross-goroutine memory management in nbio, compared to std who use the same buffer reuse in the same goroutine for each connection, and the different frameworks' scheduling cost. for a low concurrency service, nbio runs no better than std, even worse than std.