好了,解决这个是如下的一种方法:
你有CloudServer和的LocalServer。 我建议您使用消息队列(即Azure服务总线)来解决此问题。
在您的示例中,CloudServer发出命令,但互联网在本地不可用。如果您在消息队列中发出该命令,它最终会到达您的本地服务器,并且如果收到的消息有效或无效,您可以轻松确定。同样,响应最终会在线时将其最后的状态更改发送到消息队列。
你保持要求,并作为独立的实体,意义响应的概念是很重要的,如果CloudServer已发出状态改变的请求,那么这只是一个请求,并没有什么,你可以在你面前确认有实际的回应。
安全
如果你的土地同步的基于消息的形式,你不再有我警告过最初的巨大关注。您可以加密邮件的内容,也可以使用加密连接(https),如果您使用Azure Service Bus之类的东西,那么攻击者即使通过某种奇迹可以接收任何邮件,他也不会知道它来自哪里或者是谁在订阅它。安全问题解决了。
最后一个建议:
- 两家国有变化队列
- 一个队列的状态改变请求
- 一个队列的状态变更确认。
- 你永远不要假设只是基于服务器的国有变更请求
方案的状态:
方案1 - 所有连接的 - 简单的一个
CloudServer看到最后的状态如州A。 CloudServer请求状态更改为状态B(过帐到队列) LocalServer接收消息,更改状态并将确认过帐到确认队列。 CloudServer收到确认并可以设置状态。
方案2 - 连接丢失 - 并不那么容易一个
CloudServer假设最后状态A国 的LocalServer变为B国并发布了消息,不过,由于没有连接,该消息正在等待传输 CloudServer请求状态更改为状态C,发布请求消息 LocalServer认为需要状态C并在本地进行更改pos收到新消息
在这种情况下,一旦网络回来,事情就会同步,因为您可以看到消息请求和响应现在提供发生了什么事情的历史记录。你需要做的唯一的事情就是写处理事情的逻辑,即如果该CloudServer请求被忽略基于其年龄,也许序列号等上
我希望这给你的我在想什么的想法。这里的优点是您拥有的管理系统几乎不受架构的攻击。
不想在你的游行中下雨,但能够在本地控制你的物联网枢纽是一个可怕的想法。它违背了安全专家推荐的一切。如果您可以通过本地Intranet控制设备,则可能会被黑客入侵,您必须始终假设如此。在一个封闭的系统中,这是有道理的,但是你所要求的,从互联网和内联网访问都是坏的,从安全的角度来看是不好的做法。 –
@ PedroG.Dias - 需要本地控制,因为网络是不可靠的,因此当网络断开系统时可以独立工作 –
@ PedroG.Dias - 您能否提出我可以采用的任何其他模式 –