El código hasta ahora está bien, hasta donde llega (excepto que una acumulación de 1 parece excesivamente estricta), el problema por supuesto viene cuando intentas accept
una conexión en cualquiera de las tomas, ya que accept
es normalmente un bloqueo de llamada (y "sondeo" al intentar aceptar con tiempos de espera cortos en cualquiera de los zócalos alternativamente quemará los ciclos de la máquina sin un buen propósito).
select al rescate! -) select.select
(o en el mejor SO select.poll
o incluso select.epoll
o select.kqueue
... pero, buenos viejos select.select
funciona en todas partes! -) le permitirá saber qué socket está listo y cuando, por lo que puede accept
apropiadamente. En esta línea, asyncore
y asynchat
proporcionan un poco más de organización (y un marco de terceros twisted
, por supuesto, agrega un lote de dicha funcionalidad "asincrónica").
Como alternativa, puede dedicar subprocesos separados al servicio de los dos sockets de escucha, pero en este caso, si la funcionalidad de los diferentes sockets necesita afectar las mismas estructuras de datos compartidas, la coordinación (bloqueo & c) puede ponerse delicada. Sin duda, recomendaría probar primero el enfoque asincrónico: ¡es más simple, y ofrece un rendimiento sustancialmente mejor! -)
Pero, la parte que no funciona es las dos ataduras. – mRt
@mRt, ¿qué síntomas está observando con las llamadas 'bind'? Parecen correctos para unir los dos puertos en todas las interfaces disponibles (eso es lo que significa el "host" de cadena vacía, por supuesto). –