【发布时间】:2016-06-09 08:34:41
【问题描述】:
昨天我在 go 中玩了 RPC 并且有一个我无法理解的行为。
我编写了一个简单的 RPC 服务器,它在 VM 中运行,监听连接并为斐波那契计算提供单一方法。 本地机器上的 RPC 客户端每秒向服务器询问 fibonacci(n),其中 n 是 (currentSecond*fixedMultiplicator),因此我可以产生至少稍微不同的负载。
因此,在 for 循环中,客户端将在 60 秒内请求 60 个不同的值,然后重新开始。 RPC 拨号在此循环之外,因此连接有点持久。
当我杀死服务器时,假设 10 秒后,客户端将抛出错误,因为它无法向现在丢失的服务器发送任何内容。到目前为止,按计划工作。
现在让我想到的是:当我在 61 秒后终止服务器时,尽管服务器丢失并且无法响应请求,但客户端仍然会为所有请求打印出正确的结果。我什至关闭了服务器的虚拟机,所以服务器 IP 甚至不再在网络中。 虽然有点有趣,但这种行为可能对实际应用程序有害(取决于您正在开发的内容)。
有什么想法吗?
// ############
// # RPC SERVER
err := rpc.Register(service.Object)
// errorcheck
rpc.HandleHTTP()
l, e := net.Listen("tcp", ":1301")
// errorcheck
go http.Serve(l, nil)
// ############
// # RPC CLIENT
client, err := rpc.DialHTTP("tcp", "192.168.2.111:1301")
// errorcheck
var divCall *rpc.Call
for {
<-time.After(time.Duration(1 * time.Second)):
n := time.Now().Second() * 90000000
log.Debug("n=", n)
args := &services.FibonacciArgs{N: n}
var reply int
divCall = client.Go("Fibonacci.Calculate", args, &reply, nil)
go func() {
replyCall := <-divCall.Done
r := replyCall.Reply.(*int)
log.Debug("reply: ", r)
}()
}
回答
在 Linux 和 Windows 上运行代码后,我注意到不同的结果。 在 Linux 上,回复将始终是适当的零值(在我的情况下为 0)。另一方面,在 Windows 上,回复似乎被缓存了。
要走的路是@cnicutar 的提示。在 RPC 调用后检查错误值并相应地处理内容。永远不要盲目相信回复。
【问题讨论】:
-
我会对您调用 RPC 的客户端代码感兴趣。
-
@cnicutar 你去,剥离版本pastebin.com/7uERKWER
-
我在问题中添加了代码,它比在 pastebin 中更好:)