WebRTC: проверить реализацию, signaling и ICE

Сначала проверить реализацию

WebRtcPeerConnection — интерфейс соединения. Ему нужна рабочая реализация для целевой платформы. В проверенном чистом Windows C#-проекте Reckfell 1.0.0 без внешней реализации выбирается пустой WebRTCPeerConnectionExtension. Сам факт наличия класса в SDK не означает доступный обмен.

Добавьте RtcBackendProbe.cs к Entity отдельного C#-уровня, соберите и запустите F6. В этом чистом проекте ожидается WebRTC: implementation missing; дополнительно движок предупреждает, что default extension не настроен. Probe намеренно не вызывает методы пустой реализации.

using Reckfell;

public partial class RtcBackendProbe : Entity
{
    public string NativeClass { get; private set; } = "";
    public bool MissingImplementation { get; private set; }
    public Error? InitializeResult { get; private set; }
    private WebRtcPeerConnection? _peer;
    public override void _Ready()
    {
        _peer = new WebRtcPeerConnection(); NativeClass = _peer.GetClass().ToString();
        using Variant script = _peer.GetScript();
        MissingImplementation = NativeClass == "WebRTCPeerConnectionExtension" && script.VariantType == Variant.Type.Nil;
        if (MissingImplementation) { ReckfellApi.Print("WebRTC: implementation missing"); return; }
        InitializeResult = _peer.Initialize();
        ReckfellApi.Print($"WebRTC: implementation={NativeClass}, initialize={InitializeResult}; connection not established by this probe");
    }
    public override void _ExitTree()
    { if (!MissingImplementation) _peer?.Close(); _peer?.Dispose(); _peer = null; }
}

Проверка различает стандартный пустой класс без скрипта и выбранную реализацию. Другой тип ещё нужно проверить Initialize, реальным обменом и закрытием на целевой платформе. Probe сам не устанавливает соединение.

У пустой реализации вызов обязательного виртуального _initialize выводит ошибку движка, но возвращаемый Error может оказаться значением по умолчанию Error.Ok. Этот случай воспроизведён в отдельной проверке. Поэтому Error.Ok, класс в SDK и компиляция — три недостаточных доказательства работающего WebRTC.

Для нативного backend нужна реализация WebRTCPeerConnectionExtension и связанных каналов с корректной регистрацией; SetDefaultExtension выбирает зарегистрированный класс, а не скачивает/запускает библиотеку. Веб-реализация использует браузерный WebRTC, но из этого не следует доступный C#-экспорт или поддержка конкретного браузера. Не устанавливайте произвольное расширение без проверки ABI и целевой сборки 1.0.0.

Что нужно помимо backend

Signaling — обмен служебными данными между участниками через отдельный канал, например ваш HTTPS/WebSocket-сервис. Это не передача игрового состояния самим WebRTC и не готовый сервис внутри CreateOffer.

Оба участника должны принадлежать правильной signaling-сессии. Не применяйте чужие SDP/ICE к случайному соединению. Очерёдность сообщения, повтор, срок жизни и авторизация signaling относятся к вашему приложению.

Порядок установления

1. Создайте peer, подключите SessionDescriptionCreated, IceCandidateCreated и DataChannelReceived; задайте конфигурацию реализации через Initialize.
2. На инициаторе создайте нужный data channel до CreateOffer. При SessionDescriptionCreated примените SetLocalDescription и передайте type/sdp другому участнику.
3. Полученную удалённую SDP примените SetRemoteDescription. Ответная сторона также отправляет свою созданную локальную SDP через signaling.
4. Передавайте IceCandidateCreated через signaling и применяйте удалённые данные AddIceCandidate. Согласуйте буферизацию кандидатов с готовностью удалённого описания вашей реализации.
5. Продолжайте Poll. Отправляйте игровые данные только после реального открытия канала; обрабатывайте ошибки и закрытие, ограничивайте срок ожидания сигнала.

Это описание работы API. Установленное WebRTC-соединение в чистом Windows-проекте не проверено: для него нужна рабочая реализация. Проверяйте её, signaling-сервис, пары платформ, NAT/TURN, потерю сети и повторную сессию до заявления о поддержке.

Не подменять уровни

WebRtcDataChannel передаёт данные; WebRtcMultiplayerPeer связывает подходящие соединения с высокоуровневым MultiplayerApi. Raw data channel не становится RPC-лобби автоматически. Настройки порядка/надёжности канала не заменяют проверку игровых данных и серверных прав.

При завершении закройте каналы/peer и удалите их из signaling-сессии; не передавайте новые ICE/SDP старому закрытому экземпляру. Если задача — обычный нативный серверный мультиплеер без браузерного WebRTC, начните с проверенного лобби ENet. Для обмена с сервисом достаточно HTTP или WebSocket.