（全功能）长轮询服务器如何抽象地工作 [英] How does a (full featured) long polling server work abstractly

问题描述

由于你使用的是事件循环而不是线程，实际的服务器看起来如何？

Since you're using an event loop as opposed to threads, how does the actual server look?

我知道它使用了一个事件循环，但是你怎么做分开请求？你如何防止你的服务器运行速度非常慢（因为我认为，因为它是无线程的，所以一次只能推送一个东西？）

I know it uses an event loop, but how do you separate out the requests? And how do you prevent your server from running extremely slowly (since it, I assume, can only push one thing at a time since it's threadless?)

某种伪 - 代码会很棒。

Some sort of pseudo-code would be great.

原谅我的无知;当然，如果某个地方用非基本的方式解释它这样就足够了，直到你有1000名游客的方式，我很高兴知道它。

Forgive my ignorance; of course, if there's somewhere that explains it in a non-basic "this is good enough until you get 1000 visitors way", I'd be glad to know of it.

推荐答案

长轮询服务器的实现细节会因平台而异，您的假设可能不正确。

The implementation details of a long poll server would vary so much from platform to platform that your assumptions might not be correct.

我使用.NET为我们的网站实施了COMET服务器。我利用 HttpListener 来做所有无聊的http内容和 Microsoft CCR 来处理所有异步IO。它使用一个线程池来处理请求，当它们进入时。它不是每个客户端的线程，但它不是单线程，通常需要几十个线程来保持流畅，因为用户数量增加。这种方法意味着我们可以轻松跨多个CPU核心进行扩展。 CCRs异步枚举器模式确实有助于保持异步逻辑的整洁，并且我可以在一年后相当容易地阅读代码。

I implemented a COMET server for our website using .NET. I leveraged HttpListener to do all the boring http stuff and Microsoft CCR to deal with all the async IO. It uses a pool of threads to service requests as and when they come in. It's not a thread per client, but it's not single threaded either generally requiring a few tens of threads to stay fluid as user numbers rise. This approach means that we scale easily across multiple CPU cores. CCRs async enumerator pattern really helped keep the asynchronous logic nice and tidy, and I can read the code fairly easily a year later.

这种方法已被证明具有极高的可扩展性。我已经测试了多达20000个客户端，于是我们受到网络IO的约束。它处理所有客户（永久连接，每30秒重新连接一次），服务器负载为1-2％。绝对值得重新考虑您必须选择事件循环架构而不是多线程的假设。中间地带非常适合我和。用于处理IO绑定任务的.NET异步编程模型实际上使您不再需要微管理线程。实际上，当有要处理的IO数据时，会从池中借用一个线程来执行该处理，然后返回到池中，准备为另一个请求提供服务。 所有复杂的IOCP内容被摘除了。

This approach has proved extremely scalable. I've tested up to 20000 clients, whereupon we became bound by network IO. It handles all our clients (who are "permanently" connected, reconnecting every 30s) ticking along at 1-2% server load. It's definitely worth reconsidering your assumption that you must either choose an event loop architecture as opposed to multiple threads. The middle ground works very nicely for me, and the .NET asynchronous programming model for dealing with IO bound tasks really takes you away from needing to micro-manage threads. Effectively, when there's IO data to process, a thread is borrowed from the pool to do that processing, and subsequently returned to the pool ready to service another request. All the complicated IOCP stuff is abstracted away.

这篇关于（全功能）长轮询服务器如何抽象地工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！