Eine native Pascal-Implementierung des WebRTC-Peer-to-Peer-Stacks: RTCPeerConnection, ICE-Candidate-Gathering und Connectivity Checks, STUN- und TURN-Client + -Server, DTLS-SRTP-Schlüsselvereinbarung und SCTP-Data-Channels — mit bereits verdrahteter WebSocket-Signalisierung.
Bring browserreifes P2P nach Delphi — ohne Chromium zu bundeln.
Eine Delphi-WebRTC-Bibliothek erlaubt es zwei Delphi-Prozessen (oder einem Delphi-Prozess und einem Browser), einen direkten, NAT-durchquerenden, Ende-zu-Ende-verschlüsselten Kanal aufzubauen, ohne den Payload über einen zentralen Server zu leiten. sgcWebSockets stellt jeden WebRTC-Baustein als Pascal-Komponente bereit: TsgcRTCPeerConnection spiegelt die W3C-API RTCPeerConnection, TsgcSTUNClient / TsgcSTUNServer implementieren RFC 8489, TsgcTURNClient / TsgcTURNServer implementieren RFC 8656, und TsgcICEClient, ein vollständiger ICE-Agent, verbindet sie.
Im Gegensatz zu browserbasierten Stacks (die Chromium oder libwebrtc erfordern — zig Megabyte nativen Codes plus komplizierter Build) ist die sgcWebSockets-Implementierung reines Pascal auf OpenSSL und wird direkt in deine Binary kompiliert. Sie läuft von Delphi 7 bis Delphi 13 und liefert native Binaries für Win32/Win64, Linux64, macOS, iOS und Android.
Eingebauter SDP-Serialisierer und -Parser. Generiere Offers, akzeptiere Answers, trickle ICE-Candidates in genau dem Wire-Format, das Chrome und Firefox erzeugen.
Eigenständiger STUN-Client und STUN-Server für NAT-Discovery und Keep-Alive. Betreibe deinen eigenen STUN-Endpunkt mit zwei Zeilen Pascal.
TURN-Client + -Server
TURN-Client für Relay-Allokation und TURN-Server zum Selbsthosten. Long-Term Credentials, IPv4 + IPv6.
DTLS-SRTP
Das verpflichtende Schlüsselvereinbarungsprotokoll für WebRTC. DTLS-1.2-Handshake über denselben ICE-ausgehandelten UDP-Pfad — mit Export des Keying Materials für SRTP.
SCTP-Data-Channels
Zuverlässige/unzuverlässige, geordnete/ungeordnete Nachrichten über den WebRTC-Media-Transport — der Standardweg, beliebige Anwendungsdaten peer-to-peer zu senden.
WebSocket-Signalisierung
Nutze die mitgelieferten TsgcWebSocketClient / TsgcWebSocketHTTPServer als Signalisierungskanal, oder das fertige Protokollpaar TsgcWSPClient_RTCPeerConnection und TsgcWSPServer_RTCPeerConnection. Eine Bibliothek für alles.
Signalisierung
WebSocket-Signalisierung: das Standardmuster
WebRTC definiert kein Signalisierungsprotokoll — das bringst du selbst mit. Die übliche Wahl ist ein WebSocket-Kanal, der drei Nachrichtentypen trägt: offer (SDP vom Anrufer), answer (SDP vom Angerufenen) und ice-candidate (Candidates, die von beiden Seiten getrickelt werden). sgcWebSockets enthält bereits beide Enden dieses Kanals. TsgcWSPServer_RTCPeerConnection paart einen Anrufer mit einem Angerufenen und leitet deren Descriptions und Candidates weiter, TsgcWSPClient_RTCPeerConnection ist der passende Client, und TsgcWSPServer_WebRTC erledigt dieselbe Aufgabe für Browser-Peers und schickt jedem beitretenden Peer die ICE-Server-Liste.
Weil Peer-Connection-Komponente und Signalisierungsserver in derselben Bibliothek leben, kannst du eine komplette WebRTC-Anwendung — koordinierte Discovery, NAT-Traversal, verschlüsselter P2P-Payload — aufziehen, ohne ein einziges Drittanbieter-SDK zu integrieren.
NAT-Traversal
ICE-Server konfigurieren
Dieselbe iceServers-Liste, die ein Browser verwendet, bereitgestellt als RTCOptions.ICEServers — mit öffentlichen Servern und deinem eigenen privaten TURN.
uses
sgcP2P, sgcP2P_DataChannel;
// TFormPeer enthält FPeer, FChannel und 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;
// ausgehende Seite. CreateDataChannel schaltet RTCOptions.DTLS ein
FChannel := FPeer.CreateDataChannel('chat');
FChannel.OnMessage := OnChannelMessage;
FPeer.CreateOffer;
end;
procedure TFormPeer.OnLocalDescription(Sender: TObject;
const aType, aSDP: string);
begin// aType ist 'offer' oder '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// wird in einem Worker-Thread ausgelöst, vor dem Zugriff auf ein Control synchronisieren
FIncoming.Add(aText);
end;
// eine Nachricht peer-to-peer senden
FChannel.Send('Hello from Delphi');
Self-Hosting
Eigenes STUN/TURN in Delphi betreiben
Die meisten Teams starten mit dem öffentlichen Google-STUN und einem TURN-Drittanbieterservice (Twilio, Xirsys, coturn). Wenn der Traffic wächst, wächst die Rechnung für die Relay-Bandbreite mit — und TURN ist in der Praxis das einzige Stück WebRTC, für das du pro Byte zahlst. Die Bibliothek erlaubt das Selbst-Hosting: TsgcSTUNServer und TsgcTURNServer fügen sich in eine Konsolen-Anwendung oder einen Windows-Dienst ein und antworten standardmäßig auf UDP 3478, auf jedem Port und jeder Adresse, die du in Bindings einträgst. Long-Term Credentials, IPv4 und IPv6, ein Relay-Portbereich in TURNOptions.Allocation und eine Allokationsquote pro Benutzer sind alle eingebaut.