客户端能否维护一个长连接，提供一个推送通知回调，以实现推送功能？

[airx]

对于客户端网络库业务使用来说，其实就两种形式：一种主动请求（又分同步和异步），一种被动推送。 rest_rpc解决了主动请求的问题，调用确实挺方便！ 但我觉着rest_rpc不应该局限在rpc这个技术名词的意思，还应该把客户端推送也集成并且优雅的解决好，这样就全统一了，才是真正的解决问题。 服务端可选择的框架方案太多了，就是分布式，mq都有很好的方案。而客户端网络库都没人关注和做的好的，这篇文章我觉得很有道理：https://blog.51cto.com/yaocoder/1541271 要么只是封装下socket提供几个回调，当然rest_rpc算是考虑到实际调用方便，主动请求解决的挺好，但缺长连接维持和推送通知。客户端库当然还需要考虑依赖尽可能少，库尽可能小，性能第二，易用性傻瓜性第一。

[qicosmos]

客户端推送是指设置一个回调，然后等服务端推送过来的消息吗？

[qicosmos]

另外，客户端和服务端几乎没有任何依赖，不依赖boost，仅仅依赖一个比较小的asio库而已。

[airx]

客户端推送是指设置一个回调，然后等服务端推送过来的消息吗？

是的，这样主动请求和被动推送才解决完整了。不然服务器没法主动给客户端说话呀~~

[qicosmos]

目前主流的RPC框架都没有这种功能吧。

[airx]

目前主流的RPC框架都没有这种功能吧。

RPC从字面技术意思肯定不包含推送，主要看你怎么看待这个问题，是技术字面角度，还是从使用体验角度考虑。 因为我看你请求封装的挺好，考虑到方便了，所以建议你应该更进一步，着眼点在解决客户端网络库的问题，而不是再解决一个rpc方便的问题，rpc有http，okhttp这些都挺方便的，也有gprc等等，这块提升的边际效益比较低。

[qicosmos]

加这个推送功能不难，我要考虑的周全一点，看看是不是有必要加。

[airx]

加这个推送功能不难，我要考虑的周全一点，看看是不是有必要加。

非常多场景都有必要的，只要是双向的都有必要，现在非双向的场景很少了，不然http弄个websocket干嘛呢？ 服务端，http框架一大堆，tcp c++, java netty框架一大堆，基本都能解决问题；但为什么客户端就没有一个优雅精简的方案呢，一个长连接维持，既可以用来接收推送，也可以用来主动请求，API真正的友好易用呢。有些tcp socket倒是技术层面封装的还可以，不过离业务使用还有段距离，真正拿去用，还得封装一道主动请求的方法，否则到处回调过来回调过去，变量传递满天飞，这些封装的人就不考虑了，但问题还是存在啊。

[qicosmos]

已经支持了服务端主动推送。 服务端主动推送的例子在这里：https://github.com/qicosmos/rest_rpc/blob/master/examples/client/main.cpp#L366 https://github.com/qicosmos/rest_rpc/blob/master/examples/server/main.cpp#L88 服务端每隔一秒会推送一次消息，客户端把收到的通知消息打印出来。

[airx]

已经支持了服务端主动推送。 服务端主动推送的例子在这里：https://github.com/qicosmos/rest_rpc/blob/master/examples/client/main.cpp#L366 https://github.com/qicosmos/rest_rpc/blob/master/examples/server/main.cpp#L88 服务端每隔一秒会推送一次消息，客户端把收到的通知消息打印出来。

厉害！我先看看。

[fxconfig]

厉害的，我的水平还无法看懂源码，只能拿来主义了。

有个问题请教： boost asio connection 15s 无数据传输，会自动断开，这个哪里可以设置么？

[qicosmos]

这个超时时间是可以设置的，rpc_server构造函数的第三个参数就是超时时间，默认参数为15，可以根据自己的需要设置，如果不需要超时的话就设置为0

[fxconfig]

这个超时时间是可以设置的，rpc_server构造函数的第三个参数就是超时时间，默认参数为15，可以根据自己的需要设置，如果不需要超时的话就设置为0

谢大佬指点，， 关于客户端接收推送的，既然已经有 err_call_back 了，为何不干脆再加个 OnConnect， OnMessage 之类的 callback 呢，这样使用起来就更傻更方便了。。。 感觉我是用 websocket 用多了，哈哈

[fxconfig]

我加了个 std::function<void()> conncb 在 async_connect 里面 std::cout<<"connected ok"<<std::endl; 最后面添加了个 回调 目测运行完美，现在关于推送的 使用更傻瓜了，

// set_error_callback 里面设置异步重连， // set_connect_callback 里面 wait_for_notification

[airx]

我加了个 std::function<void()> conncb 在 async_connect 里面 std::cout<<"connected ok"<<std::endl; 最后面添加了个 回调 目测运行完美，现在关于推送的 使用更傻瓜了，

// set_error_callback 里面设置异步重连， // set_connect_callback 里面 wait_for_notification

你是应用在什么场景和系统呢

[hzqst]

我记得原来老版本的rest_rpc是直接有server的pub方法的 为啥新版推送搞这么复杂了还要自己去处理订阅

建议把pub加回去作为server的公开接口

[RubikZero]

在这里顺便问一下，客户端没有取消订阅的接口吗？还有服务端publish by token以后，token就加到tokenlist里面了，好像也没有删除token的接口

[someview]

哎呦，这个问题，还在，5年以后的今天，在用go开发一个rpc框架的时候，有了同样的需求，遇到同样的问题.