2012-01-20 8 views
6

Tengo un problema que no puedo entender.Extraño Flash AS3 xml Comportamiento de socket

Para entenderlo escribí un cliente de socket en AS3 y un servidor en python/twisted, puede ver el código de ambas aplicaciones a continuación.

Iniciemos dos clients al mismo tiempo, acomódelos para que pueda ver ambas ventanas y presione el botón de conexión en ambas ventanas. Luego presione y mantenga presionado cualquier botón.

Lo que estoy esperando:

cliente con el botón presionado envía un mensaje "algunos datos" al servidor, el servidor envía este mensaje a todos los clientes (incluyendo el remitente original).

Luego, cada cliente mueve a la derecha el botón 'connectButton' e imprime un mensaje en el registro con la hora en el siguiente formato: "min: secs: milisegundos".

lo que va mal:

El movimiento es suave en el cliente que envía el mensaje, pero en todos los demás clientes el movimiento es desigual.

Esto sucede porque los mensajes a esos clientes llegan más tarde que al cliente de envío original. Y si tenemos tres clientes (llamémosles A, B, C) y enviamos un mensaje desde A, el registro de tiempo de envío de B y C será el mismo.

¿Por qué otros clientes reciben estos mensajes más tarde que el remitente original?

Por cierto, en ubuntu 10.04/chrome todo el movimiento es fluido. Dos clientes se lanzan en cromos separados.

windows screenshot

linux screenshot

de ficha de registro, cuatro clientes de forma simultánea: código de cliente

[16:29:33.280858] 62.140.224.1 >> some data 
[16:29:33.280912] 87.249.9.98 << some data 
[16:29:33.280970] 87.249.9.98 << some data 
[16:29:33.281025] 87.249.9.98 << some data 
[16:29:33.281079] 62.140.224.1 << some data 
[16:29:33.323267] 62.140.224.1 >> some data 
[16:29:33.323326] 87.249.9.98 << some data 
[16:29:33.323386] 87.249.9.98 << some data 
[16:29:33.323440] 87.249.9.98 << some data 
[16:29:33.323493] 62.140.224.1 << some data 
[16:29:34.123435] 62.140.224.1 >> some data 
[16:29:34.123525] 87.249.9.98 << some data 
[16:29:34.123593] 87.249.9.98 << some data 
[16:29:34.123648] 87.249.9.98 << some data 
[16:29:34.123702] 62.140.224.1 << some data 

AS3, me dejaron parte sólo es relevante, full code here.

 private var socket   :XMLSocket; 

     socket = new XMLSocket(); 
     socket.addEventListener(DataEvent.DATA, dataHandler); 

     private function dataHandler(event:DataEvent):void 
     { 
      var now:Date = new Date(); 
      textField.appendText(event.data + "   time = " + now.getMinutes() + ":" + now.getSeconds() + ":" + now.getMilliseconds() + "\n"); 
      connectButton.x += 2; 
     } 

     private function keyDownHandler(event:KeyboardEvent):void 
     { 
      socket.send("some data"); 
     } 

     private function connectMouseDownHandler(event:MouseEvent):void 
     { 
      var connectAddress:String = "ep1c.org"; 
      var connectPort:Number = 13250; 

      Security.loadPolicyFile("xmlsocket://" + connectAddress + ":" + String(connectPort)); 
      socket.connect(connectAddress, connectPort); 
     } 

Python server code.

+1

Solo un pensamiento aquí, pero tengo la impresión de que si un objeto SWF no tiene foco en HTML, se ejecutará a una velocidad de fotogramas más baja. Esto explicaría el "choppyness", sin embargo, en ubuntu/chrome funcionó bien, que podría ser el reproductor de flash en esa configuración que lo maneja de manera diferente. ¿Lo has probado en diferentes máquinas y no solo en la misma máquina? Recuerdo vagamente haber leído que la tasa puede descender drásticamente a alrededor de 2 FPS –

+0

gracias, probé 2 máquinas diferentes con ubuntu y 4 con widnows, de todos modos. Cuando estoy ejecutando dos clientes, en dos máquinas diferentes (todos los clientes tienen un foco), los clientes esperan que los datos tengan un movimiento discontinuo y un mal registro de tiempo (como el que he publicado en la pregunta a continuación). –

Respuesta

4

Es posible que esté experimentando una combinación de ACK delay y/o Nagle's algorithm. Ambos pueden retrasar selectivamente el movimiento de datos en una sesión TCP y sus implementaciones varían mucho según la plataforma.

Intente usar setsockopt() con TCP_NODELAY en el zócalo para desactivar Nagle.

AFIK, Windows no le permite desactivar el retardo de ACK por socket: debe edit the registry y deshabilitarlo para todos los TCP. Así que intente primero con TCP_NODELAY. Si eso no funciona, entonces experimente con la desactivación del retraso de ACK. Incluso si la edición del registro no es práctica para su aplicación, el solo hecho de saber si la demora de ACK es el problema puede indicarle la dirección correcta para otras soluciones.

+0

¡Dios mío, parece que funciona! Establecí 'self.transport.setTcpNoDelay (True)' en el método * connectionMade * en el servidor twissted. –

1

Sé que esto es un poco tarde, pero lo más probable es que esto se deba al tiempo que lleva establecer la conexión TCP entre el servidor y el cliente no iniciador.

La idea es que ya existe una conexión TCP establecida entre el cliente iniciador y el servidor (está configurada antes del primer mensaje del cliente), por lo que se elimina el tiempo de toma de contacto de 3 vías. .

Puede probar esto de varias maneras, la más fácil es establecer una conexión antes del manejo real de sus mensajes (por ejemplo, enviando un mensaje ficticio a cada uno).

También puede cambiar a UDP si no desea configurar una conexión con cada cliente, pero luego pierde la confiabilidad de TCP.

No estoy seguro de haber entendido su nota sobre Linux. ¿Estás diciendo que funciona según lo previsto en Linux pero no en Windows? Si es así, necesitaremos saber más acerca de su configuración, por ejemplo, ¿están todos los clientes ejecutándose en el mismo host? En la misma instancia del navegador?

+0

No es tarde, gracias. Hay una conexión establecida antes de que los datos se envíen. Puedo verificarlo abriendo dos clientes (enlace al comienzo de la pregunta) y jugar con ellos. Sí, funciona como esperaba en Linux. El mismo host, el mismo reproductor de Flash que los clientes, Chrome en ambos. –