delphi coldfusion websocket delphi-2009 coldfusion-10

HTML5 WebSockets no funciona. Servidor=ColdFusion, Cliente=Delphi



delphi-2009 coldfusion-10 (4)

Estoy codificando un sistema de distribución de mensajes. El servidor es ColdFusion (CF) 10, utilizando el nuevo conjunto de características <cfwebsocket>. El cliente será escrito en Delphi 2009.

Si escribo el cliente en ColdFusion (usando la etiqueta <cfwebsocket>) las cosas funcionan bien: puedo enviar mensajes entre dos clientes. Entonces el lado del servidor parece estar funcionando.

No tuve tanta suerte con un cliente de Delphi. Hasta ahora he probado dos bibliotecas de componentes ( Delphi on Rails y sgcWebSockets ). Ambos parecen establecer una conexión con el servidor CF, pero los mensajes no se envían ni reciben. Estoy bastante seguro de que Delphi está haciendo una conexión con el servidor ya que no se lanzan excepciones si especifico la dirección correcta, mientras que recibo una excepción si especifico un puerto o URI diferente.

Creo que el eslabón perdido está en mi comprensión de "canales". Es fácil en CF: especifica el canal para suscribirse o enviar mensajes y funciona. Pero el concepto de "canales" no parece existir mucho fuera de ColdFusion. He buscado w3.org, Google, etc. y no veo mucho sobre los canales en las especificaciones HTML5 WebSocket. Algunas referencias, pero nada claro, especialmente en los ejemplos.

En resumen, mis preguntas:

  1. ¿Son "canales" parte de la API estándar de WebSocket? De ser así,
  2. ¿Cómo me suscribo a un canal usando una de las bibliotecas Delphi WebSocket que mencioné? ¿No debería ser tan fácil como ws: // [servidor]: [puerto] / [canal]?
  3. ¿Cómo depurar conexiones y tráfico WebSocket en el servidor CF?

Muchas gracias. Esta es mi primera publicación en StackOverflow; disculpas si es un poco largo.

Uso (o intento / investigación) esta implementación de websocket: http://code.google.com/p/bauglir-websocket/

No sé ColdFusion, también la parte de "canales" no es lo que sé de websockets. ¿Tiene CF un cliente web? Entonces puedes depurarlo fácilmente en Google Chrome

Probé esta demostración en línea: http://www.raymondcamden.com/demos/2012/feb/19/chat/#

Cuando coloco un punto de interrupción en la "función msgHandler" (Google Chrome, elemento de inspección, pestaña de script) obtengo los siguientes datos:

Object channel: "chat" clientid: 692538231 code: 0 msg: "ok" ns: "coldfusion.websocket.channels" reqType: "getSubscriberCount" subscriberCount: 1 type: "response" __proto__: Object

Sin embargo, cuando pruebo otra demo: http://www.raymondcamden.com/demos/2012/feb/19/whiteboard/ da esta información:

Object channelname: "whiteboard" data: Object ns: "coldfusion.websocket.channels" publisherid: 692539350 type: "data" __proto__: Object

Al menos veo algo de "canal" en él. Entonces, probablemente debas crear tu propio objeto JSON (como cadena) con algunas de las propiedades anteriores.

Esto no es realmente una respuesta, sino una sugerencia de solución de problemas. Divulgación: procedo de un entorno de CF, pero aún no he analizado la implementación de websocket, así que este es solo un consejo genérico y cómo solucionarlo.

Podría valer la pena mirar el tráfico HTTP y WS entre el cliente y el servidor en un cliente creado por CF, para ver dónde encaja el nombre del canal en las cosas. Revisé las especificaciones del socket web, y tampoco pude encontrar nada que pareciera equivaler a "canales".

Desde mi lectura de la especificación de websocket, hasta donde puedo decir, un URI = un "canal": no hay espacio para más de un canal (o "feed" quizás) en un URI. Desde una perspectiva de CF tal vez, y esto es una especulación completa, este concepto de "canal" es un truco de CF para poder rastrear más de un servicio de websocket en un único URI. CF se inclina hacia atrás (hasta el punto de caerse, a veces) para tratar de hacer la vida "más fácil" para los desarrolladores de CF, así que pude verlos haciendo esto. O simplemente decidieron implementar su propio camino, sin pensar que el cliente final podría no implementarse con las bibliotecas de CF también.

Dejando el material editorial a un lado: verifique qué sucede en los paquetes HTTP y WS que van entre el cliente y el servidor, y me imagino que podrá trabajar con WTH CF.

¡Gracias por los consejos! He depurado un poco desde que publiqué la pregunta y descubrí algunas respuestas.

¿Los "canales" son parte de la API estándar de WebSocket?

Por lo que puedo decir, no. Los canales parecen ser un concepto específico de ColdFusion.

¿Cómo me suscribo a un canal usando una de las bibliotecas Delphi WebSocket que mencioné? ¿No debería ser tan fácil como ws: // [servidor]: [puerto] / [canal]?

Como mencioné en mi pregunta original, Delphi (usando el componente TsgcWebSocketClient) se conectaba exitosamente al servidor WebSocket de ColdFusion (CF). Sin embargo, descubrí que estaba omitiendo un paso: suscribirse al "canal" de CF. Descubrí esto al usar Microsoft Network Monitor para comparar el tráfico del cliente Delphi con el tráfico del cliente CF. El cliente CF estaba enviando una cadena adicional al servidor después de conectarse:

{"ns":"coldfusion.websocket.channels","type":"welcome","authKey":"6DD10C406710970271EDA2295C409D38","subscribeTo":"signals","appName":"Test"}

Esto suscribe al cliente al canal de "señales". Entonces, agregué la siguiente línea a mi código Delphi después de hacer una conexión:

sgcWebSocketClient.WriteData( ''{"ns":"Delphi","type":"welcome","authKey":"6DD10C406710970271EDA2295C409D38","subscribeTo":"signals","appName":"Test"}'' );

y el cliente de Delphi pudo recibir inmediatamente mensajes del canal de "señales" de CF.

FYI, aquí está cómo enviar un mensaje ("¡Hola, Mundo!" En este caso) del cliente Delphi al canal "señales":

sgcWebSocketClient.WriteData( {"ns":"Delphi","type":"publish","channel":"signals","data":"Hello, World!","appName":"Test"}

¿Cómo depurar conexiones y tráfico WebSocket en el servidor CF?

Descubrí que Microsoft Network Monitor, con un filtro de puerto aplicado, era el método más fácil. Actualmente no es compatible con la monitorización loopback / localhost, por lo que utilicé otra computadora en nuestra LAN para generar el tráfico.