Можно ли создать веб-приложение, которое с помощью центрального сервера могло бы создавать прямые соединения с другими пользователями того же веб-приложения? Я представляю себе процесс, похожий на пробивание отверстий UDP.

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

ПРИМЕЧАНИЕ. Java-апплеты не учитываются. Меня интересуют только стандартные браузерные технологии.

Вместо умных догадок вот осознанный ответ:

HTML 5 планирует разрешить одноранговые соединения из javascript, но эти соединения НЕ БУДУТ RAW TCP.

Полную спецификацию можно найти на http://dev.w3.org/html5/websockets/.

младший

РЕДАКТИРОВАТЬ: с конкретной ссылкой на одноранговые соединения, проверьте эти ссылки:

• Что касается одноранговых соединений: 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

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

младший

ОБНОВЛЕНИЕ 17.10.2012: эта функция теперь существует в Chrome Stable v22. Чтобы использовать эту функцию в Chrome, необходимо включить два флага в chrome: // flags:

• Включить MediaStream
• Включить PeerConnection

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

ОБНОВЛЕНИЕ: инженеры Ericcson Labs имеют доказательство концепции в сборке WebKit, которая выполняет одноранговое диалоговое видео HTML5. .

В их блогах есть демонстрации технологии в действии, а также схемы и объяснения того, как технология будет работать.

Они работают над тем, чтобы стабилизировать это и добавить в репозиторий 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 основывается на прошлых тенденциях обновления, к 2018 году WebRTC должен быть доступен примерно на 75% устройств iOS и на 100% к 2020 году.

Это может быть сложно по ряду причин:

1. Брандмауэры (даже простые NAT) затрудняют такое соединение на гораздо более низком уровне протокола, чем даже HTTP. С моей шляпой по ИТ-безопасности это кажется прекрасным способом открыть произвольные порты на машине, просто посетив веб-сайт, и поэтому он будет агрессивно заблокирован практически всеми корпоративными ИТ-системами.
2. HTTP по своей сути является протоколом клиент-сервер. Хотя имитировать дуплексную связь с помощью длинного опроса (а также несколько других методов) достаточно просто, это не особенно эффективно.
3. Это открыло бы большую дыру для XSS-атак.

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

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

Во-вторых, harshath.jr: у вас вполне может быть сервер, действующий как каталог (показывающий "происхождение" каждого подключенного агента; происхождение - это схема + хост + порт, как в draft-abarth-origin , со схемой либо "ws" или "wss"). Затем вы можете инициировать одноранговые соединения WebSocket; СОП прорабатывается благодаря CORS . Конечно, это означает, что каждый агент (то есть браузер) должен будет встроить свой собственный сервер WebSocket (а-ля Opera Unite).

В то же время, сделайте это способом XMPP / IRC / и т. Д.: Без однорангового соединения, но соединения WebSocket с центральным сервером (или сетью!) Для передачи сообщений подключенным агентам (в конечном итоге с использованием некоторого конкретного WebSocket " подпротокол ")

РЕДАКТИРОВАТЬ: обратите внимание, что все это фактически выходит за рамки HTML5 (все эти вещи когда-то были частью HTML5, но были разделены на свои собственные спецификации)

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