Czy można stworzyć aplikację internetową, która przy pomocy centralnego serwera mogłaby tworzyć bezpośrednie połączenia z innymi użytkownikami tej samej aplikacji internetowej? Wyobrażam sobie proces podobny do dziurkowania UDP.

Czytałem o nowym API WebSockets w HTML5, ale wygląda na to, że musisz zainicjować połączenie z serwerem kompatybilnym z WS, zanim będzie można rozpocząć połączenie w pełni dupleksowe. Myślę bardziej o procesie tworzenia bezpośrednich połączeń między klientami, z serwerem angażującym się tylko w początkowy uścisk dłoni.

UWAGA: Aplety Java się nie liczą. Interesują mnie tylko standardowe technologie przeglądarek.

Zamiast inteligentnych domysłów, oto przemyślana odpowiedź:

HTML 5 planuje zezwalać na połączenia peer to peer z javascript, ale te połączenia NIE BĘDĄ RAW TCP.

Pełną specyfikację można znaleźć pod adresem http://dev.w3.org/html5/websockets/

jrh

EDYCJA: ze szczególnym odniesieniem do połączeń peer to peer, sprawdź te linki:

• Odnośnie połączeń peer to peer: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• Odnośnie połączeń rozgłoszeniowych do sieci lokalnej: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• Odnośnie połączeń TCP (w zakodowanym protokole): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• Uzupełnij proponowaną specyfikację: http://www.w3.org/TR/2008/WD-html5-20080122/#network

Należy zauważyć, że możliwości są nadal negocjowane. Fajnie będzie móc tworzyć aplikacje internetowe typu „czat lokalny” :)

jrh

AKTUALIZACJA 17.10.2012: ta funkcja jest teraz dostępna w wersji Chrome Stable v22. Aby skorzystać z tej funkcjonalności w Chrome, należy włączyć dwie flagi w chrome: // flags:

• Włącz MediaStream
• Włącz PeerConnection

Następnie możesz odwiedzić stronę demonstracyjną AppRTC, aby wypróbować demo. Zobacz WebRTC - Uruchamianie strony Demos, aby uzyskać bardziej szczegółowe instrukcje dotyczące konfigurowania Chrome do korzystania z funkcji peer to peer i włączania przechwytywania urządzenia.

AKTUALIZACJA: Inżynierowie z Ericcson Labs mają dowód słuszności koncepcji w kompilacji WebKit, która obsługuje konwersacyjne wideo HTML5 Peer to Peer .

Mają na swoim blogu demonstracje technologii w akcji, a także diagramy i wyjaśnienia, jak będzie działać.

Pracują nad tym, aby ustabilizować to i wprowadzić do repozytorium WebKit.

Tak, w końcu.

W chwili pisania tego tekstu (2017) WebRTC jest obecnie standardową częścią większości nowoczesnych przeglądarek (około 70% używanych) i umożliwia strumieniowe przesyłanie multimediów, peer-to-peer i dziurkowanie.

Dokumenty, przykładowy kod i rzeczywiste przykłady dotyczące WebRTC można znaleźć pod adresem html5rocks.com .

Według caniuse.com i html5rocks.com , następujące przeglądarki obsługują WebRTC:

Pełna obsługa: Edge 14, Firefox 22, Firefox Android 55
Częściowa obsługa: Przeglądarka Android 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, Przeglądarka UC Android 11.4
Wsparcie w przyszłości ( III kw. 2017): Chrome na iOS 11, Safari 11 na iOS 11 i OS X 10.11
Brak wsparcia: IE, IE Mobile, Opera Mini

Współczynnik nasycenia WebRTC jest ograniczony na urządzeniach Apple, ponieważ Safari 11 nie zostało jeszcze wydane i wymaga systemu iOS 11 lub OS X 10.11. Chociaż przewidują wcześniejsze trendy aktualizacji, WebRTC powinien być dostępny na około 75% urządzeń z systemem iOS do 2018 r. I 100% do 2020 r.

Istnieje wiele powodów, dla których byłoby to trudne:

1. Zapory ogniowe (nawet zwykłe NAT) utrudniłyby tego rodzaju połączenie przy znacznie niższej warstwie protokołu niż nawet HTTP. Gdy mam założoną czapkę bezpieczeństwa IT, wydaje się to wspaniałym sposobem otwierania dowolnych portów na komputerze, po prostu przez odwiedzenie strony internetowej - a więc byłoby to agresywnie blokowane przez praktycznie wszystkie korporacyjne systemy IT.
2. HTTP jest z natury protokołem klient-serwer. Chociaż symulowanie komunikacji dupleksowej przy użyciu długiego odpytywania (a także kilku innych technik) jest dość łatwe, nie jest to szczególnie wydajne.
3. To otworzyłoby dużą lukę dla ataków XSS.

WebSockets ma na celu rozwiązanie drugiego z tych problemów, ale (spodziewam się celowo) nie dwóch pozostałych. Kiedy mówią o peer-to-peer w specyfikacji HTML5, mają na myśli komunikację w pełnym dupleksie między serwerem a klientem, a nie między jednym klientem a drugim.

Jednak byłoby łatwo zaimplementować odpowiedni stos sieciowy na szczycie gniazd sieciowych - z zastrzeżeniem, że cała komunikacja nadal musiałaby odbywać się za pośrednictwem serwera. Widziałem to przy użyciu długiego odpytywania (mój przyjaciel z Uni napisał pełny stos TCP / IP używając długiego odpytywania).

Po drugie harshath.jr: możesz równie dobrze mieć serwer działający jako katalog (ujawniający „pochodzenie” każdego podłączonego agenta; pochodzenie to schemat + host + port jak w wersji roboczej-abarth-origin , przy czym schemat to „ws” lub „wss”). Można wtedy zainicjować połączenia typu peer-to-peer WebSocket; SOP opracowywane przez dzięki CORS . Oczywiście oznacza to, że każdy agent (tj. Przeglądarka) musiałby osadzić swój własny serwer WebSocket (à la Opera Unite).

W międzyczasie rób to drogą XMPP / IRC / itd .: bez połączenia peer-to-peer, ale połączenia WebSocket z centralnym serwerem (lub siecią!), Aby przekazywać wiadomości do podłączonych agentów (ewentualnie przy użyciu określonego WebSocket " protokół podrzędny ”)

EDYTUJ: zauważ, że to wszystko jest poza zakresem HTML5 (wszystkie te rzeczy były kiedyś częścią HTML5, ale zostały podzielone na własne specyfikacje)

Cała idea gniazd sieciowych polegała na rozwiązaniu problemów z zaporami ogniowymi i serwerami proxy http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket