【问题标题】:How to acknowledge push webservices如何确认推送 Web 服务
【发布时间】:2016-09-14 12:49:11
【问题描述】:

我的服务器上有一个 Web 服务,它将 xml 数据推送到通过 Internet 与其通信的客户端。

  1. 在这些情况下,我们很难收到来自 客户。
  2. 具体情况,例如,一旦客户端收到数据,之前 如果通信通道出现故障,则发送确认。

    示例: 如果客户端通过 Internet 进行软件更新,服务器如何确保一切正常。

【问题讨论】:

    标签: java web-services architecture


    【解决方案1】:

    如果您想走“推送”路径,并且您绝对必须知道更新是否成功,那么您必须以您知道的方式构建您的服务和客户端。

    基本上,您需要做的是构建一个小协议,以便无论通信通道出现故障,都可以传输信息。这意味着两件事:

    • 您的服务会重新传输;
    • 您的客户可以处理重复的消息;

    例如:

    1. 服务推送消息,客户端确认 => 一切正常;

    2. 服务推送消息,连接断开,消息丢失。客户端没有确认,因为它从未收到消息 => 服务稍后会再次推送相同的消息。现在希望你能解决案例 1。

    3. 服务推送消息,客户端确认但连接失败,服务未收到确认 => 类似于 2,因此服务稍后再次推送相同的消息,现在客户端收到相同的消息消息两次。它必须忽略第二条消息,但仍需要发送确认,以便服务不会第三次、第四次、...第 n 次发送它;

    等等等等……

    这是对TCP 所做工作的高级描述,例如。 TCP 是在不可靠网络上的可靠协议。它处理丢弃的数据包、重复的数据包等。

    现在,这将是推动。一个更简单的替代方法是使用“拉”。客户端定期从服务器拉取更新。这实现起来更简单(如果下载成功,则下载成功,否则您稍后再试),但并非没有陷阱,例如:

    • 控制客户端何时开始从服务中提取数据。您不能同时让它们全部更新,否则您可能会使服务器超载。客户应先询问服务器是否可以立即更新或稍后在服务不那么繁忙时返回;
    • 您是否在后台从用户设备下载升级?可能会收取数据费用,因此最好询问用户是现在还是稍后进行更新,而不是在幕后进行;
    • 在后台更新,即使数据费用没有问题,当客户端需要该带宽用于其他用途时,仍可能会消耗带宽;

    等等等等……

    问题是这是一个很大的话题,一般的解决方案可能不适用于特定情况。但这不是一个新话题。其他人以前也遇到过这些问题。例如,考虑 Windows 更新,每台 PC 的操作系统如何自我更新。不久前,当胖客户端需要更新时,也发生了类似的事情。世界转向瘦客户端,但现在胖客户端正在卷土重来。看看这些问题是如何解决的,你会在网上找到有用的信息。

    【讨论】:

    • 完成终端设备上的软件更新的方法是否相同?听起来我们需要避免编写推送服务。如果是这种情况,我们可以寻找哪些替代方案?
    • @BValluri:我已经更新了我的答案。看看有没有帮助。
    【解决方案2】:

    假设你的网络服务是RESTful,你的服务器应该是无状态的。 client 应该确保它正确接收数据。

    您可以定义一个服务来获取数据的hash value,然后是接收数据本身的请求。客户端可以在下载后检查下载数据的哈希值是否与第一次调用收到的值对应。

    除其他外,您可以在标准 Java 中使用 MD5SHA-1SHA256,如 Oracle documentation 中所述。这将从服务器端计算数据的哈希值。

    假设您从客户端使用 Javascript,则使用相同算法(例如jsSHA)计算哈希码的可能性有很多。

    希望对你有帮助。

    【讨论】:

      【解决方案3】:

      我认为没有办法做到这一点。我相信你问的原因有以下几个原因:

      1) 如果您之所以询问是因为您发送了大量数据而您的客户拒绝接收,也许您可​​以对其进行分页。这样您就可以知道访问最后一页的时间。你甚至可以更进一步,只在最后一页上放很少的数据,这样你就可以确定最后一页被调用了。

      2) 如果您真的关心确保他们收到完整的数据。建议他们访问包含数据校验和的第二个网络服务,并建议他们进行比较。

      【讨论】:

        猜你喜欢
        • 2014-12-31
        • 1970-01-01
        • 2022-01-18
        • 2014-08-03
        • 2013-06-26
        • 1970-01-01
        • 2011-09-25
        • 2012-07-01
        • 2015-08-05
        相关资源
        最近更新 更多