我正在尝试为内部应用程序构建流媒体解决方案，但正在为解决方案绘制空白以克服障碍。目前，在我的工作示例中，我正在使用 APE，但由于限制，我无法使用任何主机上有外部正在运行的进程，因此我无法运行 APE 服务器。
我正在寻找替代方案，但到目前为止我发现的所有内容都需要在服务器上运行进程。
有关该项目的一些细节。
- 一次大约有 25 人连接
- 理想情况下，每个人都应该在更新可用时同时看到更新。
- 它将在 Windows 环境中运行，因此 C#/.NET 解决方案比 PHP 等解决方案更可取。
如果node.js能够处理这个问题，或者有任何其他解决方案，任何人都有任何想法吗？
I'm trying to build a streaming solution for an internal app, but am drawing blanks for a solution to get past a roadblock. Currently, in my working example, I'm using APE, but due to restrictions I can't have any foreign running processes on the host machine, so I can't run the APE server.
I'm looking for alternatives, but everything I've found so far has required running processes on the server.
Some details about the project.
- There will be approximately 25 people connected at one time
- Ideally everyone should see the updates at the same time, as soon as they're available.
- It will be running in a Windows environment, so C#/.NET solutions would be preferable over things like PHP.
Anyone have any ideas, if node.js is capable of handling this, or of any other solutions?
发布评论
评论（4）
问题在于，传统的 Web 服务器使用每个套接字线程的方法来处理并发用户，这对于 comet/长轮询技术并不总是最佳的。 （较新版本的 IIS 有一种方法可以插入您自己的连接处理程序，我将在下面介绍。）
对于传统的 Web 服务器，更常见的目标是获得连接，尽快为用户提供服务，然后移至下一个连接。如果连接长时间徘徊，可能是因为它可能正在执行一些密集的操作，例如大量下载或大量查询，但总体而言，它积极使用 CPU，因此线程模型工作得很好。
在 comet（长轮询）中，通常您会连接到 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 中的标准线程监视器来构建您自己的 comet 事件调度事物。
然而，运行较新版本 IIS 的 .NET 应用程序确实有一线希望。您可以创建自定义 IAsyncHttpHandler。有一些很棒的在线指南供您阅读，了解其工作原理。这样您就可以建立自己的连接池并更有效地为您的客户提供服务。这不是一个完美的解决方案，您必须自己建造大量管道。 WebSync 是一款商业产品，它为您封装了此界面，并为您提供了一些可以使用的高级框架部分与然而。
The issue is that traditional web servers use a thread per socket approach to handling concurrent users which is not always optimal for comet/long polling techniques. (Newer versions of IIS have a way to plug in your own connection handlers however, which I will get too below.)
For the traditional web servers, more often the goal is to get a connection, serve the user up something as quick as possible, and move to the next connection. If a connection is lingering for a long time, its because its probably doing something intensive, like a big download or huge query but overall its actively using the CPU so the threaded model works pretty well.
In comet (long polling), normally you are connecting to a web server where you just wait for an event to occur, and more often than not. This promotes more concurrent connections. Also chacnes are that many of these users are waiting on the same events to occur across the board.
Allocating a thread then for a user to primarily just spin and wait is not a very optimal model for this type of thing. A better model is a event loop based web server that does everything in an asynchronous kind of fashion, and where dispatching off an event to multiple users doesn't involve a costly context switch for each client. This what Node.js is built on (using libevent as its core), as well as Ruby Eventmachine, Twisted Python, Friendfeed's Tornado, Jetty, and the C# based Manos server.
That is why there it's often more advantageous to have comet done on its own process custom a custom server since traditional web servers like Apache and older versions of IIS do not function in a matter that is efficient for Comet's needs.
Standard ASP.NET apps are little bit screwed because thread pool in .NET is limited to 25 general threads and 25 IO threads (and http connections take an IO thread). You may be effectively limited to be slightly less than that in reality because the thread pool is shared with all the other things in .NET. You can bump the thread pool up though with a configuration setting however, but performance has a tendency to decay exponentially the more threads you throw in. You could in theory bump this number up if you can guarantee you won't grow too much, and then possibly just use standard thread monitors in .NET to build your own comet event dispatching thing.
However .NET apps running newer versions of IIS do have a ray of hope though. You can create a custom IAsyncHttpHandler. There are some great guides online for you read up on how this works. With that you can build up your own connection pool and serve your clients more efficiently. It's not a perfect solution and you have to build out lot of plumbing on your own. WebSync is a commercial product that wraps this interface for you and gives you some high level framework pieces you can work with however.
WebSync 将是您的一个很好的解决方案；它在 IIS 上运行，因此不需要外部进程。请查看此处。
WebSync would be a good solution for you; it runs on IIS, so no external processes are needed. Check it out here.
您可以使用长池自行实现它。
25 个同时请求对于 IIS 来说应该不成问题。
只要看看 APE 流向客户端的内容即可 - 如何在 100 行代码中重新实现它（我的意思是以兼容格式进行序列化）非常干净。
You could implement it on your own, using long pooling.
25 simultanious requests should be no issue for IIS.
Just take a look what APE streams to the clients - it's pretty clean how to reimplement that in 100 lines of code (I mean serialization in the compatible format).
您看过 PubNub 吗？它也许能够处理你正在做的事情。它需要花钱，但你也可以获得大量免费交易。不确定您期望什么样的负载。
Have you looked at PubNub? It might be able to handle what you are doing. It costs money, but you get a bunch of free transactions too. Not sure what kind of load you expect.