我正在尝试为内部应用程序构建流式传输解决方案，但我正在为解决方案提供空白，以克服障碍。目前，在我的工作示例中，我正在使用APE，但由于限制，我无法在主机上运行任何外部进程，因此无法运行APE服务器。
我正在寻找替代方案，但到目前为止我发现的所有内容都需要在服务器上运行进程。
有关该项目的一些细节。
任何人都有任何想法，如果node.js能够处理这个或任何其他解决方案吗？
答案 0 :(得分：9)
问题在于传统的Web服务器使用每插槽线程方法来处理并发用户，这对于彗/长轮询技术并不总是最佳的。 （较新版本的IIS有一种方法可以插入您自己的连接处理程序，但我会得到以下内容。）
对于传统的Web服务器，更常见的目标是获得连接，尽快为用户提供服务，然后转移到下一个连接。如果一个连接长时间挥之不去，那么因为它可能正在做一些密集的事情，比如一个大的下载或大的查询，但整体上它主动使用CPU，所以线程模型工作得很好。
在彗星（长轮询）中，通常您将连接到您只是等待事件发生的Web服务器，而且通常是这样。这促进了更多的并发连接。此外，很多用户都在等待同一事件全面发生。
然后为用户分配线程主要只是旋转和等待对于这类事物来说不是一个非常优化的模型。更好的模型是基于事件循环的Web服务器，它以异步方式执行所有操作，并且将事件分派给多个用户不会为每个客户端进行昂贵的上下文切换。这就是构建Node.js（使用libevent作为核心），以及Ruby Eventmachine，Twisted Python，Friendfeed的Tornado，Jetty和基于C＃的Manos服务器。
这就是为什么在自己的流程上完成彗星定制自定义服务器通常更有利，因为传统的Web服务器（如Apache和旧版本的IIS）不能在高效满足Comet需求的情况下运行。
标准的ASP.NET应用程序有点紧张，因为.NET中的线程池限制为25个通用线程和25个IO线程（并且http连接采用IO线程）。您可能实际上被限制为略低于实际情况，因为线程池与.NET中的所有其他内容共享。但是你可以通过一个配置设置来提升线程池，但是当你输入的线程越多时，性能就会呈指数级衰减。如果你能保证你不会增长太多，理论上可以提高这个数字。然后可能只是在.NET中使用标准线程监视器来构建自己的彗星事件调度事物。
然而，运行较新版本IIS的.NET应用确实有一线希望。您可以创建自定义IAsyncHttpHandler。网上有一些很棒的指南，让您了解它是如何工作的。有了它，您可以建立自己的连接池，更有效地为您的客户服务。它不是一个完美的解决方案，你必须自己构建大量的管道。 WebSync是一个商业产品，它为您提供了这个界面，并为您提供了一些您可以使用的高级框架部分。
答案 1 :(得分：1)
WebSync对您来说是一个很好的解决方案;它在IIS上运行，因此不需要外部进程。请查看here。
答案 2 :(得分：0)
您可以使用长池自己实现它。 对于IIS来说，25个同步请求应该没有问题。 看看APE流向客户端的内容 - 如何在100行代码中重新实现这一点非常简洁（我的意思是以兼容格式进行序列化）。
答案 3 :(得分：0)
你看过PubNub了吗？它可能能够处理你正在做的事情。这需要花钱，但你也得到了一堆免费交易。不确定你期望什么样的负载。