Un'implementazione Pascal nativa dello stack peer-to-peer WebRTC: RTCPeerConnection, raccolta dei candidati ICE e controlli di connettività, client e server STUN e TURN, key agreement DTLS-SRTP e data channel SCTP — con il signalling WebSocket già cablato.
Porta P2P di livello browser in Delphi — senza distribuire Chromium.
Una libreria WebRTC Delphi consente a due processi Delphi (o a un processo Delphi e a un browser) di stabilire un canale diretto, attraverso NAT, cifrato end-to-end, senza instradare il payload attraverso un server centrale. sgcWebSockets fornisce ogni mattone WebRTC come componente Pascal: TsgcRTCPeerConnection rispecchia l'API W3C RTCPeerConnection, TsgcSTUNClient / TsgcSTUNServer implementano RFC 8489, TsgcTURNClient / TsgcTURNServer implementano RFC 8656, e TsgcICEClient, un agente ICE completo, li tiene insieme.
A differenza degli stack basati su browser (che richiedono Chromium o libwebrtc — decine di megabyte di codice nativo e una build complicata) l'implementazione sgcWebSockets è puro Pascal sopra OpenSSL e si compila nel tuo binario. Gira da Delphi 7 a Delphi 13 e distribuisce binari nativi per Win32/Win64, Linux64, macOS, iOS e Android.
Serializer e parser SDP integrati. Genera offer, accetta answer, fai trickle dei candidati ICE con lo stesso formato di rete prodotto da Chrome e Firefox.
Agente ICE
Raccolta completa dei candidati: host, server-reflexive (scoperti via STUN), relayed (allocati via TURN). Pairing, prioritizzazione e controlli di connettività secondo RFC 8445. Pagina ICE.
Client e server STUN
Client STUN e server STUN standalone per la scoperta NAT e il keep-alive. Esegui il tuo endpoint STUN con due righe di Pascal.
Client e server TURN
Client TURN per l'allocazione del relay e server TURN per il self-hosting. Long-term credential, IPv4 + IPv6.
DTLS-SRTP
Il protocollo di key agreement obbligatorio per WebRTC. Handshake DTLS 1.2 sullo stesso path UDP negoziato da ICE, esportando il keying material per SRTP.
Data channel SCTP
Messaggi affidabili / non affidabili, ordinati / non ordinati sul trasporto media WebRTC — il modo standard di inviare dati applicativi arbitrari peer-to-peer.
Signalling WebSocket
Usa i TsgcWebSocketClient / TsgcWebSocketHTTPServer inclusi come canale di signalling, oppure la coppia di protocolli già pronta TsgcWSPClient_RTCPeerConnection e TsgcWSPServer_RTCPeerConnection. Una libreria per tutto.
Signalling
Signalling WebSocket: il pattern standard
WebRTC non definisce un protocollo di signalling — te lo porti tu. La scelta convenzionale è un canale WebSocket che trasporta tre tipi di messaggio: offer (SDP dal chiamante), answer (SDP dal chiamato) e ice-candidate (candidati inviati a trickle da entrambe le parti). sgcWebSockets include già entrambi i lati di quel canale. TsgcWSPServer_RTCPeerConnection abbina un chiamante a un chiamato e inoltra le loro description e i loro candidati, TsgcWSPClient_RTCPeerConnection è il client corrispondente, e TsgcWSPServer_WebRTC fa lo stesso lavoro per i peer browser, inviando a ognuno la lista degli ICE server nel momento in cui entra.
Poiché il componente peer-connection e il server di signalling vivono nella stessa libreria, puoi mettere in piedi un'applicazione WebRTC completa — scoperta coordinata, NAT traversal, payload P2P cifrato — senza integrare un singolo SDK di terze parti.
NAT traversal
Configurazione dei server ICE
La stessa lista iceServers che usa un browser, esposta come RTCOptions.ICEServers — con sia server pubblici sia il tuo TURN privato.
uses
sgcP2P, sgcP2P_DataChannel;
// TFormPeer contiene FPeer, FChannel e FIncoming: TStringListprocedure TFormPeer.CreatePeer;
begin
FPeer := TsgcRTCPeerConnection.Create(nil);
FPeer.RTCOptions.ICEServers.AddURL('stun:stun.l.google.com:19302');
FPeer.RTCOptions.ICEServers.AddURL('turn:turn.example.com:3478',
'alice', 's3cret');
FPeer.OnLocalDescription := OnLocalDescription;
FPeer.OnIceCandidate := OnIceCandidate;
FPeer.OnDataChannel := OnDataChannel;
// lato uscita. CreateDataChannel attiva RTCOptions.DTLS
FChannel := FPeer.CreateDataChannel('chat');
FChannel.OnMessage := OnChannelMessage;
FPeer.CreateOffer;
end;
procedure TFormPeer.OnLocalDescription(Sender: TObject;
const aType, aSDP: string);
begin// aType è 'offer' oppure 'answer'
SignalToPeer(aType, aSDP);
end;
procedure TFormPeer.OnIceCandidate(Sender: TObject;
const aCandidate, aSdpMid: string; aSdpMLineIndex: Integer);
begin
SignalCandidate(aCandidate, aSdpMid, aSdpMLineIndex);
end;
procedure TFormPeer.OnDataChannel(Sender: TObject;
aChannel: TsgcRTCDataChannel);
begin
FChannel := aChannel;
FChannel.OnMessage := OnChannelMessage;
end;
procedure TFormPeer.OnChannelMessage(Sender: TObject;
const aText: string);
begin// si attiva su un worker thread, fai il marshal prima di toccare un controllo
FIncoming.Add(aText);
end;
// invia un messaggio peer to peer
FChannel.Send('Hello from Delphi');
Self-host
Esegui il tuo STUN / TURN in Delphi
La maggior parte dei team inizia con lo STUN pubblico di Google e un servizio TURN di terze parti (Twilio, Xirsys, coturn). Quando il traffico cresce, cresce anche la bolletta per la banda di relay — e TURN è, in pratica, l'unico pezzo di WebRTC in cui paghi al byte. La libreria ti consente il self-host: TsgcSTUNServer e TsgcTURNServer si inseriscono in un'applicazione console o in un servizio Windows e rispondono di default su UDP 3478, sulla porta e sull'indirizzo che metti in Bindings. Credenziali long-term, IPv4 e IPv6, un intervallo di porte di relay in TURNOptions.Allocation e una quota di allocazioni per utente sono tutti integrati.