擅长:python、mysql、java
<p>当然,我们需要实际的代码来调试这个问题。但你主要问的是:</p>
<blockquote>
<p>Is there a better (e.g. more efficient) framework to accomplish my chat implementation?</p>
</blockquote>
<p>是的。人们普遍认为<code>asyncore</code>很糟糕。它既难用又效率低。它在Windows上尤其糟糕,因为<code>select</code>在Windows上尤其糟糕。在</p>
<p>所以,是的,使用不同的框架可能会让事情变得更好。在</p>
<p>不幸的是,SO问题不是获得框架建议的好地方,但是我可以抛出一个常见的怀疑列表:<a href="http://twistedmatrix.com" rel="nofollow">twisted</a>,<a href="https://github.com/saucelabs/monocle" rel="nofollow">monocle</a>,<a href="http://gevent.org" rel="nofollow">gevent</a>,<a href="http://eventlet.net/" rel="nofollow">eventlet</a>,<a href="http://www.python.org/dev/peps/pep-3156/" rel="nofollow">tulip</a>。在</p>
<p>或者,如果您不担心可扩展到几十个客户机,只关心小规模的性能,那么每个客户机使用一个线程(甚至两个线程,一个用于读,一个用于写)和阻塞I/O非常简单。在</p>
<p>最后,如果您一直在使用python3.x,那么3.4很有可能会有一个新的改进的异步I/O模块,它比<code>asyncore</code>更高效、更易于使用(而且它几乎肯定是基于<code>tulip</code>)的。所以…最好的解决办法可能是买台时光机,再往前走几个月。(或者,如果您是一个将来搜索此答案的读者,请查看<a href="http://docs.python.org/3/library/ipc.html" rel="nofollow">IPC</a>下的标准库,猜测哪个模块是新的改进的异步I/O模块。)</p>