¿Es posible crear una aplicación web que, con la ayuda de un servidor central, pueda crear conexiones directas con otros usuarios de la misma aplicación web? Me estoy imaginando un proceso similar a la perforación de orificios UDP.

He leído acerca de la nueva API de WebSockets en HTML5, pero parece que debe iniciar la conexión con un servidor compatible con WS antes de que pueda comenzar la conexión totalmente dúplex. Estoy pensando más en un proceso para hacer conexiones directas entre clientes, con un servidor involucrado solo en el apretón de manos inicial.

NOTA: Los subprogramas de Java no cuentan. Solo me interesan las tecnologías de navegador estándar.

En lugar de conjeturas inteligentes, aquí hay una respuesta informada:

HTML 5 planea permitir conexiones de igual a igual desde javascript, pero estas conexiones NO SERÁN RAW TCP.

La especificación completa se puede encontrar en http://dev.w3.org/html5/websockets/

jrh

EDITAR: con referencia específica a las conexiones de igual a igual, consulte estos enlaces:

• Con respecto a las conexiones entre pares: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• Con respecto a las conexiones de transmisión a la red local: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• Respecto a las conexiones TCP (en el protocolo codificado): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• Especificaciones propuestas completas: http://www.w3.org/TR/2008/WD-html5-20080122/#network

Es importante señalar que las capacidades aún se están negociando. Será bueno poder crear aplicaciones web de "chat local" :)

jrh

ACTUALIZACIÓN 17/10/2012: esta funcionalidad ahora existe en Chrome Stable v22. Para utilizar esta funcionalidad en Chrome, se deben habilitar dos banderas en chrome: // flags:

• Habilitar MediaStream
• Habilitar PeerConnection

Luego, puede visitar la página de demostración de AppRTC para probar la demostración. Consulte WebRTC: Ejecución de la página Demos para obtener instrucciones más detalladas sobre cómo configurar Chrome para usar la funcionalidad de igual a igual y habilitar la captura de dispositivos.

ACTUALIZACIÓN: Los ingenieros de Ericcson Labs tienen una prueba de concepto en una compilación de WebKit que hace HTML5 Peer to Peer Conversational Video .

Tienen demostraciones en su blog de la tecnología en acción, así como diagramas y explicaciones sobre cómo funcionará la tecnología.

Están trabajando para estabilizarlo y comprometerlo con el repositorio de WebKit.

Sí, finalmente.

En el momento de escribir este artículo (2017), WebRTC es ahora una parte estándar de la mayoría de los navegadores modernos (alrededor del 70% de los que están en uso) y permite la transmisión multimedia, de igual a igual y la perforación.

Se pueden encontrar documentos, código de muestra y ejemplos en vivo para WebRTC en html5rocks.com .

Según caniuse.com y html5rocks.com , los siguientes navegadores admiten WebRTC:

Soporte completo: Edge 14, Firefox 22, Firefox Android 55
Soporte parcial: Navegador Android 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
Soporte futuro ( Q3 2017): Chrome para iOS 11, Safari 11 para iOS 11 y OS X 10.11
Sin soporte: IE, IE Mobile, Opera Mini

La tasa de saturación de WebRTC está limitada en los dispositivos Apple, ya que Safari 11 aún no se lanzó y requiere iOS 11 u OS X 10.11. Aunque se proyecta a partir de tendencias de actualización pasadas, WebRTC debería estar disponible en alrededor del 75% de los dispositivos iOS para 2018 y el 100% para 2020.

Hay varias razones por las que esto sería complicado:

1. Los cortafuegos (incluso los NAT simples) dificultarían este tipo de conexión en una capa protocal mucho más baja que incluso HTTP. Con mi sombrero de seguridad de TI puesto, esta parece una manera maravillosa de abrir puertos arbitrarios en una máquina, simplemente visitando un sitio web, por lo que sería bloqueado agresivamente por prácticamente todos los sistemas de TI corporativos.
2. HTTP es inherentemente un protocolo cliente-servidor. Si bien es razonablemente fácil simular comunicaciones dúplex utilizando un sondeo largo (así como un par de otras técnicas), no es particularmente eficiente.
3. Esto abriría un gran agujero para los ataques XSS.

WebSockets está diseñado para resolver el segundo de estos problemas, pero (deliberadamente, espero) no los otros dos. Cuando hablan de peer-to-peer en la especificación HTML5, están hablando de comunicaciones full duplex entre el servidor y el cliente, no entre un cliente y otro.

Sin embargo, sería sencillo implementar una pila de red adecuada en la parte superior de los websockets, con la condición de que toda la comunicación debería realizarse a través del servidor. He visto esto hecho usando un sondeo largo (un amigo mío en Uni escribió una pila TCP / IP completa usando un sondeo largo).

Yo segundo harshath.jr: muy bien podría tener un servidor actuando como un directorio (exponiendo los "orígenes" de cada agente conectado; el origen es esquema + host + puerto como en draft-abarth-origin , con el esquema siendo "ws" o "wss"). A continuación, puede iniciar conexiones WebSocket de igual a igual; el SOP se está trabajando gracias a CORS . Por supuesto, esto significa que cada agente (es decir, navegador) tendría que integrar su propio servidor WebSocket (al estilo Opera Unite).

Mientras tanto, hágalo de la manera XMPP / IRC / etc.: sin conexión de igual a igual, pero con conexiones WebSocket a un servidor central (¡o red!) Para pasar mensajes a los agentes conectados (eventualmente usando algún WebSocket específico " subprotocolo ")

EDITAR: tenga en cuenta que todo esto está realmente fuera del alcance de HTML5 (todas esas cosas alguna vez fueron parte de HTML5, pero se han dividido en sus propias especificaciones)

Toda la idea de Web Sockets era resolver los problemas con firewalls y proxies http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket