You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
------------------ 原始邮件 ------------------
发件人: 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: ***@***.***>
Activity
Barenboim commentedon Dec 25, 2025
就是希望请求是一条TLVMessage，回复是持续的TLVMessage流对吧？然后每收到一个TLVMessage会callback一下？
Barenboim commentedon Dec 25, 2025
这个client好做，但用workflow实现这样的server不是很自然。
povs2012 commentedon Dec 25, 2025
是的，就是sse的自定义协议版
povs2012 commentedon Dec 25, 2025
服务端没问题，之前参考过一些issue，已经实现了类似的功能了
povs2012 commentedon Dec 25, 2025
或者说如果客户端和服务端都是workflow，客户端持续的定时使用tlv协议请求服务端（几十毫秒一次），相比订阅一次，持续接收TLVMessage流，性能和对服务端的压力会差别很大吗
Barenboim commentedon Dec 25, 2025
区别不会太大吧，一条TLV请求也不消耗多少资源。如果对实时性要求不高，定期请求一下不会多占多少资源。
workflow最推荐的用法是actor模式，client端也开一个server，实际server端产生消息时，向client端的server发生request。这个方式用workflow实现非常非常自然且高效。
client订阅，server推送的方式也是可以的，自己实现的话就模仿http chunked client的方式，派生几个类。
povs2012 commentedon Dec 25, 2025
看到一个WFRedisServer，这个是不是可以实现redis server，能不能用这个实现个redis的pub sub协议，然后用WFRedisSubscriber来订阅，这样是不是比自己实现TLV协议的chunked client要简单一点
povs2012 commentedon Dec 25, 2025
actor模式的话，如果客户端停掉了，服务端怎么知道呢
povs2012 commentedon Dec 25, 2025
感觉最好能官方支持持续订阅的TLVMessage，这样方便应用自己定制协议
Barenboim commentedon Dec 25, 2025
Barenboim commentedon Dec 25, 2025
request时失败，就知道client挂了。在后端服务里，双向调用是最简洁的模式。但如果有NAT或防火墙就不行了。