Отличие WebRTC в том, что связь идет напрямую, а не через сервер мордокниги, вконтакта, ютуба и т.п. То есть это в чистом виде p2p соединение.
Не всегда напрямую (TURN) и всегда не в чистом виде.
Недостаток (один из...) в том, что для начала соединения нужно обменяться некими "сигнальными" данными. Обмен можно произвести хоть голубинной почтой, но обычно для этого используют промежуточные "сигнальные сервера". Эти сигнальные сервера являются уязвимым местом для возможных атак из вне или для всяких роскомпозоров.
Обмен хоть и можно произвести голубинной почтой, но есть нюансы и работать толком ничего не будет, поэтому "обычно используют" в данном случае уместно заменить на "всегда используют".
А ещё, сигнальные серверы это bottleneck для производительности и масштабирования сети.
Есть идея: создать децентрализованную WebRTC сеть в которой сигнальными серверами, будут сами клиенты (браузеры, приложения).
То есть совсем от настоящих сигнальных серверов отказаться не получится, но попытаться минимизировать их роль в поддержке сети.
Сейчас идея на стадии идеи. Концепция более или менее уже понятна. Совсем нет времени на реализацию. Если кто-то захочет реализовать, то буду рад помочь и поучаствовать в разработке.
Я на эту идею джва года как забил. Минимизировать роль сигнальных серверов невозможно, потому что WebRTC это не настоящий p2p.
Суть в том, что нужно провести что-то типа научного исследования... То есть сейчас мне не понятно в принципе: реализуема ли идея или нет?
Нет.
Чтобы установить соединение, два пира должны обменяться сигнальными данными: один пир генерирует сигнал который называется offer - это тупой набор тектовых данных, другой пир получает этот текст и на его основе генерирует сигнал answer - тоже текст который надо послать обратно первому пиру.
Когда пиры обменялись этими текстовыми данными, происходит магия: соединение считается установленным, пиры получают возможность обмениваться данными, даже если между ними 100500 роутеров и ип адреса у этих пиров что-то типа 192.168.1.1 или 127.0.0.1
Это не тупой набор текстовых данных. К нему прилагается маршрут, поэтому никакой магии нет. Без браузеров и WebRTC хендшейк нескольких пиров организовать ещё проще, что более магично, как по мне.
Так вот, сейчас я пока не могу понять: что происходит при разрыве соединения? Офферы и ансверы протухают и надо генерировать новые? Или можно например запомнить оффер, выключить комп, потом сгенерировать новый ансвер на основе старого оффера, отправить партнеру новый ансвер и опять соединиться получается со старым оффером, но с новым ансвером?
А может вообще можно запомнить офферы и ансверы при разрыве соединения и потом использовать эту сигнальную информацию повторно для нового соединения? Это было бы вообще прикольно. Тогда точно можно сделать одноранговую p2p сеть, запоминая офферы и ансверы где-нибудь в localStorage и используя эту информацию так, как обычные p2p сети используют IP адреса.
Так не получится. Протухают даже при закрытии вкладки, порты закрываются, движок отклоняет все некошерные соединения. Браузеры это проприетарное говно с открытым исходным кодом, поэтому никакой децентрализации и прочих p2p они совсем не умеют, а все их фичи a.k.a. стандарты отдалённо похожие на это спроектированы настолько извратно, чтобы их использование третьей стороной никак не могло угрожать централизованной монополии Цукербринов.
.