C客户机/JVM服务器设置中双向、经过身份验证、加密连接的推荐集成机制?

首先让我举个例子。假设您有一台运行JVM应用程序的服务器。此服务器保存N个方程式的集合,每个客户端一次:

Client #1: 2x 
Client #2: 1 + y 
Client #3: z/4

此服务器包含一个HTTP接口,以便随机访问者可以键入 https://www.acme.com/client/3 int他们的浏览器并查看最新的评估结果 z/4

棘手的是,客户机或服务器可能随时更改变量值,并立即通知另一方。

更具体地说,Client#3(一个C应用程序)最初可以告诉服务器 z=20 z=23 . 同样,服务器可以稍后通知客户机 .

注释中指出,当客户机和服务器同时更改值时,可能存在竞争条件。解决方案是让客户端和服务器都发送 活动 在其消息中执行,这需要由另一方执行。为了简单起见,让我们将操作限制为(交换的)加法,这样就可以忽略消息顺序。例如,客户端使用 z=20 :

server:z=20, client:z=20
  server sends {+3} message (so z=23 locally) & 
  client sends {-2} message (so z=18 locally) at the exact same time
server receives {-2} message at some point, adds to his local copy so z=21
client receives {+3} message at some point, adds to his local copy so z=21

最后 经双方评估,正确答案将 最后 由于我们仅限于 交换的 操作(添加3和-2)。这意味着客户端和服务器都可能在交换和处理消息所需的时间内返回错误的答案。虽然这是不可取的,但我相信这是不可避免的。

这一想法的一些可能实现包括:

• 打开加密的、始终在线的TCP套接字连接进行通信
  • :不需要额外的基础设施,客户机和服务器可以立即知道对方是否存在问题(断开连接),非常简单(加密除外),JVM和C平台都提供本机支持
  • 欺骗 :级别相当低,因此您自己编写了很多内容(协议、交付验证、故障重试逻辑),在客户端应用程序安装期间可能会遇到很多防火墙问题
• 异步消息传递(例如: ActiveMQ )
  • 赞成的意见
  • :需要附加的基础结构(消息服务器),该基础结构 决不能失败
• 作为异步集成点的数据库或文件系统
  • 与上面相同的优点/缺点,但更混乱
• RESTful Web服务
  • 赞成的意见 :简单,可能重用服务器现有的RESTAPI,SSL为您解决加密问题(可能使用RSA密钥a la GitHub进行身份验证?)
  • 欺骗 :客户端现在需要运行带有SSL的C HTTP REST服务器,客户端和服务器需要重试逻辑。 Axis2 具有Java和C版本,但您可能仅限于SOAP。

我还应该评估哪些其他技术?你对这些机制有什么真实体验?对于这个问题,你推荐哪一种?为什么?