RPC 和共享持久数据空间
我有一个家庭作业问题，询问我们是否使用共享持久数据空间时有关 RPC 系统的问题。拥有共享的持久数据空间是否会改变构建 RPC 系统的方式？
例如，如果客户端或服务器不可用，则可以使用不同的选项来处理该问题。如果您还有共享的持久数据空间，这是否意味着您应该在客户端或服务器不可用时使用它来存储响应和请求？这样会不会很慢……这不合理吗？我应该忽略问题的共享持久数据空间部分吗？
I have a homework question that asks about an RPC system if we're using a shared persistent data space. Would having a shared persistent data space even change anything about the way you build an RPC system?
For example, if the client or server isn't available, there are different options to deal with that. If you also have a shared persistent data space, would this mean you should use it to store responses and requests if the client or server is unavailable? Would this be slow... is it unreasonable? Should I just ignore the shared persistent data space part of the question?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通过 rpc 调用写入共享数据时，请注意竞争条件和响应时间。
“在传统的 RPC 模型中，客户端在远程过程调用中被阻塞，直到调用返回。”请参阅 http://msdn。 microsoft.com/en-us/library/windows/desktop/aa373550%28v=vs.85%29.aspx。
使用同步 rpc 调用，您会遇到服务器响应性问题，但不会出现竞争条件问题，使用异步 rpc 调用则反之亦然。
Be aware of race conditions and response times when writing shared data via rpc calls.
"In the traditional RPC model, a client is blocked in a remote procedure call until the call returns." see http://msdn.microsoft.com/en-us/library/windows/desktop/aa373550%28v=vs.85%29.aspx.
Using synchronious rpc calls, you have a problem with the server responsiveness but not with race conditions, using asynchronious rpc calls it's vice versa.