构建服务器时，有时会执行从客户端到服务器的异步任务（在异步时间内响应客户端）， 或者服务器需要向客户端发送消息
现在如果客户端一直在监听（意味着轮询），则需要大量资源才有问题
这里我假设操作系统介入并承担轮询适当端口的角色，并让应用程序知道使用适当的事件（应用程序使用OS API订阅）
我的假设是对的吗？如何使用操作系统的API订阅端口？ （为了争论，让我们说安卓）
从服务器到客户端的消息如何正常工作？ 以及服务器如何随时了解客户端的IP？
我在这个主题上看过很多问题，但是无法弄清楚大局是什么
修改：
我在Android中使用GCM，但是已经看到其他应用程序没有使用它并仍然设法做得对，这也是一个更普遍的问题，关于java VS中的正确方法是什么。它使用的任何操作系统（ubnutu，windows，android等）
答案 0 :(得分：0)
完全正确 - 轮询通常是浪费资源。直到最近，许多应用程序要么保持套接字打开并每隔几分钟轮询以保持活动状态，要么定期对服务器进行HTTP调用。
如今，大多数应用都使用Google Cloud Messaging来推送数据而不是不断轮询。正如您所猜测的那样，这是通过与Google的服务器保持持久连接来实现的。这样做的好处是它对电池寿命非常有效，并且所有应用程序都可以使用这一个资源发送推送通知，而不是每个应用程序必须轮询不同的服务器或创建自己的持久连接。
这个想法是您从服务器向GCM发送请求（这可以响应用户活动等），将其发送到所有客户端的设备。您可以发送带有小负载（最多4kb）的消息或“发送到同步”消息，该消息告诉应用程序联系服务器（例如，在用户更改后从服务器同步新数据）。
这里我假设操作系统介入并承担轮询适当端口的角色，并让应用程序知道使用适当的事件（应用程序使用OS API订阅）
GCM将消息推送到客户端，因此您没有像在简单的轮询系统中看到的那样进行活动等待。
从服务器到客户端的消息如何正常工作？以及服务器如何随时了解客户端的IP？
服务器无需知道客户端IP，因为任何在线Android设备通常都会与GCM建立连接。定位特定用户是通过User Notifications完成的。
（哦，我意识到你的问题比Android更常见，我有更多的经验，但iOS有一个类似的系统。我见过的一些开发人员喜欢使用Parse管理推送通知。）