Чи можливо створити веб-додаток, який за допомогою центрального сервера міг би створити прямі зв’язки з іншими користувачами того ж веб-додатка? Я уявляю процес, схожий на пробивання отворів UDP.

Я читав про новий API WebSockets в HTML5, але, здається, потрібно ініціювати з'єднання із сервером, сумісним із WS, перш ніж повністю розпочатись дуплексне з'єднання. Я більше замислююся над процесом встановлення прямих зв’язків між клієнтами, причому сервер залучається лише до початкового рукостискання.

ПРИМІТКА: аплети Java не враховуються. Мене цікавлять лише стандартні технології браузера.

Замість розумних здогадок, ось усвідомлена відповідь:

HTML 5 планує дозволити однорангові зв'язки з Javascript, але ці з'єднання НЕ будуть RAW TCP.

Повний опис можна знайти на веб- сайті http://dev.w3.org/html5/websockets/

jrh

EDIT: з конкретним посиланням на зв'язки однорангових, перевірте ці посилання:

• Що стосується підключень до однорангових: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• Що стосується широкомовного підключення до локальної мережі: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• Щодо підключень TCP (у кодованому протоколі): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• Повна запропонована специфікація: http://www.w3.org/TR/2008/WD-html5-20080122/#network

Важливо зазначити, що про можливості все ще ведуться переговори. Буде приємно мати можливість створити веб-додатки "локальний чат" :)

jrh

ОНОВЛЕННЯ 17.10.2012: Ця функціональність зараз існує в Chrome Stable v22. Щоб використовувати цю функціональність у Chrome, потрібно ввімкнути два прапори в хромі: // flags:

• Увімкнути MediaStream
• Увімкнути PeerConnection

Потім ви можете відвідати демонстраційну сторінку AppRTC, щоб спробувати демонстрацію. Див. WebRTC - Запуск сторінки Demos для отримання більш детальних інструкцій щодо налаштування Chrome для використання функцій однорангового перегляду та забезпечення можливості захоплення пристрою.

ОНОВЛЕННЯ: Інженери в лабораторіях Ericcson мають доказ концепції в побудові WebKit, що робить розмовне відео HTML Peer to Peer на розгляд .

Вони демонструють у своєму блозі технологію в дії, а також схеми та пояснення того, як технологія буде працювати.

Вони працюють над тим, щоб це стабілізувалося і було прийнято до сховища WebKit.

Так, нарешті.

Станом на це написання (2017), WebRTC тепер є стандартною частиною більшості сучасних браузерів (близько 70% тих, хто використовується), і дозволяє здійснювати потокове передавання мультимедіа, рівномірне та перфораційне отвір.

Документи, зразок коду та живі приклади для WebRTC можна знайти на html5rocks.com .

За caniuse.com і html5rocks.com наступні браузери підтримують WebRTC:

Повна підтримка: Edge 14, Firefox 22, Firefox Android 55
Часткова підтримка: 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
Майбутня підтримка ( Q3 2017): Chrome для iOS 11, Safari 11 для iOS 11 та OS X 10.11
Немає підтримки: IE, IE Mobile, Opera Mini

Швидкість насичення WebRTC обмежена на пристроях Apple, оскільки Safari 11 ще не випущений і вимагає iOS 11 або OS X 10.11. Незважаючи на те, що прогнозується на минулих тенденціях оновлення, WebRTC має бути доступний приблизно на 75% пристроїв iOS до 2018 року та 100% до 2020 року.

Є кілька причин, чому це було б складно:

1. Брандмауери (навіть просто звичайні NAT) ускладнювали б таке з'єднання на набагато нижчому протокольному шарі, ніж навіть HTTP. З моєю шапкою безпеки ІТ це здається чудовим способом відкрити довільні порти на машині, просто відвідавши веб-сайт, - і це буде агресивно заблоковано практично всіма корпоративними ІТ-системами.
2. HTTP по суті є протоколом клієнт-сервер. Хоча моделювати дуплексні комунікації досить просто за допомогою тривалого опитування (як і пару інших методик), це не особливо ефективно.
3. Це відкриє велику діру для атак XSS.

WebSockets розроблений для вирішення другого з цих питань, але (навмисно, я очікую) не двох інших. Коли вони говорять про одноранговий в специфікації HTML5, вони говорять про повне дуплексне спілкування між сервером і клієнтом, а не між одним клієнтом та іншим.

Однак було б просто застосувати правильний стек мережі поверх веб-сокетів - за умови, що все спілкування все-таки повинно здійснюватися через сервер. Я бачив це, використовуючи довге опитування (мій друг в Uni написав повний стек TCP / IP, використовуючи довге опитування).

Я другий harshath.jr: ви могли б дуже добре мати сервер, що виконує функції каталогів (викриваючи "походження" кожного підключеного агента; походження є схемою + хост + порт, як у проекті походження abarth , при цьому схема є або "ws" або "wss"). Потім ви можете ініціювати однорангові з’єднання WebSocket; СОП опрацьовується завдяки CORS . Звичайно, це означає, що кожен агент (тобто браузер) повинен був вбудувати власний сервер WebSocket (à la Opera Unite).

Тим часом зробіть це XMPP / IRC / etc.-way: немає однорангового з'єднання, але WebSocket підключення до центрального сервера (або мережі!) Для передачі повідомлень підключеним агентам (зрештою, використовуючи певний WebSocket " субпротокол ")

EDIT: зауважте, що все це насправді виходить за рамки HTML5 (всі ці речі колись були частиною HTML5, але були розділені на власні характеристики)

Вся ідея Web Sockets полягала у вирішенні проблем із брандмауерами та проксі-серверами http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket