É possível criar um aplicativo web que, com a ajuda de um servidor central, possa criar conexões diretas com outros usuários do mesmo aplicativo web? Estou imaginando um processo semelhante ao de perfuração UDP.

Eu li sobre a nova API WebSockets em HTML5, mas parece que você deve iniciar a conexão com um servidor compatível com WS antes que a conexão totalmente duplex possa começar. Estou pensando mais sobre um processo para fazer conexões diretas entre clientes, com um servidor se envolvendo apenas no handshake inicial.

NOTA: os miniaplicativos Java não contam. Estou interessado apenas em tecnologias de navegador padrão.

Em vez de suposições inteligentes, aqui está uma resposta informada:

O HTML 5 planeja permitir conexões ponto a ponto de javascript, mas essas conexões NÃO SERÃO TCP RAW.

A especificação completa pode ser encontrada em http://dev.w3.org/html5/websockets/

jrh

EDITAR: com referência específica a conexões ponto a ponto, verifique estes links:

• Com relação às conexões ponto a ponto: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• Com relação às conexões de transmissão para a rede local: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• Com relação às conexões TCP (no protocolo codificado): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• Especificação proposta completa: http://www.w3.org/TR/2008/WD-html5-20080122/#network

É importante observar que os recursos ainda estão sendo negociados. Será bom poder criar aplicativos da web de "bate-papo local" :)

jrh

ATUALIZAÇÃO 17/10/2012: Esta funcionalidade agora existe no Chrome Stable v22. Para usar essa funcionalidade no Chrome, é necessário habilitar dois sinalizadores em chrome: // flags:

• Habilitar MediaStream
• Habilitar PeerConnection

Em seguida, você pode visitar a página de demonstração AppRTC para experimentar a demonstração. Consulte a página WebRTC - Executando as Demonstrações para obter instruções mais detalhadas sobre como configurar o Chrome para usar a funcionalidade ponto a ponto e habilitar a captura de dispositivo.

ATUALIZAÇÃO: Os engenheiros da Ericcson Labs têm uma prova de conceito em um WebKit que faz vídeo de conversação ponto a ponto HTML5 .

Eles têm demonstrações em seu blog da tecnologia em ação, bem como diagramas e explicações sobre como a tecnologia funcionará.

Eles estão trabalhando para estabilizar e comprometer o repositório WebKit.

Sim, finalmente.

No momento em que este artigo foi escrito (2017), WebRTC agora é uma parte padrão da maioria dos navegadores modernos (cerca de 70% dos que estão em uso) e permite streaming de multimídia, ponto a ponto e perfuração.

Documentos, código de amostra e exemplos ao vivo para WebRTC podem ser encontrados em html5rocks.com .

De acordo com caniuse.com e html5rocks.com , os seguintes navegadores suportam WebRTC:

Suporte total: Edge 14, Firefox 22, Firefox Android 55
Suporte parcial: Android Browser 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
Suporte futuro ( Q3 2017): Chrome para iOS 11, Safari 11 para iOS 11 e OS X 10.11
Sem suporte: IE, IE Mobile, Opera Mini

A taxa de saturação do WebRTC é limitada em dispositivos Apple, já que o Safari 11 ainda não foi lançado e requer iOS 11 ou OS X 10.11. Apesar de projetar a partir de tendências de atualização anteriores, WebRTC deve estar disponível em cerca de 75% dos dispositivos iOS em 2018 e 100% em 2020.

Existem vários motivos pelos quais isso seria complicado:

1. Firewalls (mesmo apenas NATs simples) tornariam esse tipo de conexão difícil em uma camada protocal muito mais baixa do que até mesmo HTTP. Com o meu chapéu de segurança de TI, esta parece ser uma maneira maravilhosa de abrir portas arbitrárias em uma máquina, apenas visitando um site da Web - e assim seria bloqueado agressivamente por praticamente todos os sistemas de TI corporativos.
2. HTTP é inerentemente um protocolo cliente-servidor. Embora seja razoavelmente fácil simular comunicações duplex usando long polling (bem como algumas outras técnicas), não é particularmente eficiente.
3. Isso abriria um grande buraco para ataques XSS.

O WebSockets foi projetado para resolver o segundo desses problemas, mas (deliberadamente, eu espero) os outros dois não. Quando eles falam sobre ponto a ponto nas especificações HTML5, eles estão falando sobre comunicações full duplex entre o servidor e o cliente, não entre um cliente e outro.

No entanto, seria simples implementar uma pilha de rede apropriada em cima de websockets - com a condição de que toda a comunicação ainda teria que ser feita através do servidor. Eu vi isso usando long polling (um amigo meu na Uni escreveu uma pilha TCP / IP completa usando long polling).

Segundo harshath.jr: você poderia muito bem ter um servidor agindo como um diretório (expondo as "origens" de cada agente conectado; origem sendo o esquema + host + porta como em draft-abarth-origin , com o esquema sendo "ws" ou "wss"). Você pode então iniciar conexões WebSocket ponto a ponto; o SOP sendo trabalhado graças ao CORS . Claro, isso significa que cada agente (ou seja, navegador) teria que incorporar seu próprio servidor WebSocket (à la Opera Unite).

Nesse meio tempo, faça isso do modo XMPP / IRC / etc.: sem conexão ponto a ponto, mas conexões WebSocket a um servidor central (ou rede!) Para passar mensagens para os agentes conectados (eventualmente usando algum WebSocket específico " subprotocol ")

EDITAR: observe que tudo isso está realmente fora do escopo do HTML5 (todas essas coisas já fizeram parte do HTML5, mas foram divididas em suas próprias especificações)

Toda a ideia do Web Sockets era resolver os problemas com Firewalls e proxies http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket