ws-tool

ws-tool copied to clipboard

Ntex/axum integration

3

Is it possible to integrate your crate with frameworks such as ntex or axum? It would be great to see examples

rocinant3

current per message deflate impl backend use libz or libz-ng, and it's performance isn't good enough for real time message transport, maybe it need some tuning. And there is another...

PrivateRookie

Help wanted: Create Node.js Bindings

1

Hi there, I am trying to create Node.js bindings for this library. Websockets are in high demand in Node.js & Javascript environments, so an npm package for this package would...

mkadirtan

PrivateRookie

the following socket types in zmq is very useful - pub/sub - push/pull - req/resp should try to port them from zmq, but with easier monitor api

PrivateRookie

websocket over htth2

3

PrivateRookie

Easier api when server handling tls & add blocking tls server handling

2

PrivateRookie

impl Clone for Sender

3

一般通道的接收都是先反序列化，再根据反序列化的结果再match分发处理，如果Clone了，可能对哪个接收者Receiver会收到消息不一定有直观的预期，所以接收者的对于Clone的需求不太大。 但发送者Sender（代指ws-tool内ws相关的所有发送者）大多数时候都有分享到不同线程的需求。比如说推送通知，就有可能来自于不同系统的推送，也有可能来自其他客户端的推送。如果不能把Sender分享到不同线程的话，实现此类功能就很麻烦。 一般而言会考虑两种方式，一种是通道，一种是加锁： 标准库通道、crossbeam-channel、tokio通道、async-channel，都可以实现Sender的跨线程克隆； 标准库锁、parking_lot、tokio异步锁、fast-async-mutex也都可以克隆； 根据测试，同环境里原则上加锁最快（rustcc论坛里有发过测试结果），所以我试了ws-tool（主要是Frame相关的类型），同步环境下用parking_lot::mutex加锁（我是在ubuntu下测试的，window下可能标准库mutex更快），异步环境下用fast-async-mutex加锁，然后放进一个可分享的map里进行全局调度，可以成功运行。 Sender加锁后在执行send固然能够实现多线程分享，但却不是最佳实践，锁的粒度理论上还能够更细，最好细到write/write_all/write_vectored这个级别，但我看了FrameWriteState::send的源码，发现里面部分的write行为是拆分开来的，在单线程或独占的状态下直接write没问题，但不确定锁的粒度进一步细化后，导致write乱序是否会影响功能实现。 建议： 一、如有必要的话，应把同一个send/async_send里的写行为进行合并； 二、增加一个ShardedSender的类型，内建类型是`Arc`，普通Sender需要实现Clone/Into变成ShardedSender，ShardedSender克隆还是本类型，但Arc的引用计数为1时，可以into成Sender（不怎么用得到但也算保持类型可逆性）。

lithbitren