Domanda

È possibile creare un'app Web che, con l'aiuto di un server centrale, possa creare connessioni dirette con altri utenti della stessa app Web? Sto immaginando un processo simile alla perforazione UDP.

Ho letto della nuova API WebSocket in HTML5, ma sembra che sia necessario avviare la connessione con un server compatibile WS prima che possa iniziare la connessione completamente duplex. Sto pensando più a un processo per stabilire connessioni dirette tra client, con un server coinvolto solo nella stretta di mano iniziale.

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

È stato utile?

Soluzione

Invece di ipotesi intelligenti, ecco una risposta informata:

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

Le specifiche complete sono disponibili all'indirizzo http://dev.w3.org/html5/websockets/

JRH

EDIT: con specifico riferimento alle connessioni peer to peer, dai un'occhiata a questi link:

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

JRH

Altri suggerimenti

AGGIORNAMENTO 17/10/2012: questa funzionalità è ora disponibile 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 AppRTC per provare la demo. Consulta la WebRTC - Esecuzione delle demo per istruzioni più dettagliate sulla configurazione di Chrome per utilizzare la funzionalità peer to peer e abilitando l'acquisizione del dispositivo.


AGGIORNAMENTO: Gli ingegneri di Ericcson Labs hanno una prova di concetto in una build WebKit che Video conversazionale peer-to-peer HTML5 .

Nel loro blog sono disponibili dimostrazioni della tecnologia in azione, nonché diagrammi e spiegazioni su come funzionerà la tecnologia.

Stanno lavorando per stabilizzare e impegnarsi nel repository WebKit.

Sì, finalmente.

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

Documenti, codice di esempio ed esempi live per WebRTC sono disponibili all'indirizzo 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 (3 ° trimestre 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 proietti dalle tendenze passate degli aggiornamenti, WebRTC dovrebbe essere disponibile su circa il 75% dei dispositivi iOS entro il 2018 e il 100% entro il 2020.

Esistono diversi motivi per cui questo potrebbe essere complicato:

  1. I firewall (anche solo semplici NAT) renderebbero difficile questo tipo di connessione a un livello protocal molto più basso rispetto persino all'HTTP. Con il mio cappello di sicurezza IT attivo, questo sembra un modo meraviglioso per aprire porte arbitrarie su una macchina, semplicemente visitando un sito Web - e quindi sarebbe bloccato in modo aggressivo da praticamente tutti i sistemi IT aziendali.
  2. HTTP è intrinsecamente un protocollo client-server. Sebbene sia abbastanza facile simulare le comunicazioni duplex utilizzando il polling lungo (oltre a un paio di altre tecniche), non è particolarmente efficiente.
  3. Questo 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 adeguato in cima ai websocket - a condizione che tutte le comunicazioni debbano ancora essere fatte attraverso il server. Ho visto questo fatto 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 "origini" di ciascun agente connesso; origine essendo schema + host + porta come in draft-abarth-origin , con lo schema che può essere sia" ws "sia" wss ". È quindi possibile avviare connessioni WebSocket peer-to-peer; il SOP viene elaborato grazie a CORS . Ovviamente, ciò significa che ogni agente (ad esempio il browser) dovrebbe incorporare il proprio server WebSocket (& # 224; la Opera Unite).

Nel frattempo, esegui la modalità XMPP / IRC / ecc.: nessuna connessione peer-to-peer ma connessioni WebSocket a un server centrale (o rete!) per passare i messaggi agli agenti collegati (eventualmente usando alcuni WebSocket specifico "subprotocollo")

EDIT: nota che tutto ciò è in realtà al di fuori dell'ambito di HTML5 (tutte quelle cose una volta facevano parte di HTML5 ma sono state divise nelle loro specifiche)

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top