JSON 异步应用服务器？
首先让我解释一下我需要的数据流
Client connects and registers with server
Server sends initialization JSON to client
Client listens for JSON messages sent from the server
现在所有这些都可以轻松简单地手动完成，但我想利用某种服务器来处理所有连接内容，保持活动状态，死客户端等。 ？
这样做有先例吗 客户端在哪里连接并从服务器异步接收 JSON 消息？不使用手动套接字编程？
First let me explain the data flow I need
Client connects and registers with server
Server sends initialization JSON to client
Client listens for JSON messages sent from the server
Now all of this is easy and straightforward to do manually, but I would like to leverage a server of some sort to handle all of the connection stuff, keep-alive, dead clients, etc. etc.
Is there some precedent set on doing this kind of thing? Where a client connects and receives JSON messages asynchronously from a server? Without using doing manual socket programming?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一种可能的解决方案称为 Comet，它涉及客户端打开到长时间保持开放的服务器。然后，服务器可以在数据可用时立即将数据推送到客户端，而客户端几乎可以立即获取数据。最终 Comet 连接超时，并创建了另一个连接。
不确定你使用的是什么语言，但我见过几种 Java 和 Scala 语言。在 Google 中搜索 comet 框架和你的语言名称，你应该会找到一些东西。
A possible solution is known as Comet, which involves the client opening a connection to the server that stays open for a long time. Then the server can push data to the client as soon as it's available, and the client gets it almost instantly. Eventually the Comet connection times out, and another is created.
Not sure what language you're using but I've seen several of these for Java and Scala. Search for comet framework and your language name in Google, and you should find something.
在“美好的过去”，这很容易，因为在第一次连接时，服务器会获取客户端的 IP 号码，因此它可以回调。事实上，这很简单，FTP 就是这样做的，没有什么充分的理由......但现在我们几乎可以肯定客户端位于某些 NAT 后面，因此您无法“回调”。
然后您可以保持 TCP 连接打开，因为它是双向的，只需让客户端等待数据出现即可。服务器会尽可能发送它想要的任何内容......但是现在每个人都希望每个应用程序都在网络浏览器之上运行，这意味着 HTTP，它是严格由客户端发起的“请求/响应”。
所以，当前的答案是 Comet。简单地说，JavaScript 客户端发送请求，但服务器很长时间没有响应。如果连接超时，客户端会立即重新打开它，因此始终有一个打开的管道等待服务器的响应。该响应将包含服务器想要发送给客户端的任何消息，并且仅在相关时才发送。客户端收到后立即发送新的查询以保持通道打开。
In 'good old times' that would be easy, since at the first connection the server gets the IP number of the client, so it could call back. So easy, in fact, that it was how FTP does it for no good reason.... But now we can be almost certain that the client is behind some NAT, so you can't 'call back'.
Then you can just keep the TCP connection open, since it's bidirectional, just make the client wait for data to appear. The server would send whatever it wants whenever it can.... But now everybody wants every application to run on top of a web browser, and that means HTTP, which is a strictly 'request/response' initiated by the client.
So, the current answer is Comet. Simply put, a JavaScript client sends a request, but the server doesn't answer for a looooong time. if the connection times out, the client immediately reopens it, so there's always one open pipe waiting for the server's response. That response will contain whatever message the server want's to send to the client, and only when it's pertinent. The client receives it, and immediately sends a new query to keep the channel open.
问题在于 HTTP 是一种请求响应协议。除非客户端提交请求，否则服务器无法发送任何数据。
尝试通过发送请求然后不断地发回相同的原始请求的响应来规避这一点是有缺陷的，因为该行为不符合 HTTP 并且它不能与所有类型的中介（代理、路由器等）和浏览器行为（Ajax 完成）。它也不能很好地扩展，在服务器上保持套接字打开需要大量资源，并且套接字是非常宝贵的资源（通常只有几千个可用）。
尝试通过反转流程（即服务器在有要推送的内容时连接到客户端）来规避此问题甚至更加有缺陷，因为随之而来的安全/身份验证问题（响应很容易被劫持、否认或欺骗）也因为很多时候客户端无法访问（位于代理或 NAT 设备后面）。
AFAIK 大多数 RIA 客户端只是根据计时器进行轮询。并不理想，但这就是 HTTP 的工作原理。
The problem is that HTTP is a request response protocol. The server cannot send any data unless a requests is submitted by the client.
Trying to circumvent this by macking a request and then continously send back responses on the same, original, requests is flawed as the behavior does not conform with HTTP and it does not play well with all sort of intermediaries (proxies, routers etc) and with the browser behavior (Ajax completion). It also doesn't scale well, keeping a socket open on the server is very resource intensive and the sockets are very precious resources (ordinarly only few thousand available).
Trying to circumvent this by reversing the flow (ie. server connects to the client when it has somehting to push) is even more flawed because of the security/authentication problems that come with this (the response can easily be hijacked, repudiated or spoofed) and also because often times the client is unreachable (lies behind proxies or NAT devices).
AFAIK most RIA clients just poll on timer. Not ideal, but this how HTTP works.
GWT 为此类内容提供了一个框架。与 Comet 集成（至少对于 Jetty 而言）。如果您不介意至少用 Java 编写 JavaScript 的一部分，那么这可能是更简单的方法。
GWT provides a framework for this kind of stuff & has integration with Comet (at least for Jetty). If you don't mind writing at least part of your JavaScript in Java, it might be the easier approach.