Tag: 长轮询

“xhr-polling”configuration在socket.io中做什么？

我有一个node.js服务器与socket.io： var io = require('socket.io').listen(app); // assuming io is the Socket.IO server object io.configure(function () { io.set("transports", ["xhr-polling"]); io.set("polling duration", 10); }); io.sockets.on('connection', function(socket){ console.log('connected: %s', socket.id); … } 使用xhr-polling和10秒的轮询时间，这是否意味着每10秒会调用一次新的连接？ 如果是这样，如果用户断开连接，如何跟踪用户？ 我在heroku上运行node.js。

长期投票的严重缺点？

对于交互式Web应用程序，像Websockets这样的东西越来越受欢迎。 然而，由于客户端和代理世界并不总是完全兼容，所以通常会使用像“Socket.IO”这样的复杂框架，对于任何可能会禁用其他框架的情况隐藏几种不同的机制。 我只是想知道一个正确实现的长轮询的缺点是什么，因为今天的服务器比如node.js很容易实现，并依赖于很好的支持旧的http技术（尽pipe长时间的轮询行为本身可能会打破它）。 从高层次来看，长时间轮询（尽pipe有一些额外的开销，适用于中等stream量的应用程序）类似于WebSockets所做的真正的推送行为，因为服务器每当他喜欢（尽pipe有一些超时/心跳机制）实际发送它的答案。 所以我们有更多的开销，因为我猜测TCP / IP更多的确认，但没有像频繁轮询那样的持续stream量。 而使用事件驱动的服务器，我们将不会有线程开销来阻止连接。 那么是否还有其他困难的缺点，迫使像聊天这样的中等stream量应用使用WebSockets而不是长时间轮询？