能否给TLVMessage类型的请求实现类似HttpChunkClient或者WFRedisSubscribeTask机制，实现一次订阅后可以持续收到后续推送结果

[povs2012]

[Barenboim]

就是希望请求是一条TLVMessage，回复是持续的TLVMessage流对吧？然后每收到一个TLVMessage会callback一下？

[Barenboim]

这个client好做，但用workflow实现这样的server不是很自然。

[povs2012]

是的，就是sse的自定义协议版

[povs2012]

这个client好做，但用workflow实现这样的server不是很自然。

服务端没问题，之前参考过一些issue，已经实现了类似的功能了

[povs2012]

或者说如果客户端和服务端都是workflow，客户端持续的定时使用tlv协议请求服务端（几十毫秒一次），相比订阅一次，持续接收TLVMessage流，性能和对服务端的压力会差别很大吗

[Barenboim]

区别不会太大吧，一条TLV请求也不消耗多少资源。如果对实时性要求不高，定期请求一下不会多占多少资源。

workflow最推荐的用法是actor模式，client端也开一个server，实际server端产生消息时，向client端的server发生request。这个方式用workflow实现非常非常自然且高效。

client订阅，server推送的方式也是可以的，自己实现的话就模仿http chunked client的方式，派生几个类。

[povs2012]

看到一个WFRedisServer，这个是不是可以实现redis server，能不能用这个实现个redis的pub sub协议，然后用WFRedisSubscriber来订阅，这样是不是比自己实现TLV协议的chunked client要简单一点

[povs2012]

actor模式的话，如果客户端停掉了，服务端怎么知道呢

[povs2012]

感觉最好能官方支持持续订阅的TLVMessage，这样方便应用自己定制协议

[Barenboim]

这个redis server可以用的，不支持pipeline。用来实现pub server也勉强可以，但只能在请求时就订阅好，中间不能增加或减少channel。 WFRedisServer这个我们一直用来做分布式数据库的代理服务器的，非常好用。用户认证信息简单放在连接上下文就可以。

…

------------------ 原始邮件 ------------------ 发件人: povs2012 ***@***.***> 发送时间: 2025年12月25日 19:15 收件人: sogou/workflow ***@***.***> 抄送: xiehan ***@***.***>, Comment ***@***.***> 主题: Re: [sogou/workflow] 能否给TLVMessage类型的请求实现类似HttpChunkClient或者WFRedisSubscribeTask机制，实现一次订阅后可以持续收到后续推送结果 (Issue #1802) povs2012 left a comment (sogou/workflow#1802) 看到一个WFRedisServer，这个是不是可以实现redis server，能不能用这个实现个redis的pub sub协议，然后用WFRedisSubscriber来订阅，这样是不是比自己实现TLV协议的chunked client要简单一点 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[Barenboim]

actor模式的话，如果客户端停掉了，服务端怎么知道呢

request时失败，就知道client挂了。在后端服务里，双向调用是最简洁的模式。但如果有NAT或防火墙就不行了。