如何构建一个需要与客户端进行双向通信的 django 应用程序答案

【问题标题】：How to architect a django app that requires bidirectional communication with the client如何构建一个需要与客户端进行双向通信的 django 应用程序
【发布时间】：2013-10-22 08:03:26
【问题描述】：

我有一个 webapp (django/node.js) 和一个客户端（不是浏览器，一个使用 requests 包的控制台应用程序），它们通过互联网（完全独立的网络）连接。预计客户端不会一直处于活动状态，而是会通过不可靠的 Internet 连接连接到 Internet。

我需要一些关于构建应用程序的建议，系统应该执行以下操作：

我需要能够将数据从服务器推送到客户端，当这种情况发生时，客户端将根据接收到的数据更新其本地 MSSQL 数据库，并向服务器确认数据更新成功（即双向通信）
服务器还可以询问客户端是否还活着....如果它还活着，客户端会响应，这被用作监控客户端状态的心跳。如果它还活着，服务器可以要求客户端启动一个漫长的过程（例如，开始备份其数据库并上传）。如果客户端没有响应，则存在某种超时，并且会发送一封电子邮件，说明服务器无法访问客户端。

这里有一些限制：

我已尝试将服务器端事件推送到客户端，然后客户端将其响应发布到 url。第一个问题是，客户端会消耗处理器上的周期，只是等待一个事件（即使我尝试使用 chrome 或 firefox 之类的浏览器，也会出现同样的问题 - 在等待时，处理器使用率上升了 8% 左右或者）。另一个问题是从服务器启动 ARE_YOU_ALIVE 的代码将停止，客户端将发布到不同的位置/视图，我必须获取该信息。似乎一场灾难即将发生。所以放弃了这种方法。
我真的不想使用龙卷风，扭曲等。现在真的不想在这方面投入时间。我的大部分应用都运行良好，不想为这个小功能重新发明轮子。
我确信正确的方法涉及 node.js 和 socketio，并希望使用它们。同时，我不是 JS 忍者，我想让 django 做繁重的工作。我喜欢this article solves the problem 的方式，并且拥有最少的 node.js，并让 django 处理逻辑。但是，问题似乎是node_api(request)（客户端将向其发布响应的位置）不知道客户端正在响应哪个 ARE_YOU_ALIVE 请求。我真的需要一些简单的东西，比如：
```
client_alive = Get_client_status(client)
if client_alive:
  send_command_to_client(command['INIT_BACKUP']
  response = Get_client_status(client)

  block until response.state == "BACKUP_COMPLETE":
       response = Get_client_status(client)
  # need to handle timeout if backup is stuck and will not complete for some reason

else:  timeout?
   send_email_client_dead()
```
人们通常如何处理这种情况是否有已知的模式？我觉得我正在做一些新的事情，但没有遇到任何关于如何完成的文档。如有任何指导，我将不胜感激。

【问题讨论】：

我认为人们使用 TCP 套接字进行双向通信。为什么不这样做呢？
是的，我打算在 HTTP 上使用 TCP 套接字（也称为 websockets）
“客户活着”是什么意思？
客户端存活意味着客户端程序正在运行并且没有死。

标签： python django node.js architecture

【解决方案1】：

如果坚持使用 HTTP，我建议在这里考虑几个选项。

直接使用WebSocket进行客户端和服务器通信。如果使用 Java，客户端和服务器端需要使用 J2EE 7 来支持这一点。这样，服务器可以直接向客户端发送消息。客户端可以使用类似 onMessage() 的方法以事件通知的方式获取消息。
使用普通的 HTTP，但在 HTTP 之上创建一个协议。例如。客户端将通过每 5 或 10 秒发布到带有时间戳的 URL 来向服务器发送心跳信号。服务器端有一个逻辑来检查是否有一定的心跳信号丢失，比如最近连续10次心跳低于50%的右心跳，这意味着客户端已经死了。或者你想在这里设置的任何规则。
在客户端创建像 Jetty 这样的轻量级服务器，以在 HTTP 上创建“实时或非实时”Restful 服务。

【讨论】：