This is an automated email from the ASF dual-hosted git repository.
jamesge pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-brpc.git
The following commit(s) were added to refs/heads/master by this push:
new 4653c39 docs: fix server_push.md
new c8d2475 Merge pull request #1463 from lorinlee/fix-docs
4653c39 is described below
commit 4653c3932d28aaabb2e1cc5455a4d73435ffde61
Author: LorinLee <[email protected]>
AuthorDate: Tue Jul 6 23:47:03 2021 +0800
docs: fix server_push.md
---
docs/cn/server_push.md | 2 +-
docs/en/server_push.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/cn/server_push.md b/docs/cn/server_push.md
index c759950..5df8e59 100644
--- a/docs/cn/server_push.md
+++ b/docs/cn/server_push.md
@@ -6,7 +6,7 @@ server push指的是server端发生某事件后立刻向client端发送消息，
# 远程事件
-和本地事件类似，分为两步：注册和通知。client发送一个代表**事件注册**的异步RPC至server，处理事件的代码写在对应的RPC回调中。此RPC同时也在等待通知，server收到请求后不直接回复，而是等到对应的本地事件触发时才调用done->Run()**通知**client发生了事件。可以看到server也是异步的。这个过程中如果连接断开，client端的RPC一般会很快失败，client可选择重试或结束。server端应通过Controller.NotifyOnFailed()及时获知连接断开的消息，并删除无用的done。
+和本地事件类似，分为两步：注册和通知。client发送一个代表**事件注册**的异步RPC至server，处理事件的代码写在对应的RPC回调中。此RPC同时也在等待通知，server收到请求后不直接回复，而是等到对应的本地事件触发时才调用done->Run()**通知**client发生了事件。可以看到server也是异步的。这个过程中如果连接断开，client端的RPC一般会很快失败，client可选择重试或结束。server端应通过Controller.NotifyOnCancel()及时获知连接断开的消息，并删除无用的done。
这个模式在原理上类似[long
polling](https://en.wikipedia.org/wiki/Push_technology#Long_polling)，听上去挺古老，但可能仍是最有效的推送方式。“server
push“乍看是server访问client，与常见的client访问server方向相反，挺特殊的，但server发回client的response不也和“client访问server”方向相反么？为了理解response和push的区别，我们假定“client随时可能收到server推来的消息“，并推敲其中的细节：
diff --git a/docs/en/server_push.md b/docs/en/server_push.md
index 4b00287..c00c828 100644
--- a/docs/en/server_push.md
+++ b/docs/en/server_push.md
@@ -6,7 +6,7 @@ What "server push" refers to is: server sends a message to
client after occurren
## Remote event
-Similar to local event, remote event is divided into two steps: registration
and notification. The client sends an asynchronous RPC to the server for
registration, and puts the event-handling code in the RPC callback. The RPC is
also a part of the waiting for the notification, namely the server does not
respond directly after receiving the request, instead it does not call
done->Run() (to notify the client) until the local event triggers. As we see,
the server is also asynchronous. If th [...]
+Similar to local event, remote event is divided into two steps: registration
and notification. The client sends an asynchronous RPC to the server for
registration, and puts the event-handling code in the RPC callback. The RPC is
also a part of the waiting for the notification, namely the server does not
respond directly after receiving the request, instead it does not call
done->Run() (to notify the client) until the local event triggers. As we see,
the server is also asynchronous. If th [...]
This pattern is similar to [long
polling](https://en.wikipedia.org/wiki/Push_technology#Long_polling) in some
sense, sounds old but probably still be the most effective method. At first
glance "server push" is server visiting client, opposite with ordinary client
visiting server. But do you notice that, the response sent from server back to
client is also in the opposite direction of "client visiting server"? In order
to understand differences between response and push, let's analyze the [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
