我正在尝试为Comet提出一个实用的客户端(JavaScript)实现。 http://en.wikipedia.org/wiki/Comet_(programming))讨论了理论,但是我很难找到一个可行的实现。我知道这里也有很好的服务器端要求,但是我只对它的客户端部分感兴趣。
特别是我要回答的问题是-
我曾尝试寻找Comet框架,但我发现的每个框架(CometD,Atmosphere)等也都带有服务器端实现,并使客户端交易对用户透明。但是,我试图找出它们如何实现客户端的壮举。我有自己的服务器实现和协议。
以下是我公司解决这些问题的方式:
1)如果您可以在不立即收到错误的情况下进行连接,则必须假定已建立连接。如果您没有立即收到响应(错误或其他错误),则只需假设它可以正常工作……这会使客户端很难处理,因此,智能地使用序列ID非常重要。
2)请立即重试。通常,服务器会在客户端之前超时,然后将错误代码发回,告诉您发生了什么。只要确保在服务器端使用合理的时间(例如20秒)作为轮询时间即可。
3)您必须使用与对同一服务计算机的其他请求不同的域名,并使用jsonp。例如,如果您的网页是从example.com托管的,则通常有一个chat.example.com子域,因为大多数浏览器一次只允许3或4个打开的连接到达同一域名。由于相同的原始策略,因此必须使用Jsonp。除此之外:测试,测试,测试。
Ryan Dahl(node.js的创建者)在这里实现了一个非常简单的聊天客户端/服务器:https://github.com/ry/node_chat
祝你好运!
如果传输是一种长时间轮询,您可能不知道。当我在jQuery Socket中设计长轮询传输时,我遇到了相同的问题,因为在建立连接时,套接字对象会触发open
事件。因此,我添加了一条规则,即服务器在收到第一个长轮询请求时必须立即响应,以告知客户端服务器已接受此请求并建立了连接。供您参考,如果第一个长轮询请求未在指定的超时时间内完成,则套接字对象将触发close
事件。
我同意@Hersheezy的回答。请再试一次。
测试就是答案。传输方式的组合取决于浏览器应用程序和服务器应用程序的环境。例如,如果您将支持IE6,但不支持跨域连接和移动设备,则无需使用长轮询传输。使用WebSocket,服务器发送的事件和HTTP流传输就足够了,如果您负担不起准备WebSocket服务器的费用,那么正确的传输将是服务器发送的事件和流。
我一直在制作jQuery Socket,它是服务器的JavaScript库,并为基于浏览器的应用程序提供了套接字。也许这对您有帮助。当前,它是预Alpha版本,我正在写一个涉及服务器端处理的文档。
谢谢。