Delphi-WebRTC-Bibliothek — P2P, ICE, STUN, TURN, DataChannel

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.

Peer-to-Peer für Pascal, Ende zu Ende

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.

Peer Connection

TsgcRTCPeerConnection

ICE / STUN / TURN

P2P-Komponenten

Standards

RFC 8825 / 8445 / 8489 / 8656 / 6347 / 4960 / 8831

Edition

Enterprise für die Komponenten, dazu das sgcWebRTC-Pack für Offer und Answer, DataChannels und Tracks. Beide sind in All-Access enthalten.

Jede WebRTC-Komponente freigegeben

Die Peer Connection ist die Headline, aber auch die unterstützenden Teile sind erstklassige Komponenten.

RTCPeerConnection

TsgcRTCPeerConnection spiegelt die W3C-API: CreateOffer, CreateAnswer, SetLocalDescription, SetRemoteDescription, AddIceCandidate, CreateDataChannel, AddTrack. Siehe RTCPeerConnection.

SDP-Offer / -Answer

Eingebauter SDP-Serialisierer und -Parser. Generiere Offers, akzeptiere Answers, trickle ICE-Candidates in genau dem Wire-Format, das Chrome und Firefox erzeugen.

ICE-Agent

Vollständiges Candidate-Gathering: host, server-reflexive (per STUN entdeckt), relayed (per TURN allokiert). Pairing, Priorisierung und Connectivity Checks gemäß RFC 8445. ICE-Seite.

STUN-Client + -Server

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.

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.

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: TStringList

procedure 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');

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.

Mehr zu P2P in sgcWebSockets

P2P-/WebRTC-Hub

Landing Page für jede Peer-to-Peer-Komponente.

RTCPeerConnection

Detaillierte Komponentenreferenz.

ICE-Agent

Candidate-Gathering und Connectivity Checks.

STUN & TURN

NAT-Discovery und Relay-Server.

Blog: RTCPeerConnection-P2P

End-to-End-Walkthrough eines Delphi-zu-Delphi-Data-Channels.

Blog: STUN- + TURN-Server & -Client

Eigene STUN/TURN-Infrastruktur in Delphi selbst hosten.

Blog: coturn unter Windows

Quervergleich mit der C-Referenzimplementierung für Interoperabilitätstests.

Bestes Preis-Leistungs-Verhältnis: All-AccessAlle eSeGeCe-Produkte, inklusive Premium-Support, ab €1,059 pro Jahr.
All-Access-Preise ansehen

Baue deinen ersten P2P-Kanal

Lade die Testversion — die WebRTC-, STUN- und TURN-Demos werden als kompilierbare Delphi-Projekte ausgeliefert.