在客户端 - 服务器系统中,它是否被认为是服务器方法的“良好架构”以“询问客户端”以获取更多信息?如果是这样,设计这种情景的最佳方法是什么?这有“模式”吗?
例如,假设最终用户在客户端UI中选择了一组他们想要删除的记录,然后客户端使用记录集作为参数对服务器进行“删除记录”调用。然后,服务器以某种方式找到那些“特殊”的记录的子集,因此需要由用户确认。是否适合服务器以某种方式“回调”客户端到名为“确认记录”的方法,同时仍然继续从客户端到服务器的原始呼叫?
那么在服务器和客户端之间需要长时间“对话”的更复杂的服务器调用呢?
答案 0 :(得分:1)
某些回复说“记录x,y和z未被删除,再次尝试将I_RELLY_WANT_TO
设置为删除它们”对我来说似乎是一个合理的解决方案。
一般模式;不要问,做东西并报告,让客户决定下一步该做什么。这可以在作为对话形式的持久连接的上下文中完成。
不是我的田地所以...添加64mg NaCl
答案 1 :(得分:1)
客户端正在发送要删除的文件列表,对吧?只需让服务器回复一个成功状态列表,指出哪个文件被删除,哪个文件没有删除,以及可能为什么没有删除(不存在,没有权限等)。
如果常见的情况是所有文件都被成功删除,可以从响应开始,状态字段指示是否所有文件都被删除,或者客户端是否需要实际评估状态代码以查看操作是如何消失的。
通过此响应,客户端应该能够更新其对服务器状态的视图,至少对于已选择删除的文件(即,从UI中删除那些已成功删除的文件,还有那些不再存在的;也可能表示服务器由于缺少权限而无法删除的那些文件。)
答案 2 :(得分:0)
这样的回调会颠倒客户端和服务器的角色。在许多这些类型的体系结构中,客户端无法监听请求。如果是这样,你就开始关注P2P类型的系统了。也许这样的事情可能有用。
client code:
special_records = server.deleteRecords(records)
server.deleteSpecialRecords(special_records)
server code:
def deleteRecords(records):
special_records = detectSpecialRecords(records)
reply(special_records)
actuallyDeleteRecords(records - special_records)
因此,对deleteRecords的第一次调用将返回需要显式删除的这些特殊记录的列表。希望这会有所帮助。
答案 3 :(得分:0)
我认为那种安排完全没问题。没有什么可以阻止服务器向客户端回复查询以获取更多信息以及客户端提供它。只要套接字连接打开,您就可以自由地来回发送消息。
我已经看到了一个安排,客户端向服务器发送了一条消息,之后没有做什么比stdin / out上面的小层和本地机器上的文件系统更多,因为服务器控制它。它工作得很好而且非常快。