È possibile creare una web app che, con l'ausilio di un server centrale, possa creare connessioni dirette con altri utenti della stessa web app? Immagino un processo simile alla perforazione UDP.

Ho letto della nuova API WebSockets in HTML5, ma sembra che sia necessario avviare la connessione con un server compatibile con WS prima che la connessione completamente duplex possa iniziare. Sto pensando dà fastidio solo di un processo per effettuare le connessioni dirette tra i clienti, con un server farsi coinvolgere solo nella stretta di mano iniziale.

NOTA: le applet Java non contano. Sono interessato solo alle tecnologie browser standard.

Invece di ipotesi intelligenti, ecco una risposta informata:

HTML 5 prevede di consentire connessioni peer to peer da javascript, ma queste connessioni NON SARANNO TCP RAW.

La specifica completa può essere trovata su http://dev.w3.org/html5/websockets/

jrh

EDIT: con specifico riferimento alle connessioni peer to peer, controlla questi link:

• Per quanto riguarda le connessioni peer to peer: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• Per quanto riguarda le connessioni di trasmissione alla rete locale: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• Per quanto riguarda le connessioni TCP (nel protocollo codificato): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• Specifica proposta completa: http://www.w3.org/TR/2008/WD-html5-20080122/#network

È importante notare che le capacità sono ancora in fase di negoziazione. Sarà bello poter creare applicazioni web di "chat locale" :)

jrh

AGGIORNAMENTO 17/10/2012: questa funzionalità ora esiste in Chrome Stable v22. Per utilizzare questa funzionalità in Chrome, è necessario abilitare due flag in chrome: // flags:

• Abilita MediaStream
• Abilita PeerConnection

Quindi puoi visitare la pagina demo di AppRTC per provare la demo. Consulta la pagina WebRTC - Esecuzione della demo per istruzioni più dettagliate su come configurare Chrome per utilizzare la funzionalità peer to peer e abilitare l'acquisizione del dispositivo.

AGGIORNAMENTO: Gli ingegneri di Ericcson Labs hanno una prova di concetto in una build WebKit che esegue video conversazionali peer to peer HTML5 .

Hanno dimostrazioni nel loro blog della tecnologia in azione, oltre a diagrammi e spiegazioni su come funzionerà la tecnologia.

Stanno lavorando per ottenere la stabilizzazione e il commit nel repository WebKit.

Si Finalmente.

Al momento della stesura di questo articolo (2017), WebRTC è ora una parte standard della maggior parte dei browser moderni (circa il 70% di quelli in uso) e consente lo streaming multimediale, peer-to-peer e perforazione.

Documenti, codice di esempio ed esempi dal vivo per WebRTC sono disponibili su html5rocks.com .

Secondo caniuse.com e html5rocks.com , i seguenti browser supportano WebRTC:

Supporto completo: Edge 14, Firefox 22, Firefox Android 55
Supporto parziale: 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
Supporto futuro ( Q3 2017): Chrome per iOS 11, Safari 11 per iOS 11 e OS X 10.11
Nessun supporto: IE, IE Mobile, Opera Mini

Il tasso di saturazione di WebRTC è limitato sui dispositivi Apple, poiché Safari 11 non è ancora stato rilasciato e richiede iOS 11 o OS X 10.11. Sebbene proiettando dalle tendenze di aggiornamento passate, WebRTC dovrebbe essere disponibile su circa il 75% dei dispositivi iOS entro il 2018 e il 100% entro il 2020.

Ci sono una serie di ragioni per cui questo sarebbe complicato:

1. I firewall (anche solo semplici NAT) renderebbero questo tipo di connessione difficile a un livello protocale molto più basso persino di HTTP. Con il mio cappello di sicurezza IT, questo sembra un modo meraviglioso per aprire porte arbitrarie su una macchina, semplicemente visitando un sito Web, e quindi sarebbe bloccato in modo aggressivo praticamente da tutti i sistemi IT aziendali.
2. HTTP è intrinsecamente un protocollo client-server. Sebbene sia ragionevolmente facile simulare comunicazioni duplex utilizzando un polling lungo (così come un paio di altre tecniche), non è particolarmente efficiente.
3. Ciò aprirebbe un grande buco per gli attacchi XSS.

WebSocket è progettato per risolvere il secondo di questi problemi, ma (deliberatamente, mi aspetto) non gli altri due. Quando parlano di peer-to-peer nelle specifiche HTML5, parlano di comunicazioni full duplex tra il server e il client, non tra un client e l'altro.

Tuttavia, sarebbe semplice implementare uno stack di rete appropriato sopra i websocket, a condizione che tutte le comunicazioni debbano ancora essere effettuate tramite il server. L'ho visto fare usando il polling lungo (un mio amico di Uni ha scritto uno stack TCP / IP completo usando il polling lungo).

Secondo harshath.jr: potresti benissimo avere un server che funge da directory (esponendo le "origini" di ciascun agente connesso; l'origine è schema + host + porta come in draft-abarth-origin , con lo schema sia "ws" o "wss"). È quindi possibile avviare connessioni WebSocket peer-to-peer; la SOP in lavorazione grazie a CORS . Ovviamente, questo significa che ogni agente (cioè il browser) dovrebbe incorporare il proprio server WebSocket (alla Opera Unite).

Nel frattempo, fallo nel modo XMPP / IRC / ecc.: Nessuna connessione peer-to-peer ma connessioni WebSocket a un server centrale (o rete!) Per passare messaggi agli agenti collegati (eventualmente utilizzando alcuni WebSocket specifici " sottoprotocollo ")

MODIFICA: nota che tutto questo è in realtà al di fuori dell'ambito di HTML5 (tutte queste cose una volta facevano parte di HTML5 ma sono state suddivise nelle loro specifiche)

L'intera idea di Web Sockets era quella di risolvere i problemi con firewall e proxy http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket