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