2012-10-01 33 views
11

No estoy seguro de si estoy teniendo un tiempo de espera predeterminado (¿puedo configurar esto en alguna parte?), Pero tal vez me falta algo. Cuando el navegador de un cliente establece una conexión websocket, mantengo la persistencia. Luego, al desconectarme, elimino ese objeto persistente. Suficientemente simple. La desconexión normalmente se activa cuando un cliente cierra el navegador, pero no cuando el cliente apaga su conexión wi-fi (probando en una MacBook Pro, no es que esto importe).¿Desconexión 'dura' de websocket no aparente?

En el controlador Scala, estoy tala cada mensaje in, pero nada viene a través de cuando la conexión Wi-Fi está apagado (desde el docs, yo esperaría un EOF?).

creo que esto debe ser un error, ya que tomado de cómo interpretar la WS protocolel servidor deberá cerrar la conexión WebSocket , y debe registrar el problema. Pero esto último no sucede.

val in = Iteratee.foreach[String](x => { 
    logger.info("Websocket msg: " + x) 
    // expect EOF? 
    x match { 
    case "persist" => // persist some object 
    } 
}).mapDone { x => 
    // delete my persisted object (never happens unless browser/tab closed) 
} 

¿Alguien ha experimentado esto? Intenté con un controlador simple y algo que coincida con mi configuración. Ni los controladores ws3 ni ws2 a continuación hacen el truco. ¡Jugar! código de abajo:

object Application extends Controller { 

    private def ws(out: PushEnumerator[String]) = { 

    Logger.logger.info("ws()") 

    val in = Iteratee.foreach[String](x => { 
     Logger.logger.info("Websocket msg: " + x) 
     try { 
     x match { 
      case "persist" => Logger.logger.info("PERSIST") 
     } 
     } catch { 
     case e: Exception => { 
      Logger.logger.info("NOT RECOGNIZED COMMAND, NO PERSIST") 
     } 
     } 
    }).mapDone { x => 
     Logger.logger.info("STOP PERSIST") 
    } 
    in 
    } 

    def ws2() = WebSocket.using[String] { request => 

    Logger.logger.info("ws2()") 

    val out = Enumerator.imperative[String]() 
    val in = ws(out) 

    (in, out) 
    } 

    def ws3() = WebSocket.using[String] { request => 

    Logger.logger.info("ws3()") 

    val out = Enumerator.imperative[String]() 
    val in = Iteratee.foreach[String](x => { 
     Logger.logger.info("Websocket msg: " + x) 
     try { 
     x match { 
      case "persist" => Logger.logger.info("PERSIST") 
     } 
     } catch { 
     case e: Exception => { 
      Logger.logger.info("NOT RECOGNIZED COMMAND, NO PERSIST") 
     } 
     } 
    }).mapDone { x => 
     Logger.logger.info("STOP PERSIST") 
    } 
    (in, out) 
    } 

    def view() = Action { implicit request => 
    Ok(views.html.index.render("")) 
    } 
} 

la vista es un simple:

@(message: String) @main("Welcome to Play 2.0") { 

@play20.welcome(message) } 

<script type="text/javascript" charset="utf-8"> 
    var sock = new WebSocket("ws://192.168.1.120:9001/ws3"); 

    sock.onopen = function(event) { 
     sock.send('persist'); 
    } 
</script> 

Rutas:

GET  /ws2       controllers.Application.ws2 
GET  /ws3       controllers.Application.ws3 
GET  /view       controllers.Application.view 

Respuesta

2

Esto no es un juego tema marco específico, en lugar de una relacionada con la red. Lo que ocurre es que si se desconecta normalmente, el otro extremo envía el paquete FIN y el servidor lo sabe colgando. Si el otro extremo no tiene una conexión de red, no puede hacerlo.

¿Cómo determinar si un socket está abierto, entonces? Obtendrá una excepción cuando intente leer o escribir. Pero con un modelo sin bloqueo eso no sucede solo. Así que en su caso yo:

  • Tener un tiempo de espera
  • Haga JavaScript enviar pings dentro de un período de tiempo de espera
  • Si no hay pings llegar, se desconectan

o envían pings desde el lado del servidor (escritura a la toma).

+0

La gestión era algo que tenía miedo. Encontré esto también - https://code.google.com/p/chromium/issues/detail?id=76358 -. Parece que esto debería ser algo incorporado en el marco, o al menos hablarse de eso. ¡Gracias! –

+0

Para cualquiera que lea esto, ese "creeping" servidor de memoria también se incluye en esta categoría. –