TsgcWebTransportSession › Ereignisse › OnWriteData
Transport-Hook. Der Fallback-Writer auf Sitzungsebene, der nur von Streams verwendet wird, die keinen eigenen Writer pro Stream besitzen.
property OnWriteData: TsgcWebTransportWriteEvent read FOnWriteData write FOnWriteData;
// event type
TsgcWebTransportWriteEvent = procedure(Sender: TObject;
const aData: TBytes) of object;
// handler signature
procedure MyWriteData(Sender: TObject; const aData: TBytes);| Name | Typ | Beschreibung |
|---|---|---|
Sender | TObject | Die TsgcWebTransportSession, die schreibt. Beachten Sie, dass dies die Sitzung ist und nicht der Stream, von dem die Bytes stammen: Diese Information wird nicht übergeben, was genau der Grund dafür ist, dass dieser Writer keinen bestimmten Stream ansprechen kann. |
aData | const TBytes | Die rohen Bytes, die auf die Verbindung geschrieben werden sollen, genau so, wie sie auf der Leitung erscheinen sollen. Ein etwaiger WebTransport-Stream-Header ist vom Aufrufer bereits enthalten. |
Bei einer nackten Sitzung nicht zugewiesen. Sowohl der HTTP/3-Client als auch der HTTP/3-Server weisen sie zu, bevor Sie die Sitzung sehen; der Client verweist damit auf den Standard-CONNECT-Stream der QUIC-Verbindung.
Weisen Sie dies nicht aus dem Anwendungscode zu. Es handelt sich um einen Transport-Hook, den der HTTP/3-Client und -Server bereits belegen. Er ist für Autoren eigener Transporte dokumentiert.
Es ist ein Fallback und wird im Normalbetrieb nie verwendet. Jeder Stream hat seinen eigenen Writer, TsgcWebTransportStream.OnWriteBytes. OpenStream startet einen neuen Stream auf einem sitzungsweiten Standard-Writer, der hierher weiterleitet, löst dann OnOpenStream aus, und der Transport ersetzt den Writer durch einen, der an einen echten QUIC-Stream gebunden ist. Ab diesem Zeitpunkt umgehen die Bytes des Streams OnWriteData vollständig. Es transportiert nur dann Daten, wenn ein Stream ohne streambezogenen Writer bleibt, was im ausgelieferten HTTP/3-Client und -Server bedeutet, dass der QUIC-Stream nicht geöffnet werden konnte.
Es kann keinen Stream adressieren, und das ist beabsichtigt. Der Handler erhält die Sitzung und ein Byte-Array, sonst nichts. Bytes aus beliebig vielen Streams treffen hier ununterscheidbar voneinander ein. Das bildet einen einzelnen multiplexten Transport-Stream ab, was als eingeschränkter Pfad in Ordnung ist, aber kein WebTransport ist: Echte Sitzungen benötigen jeden Stream auf einem eigenen QUIC-Stream, damit sie unabhängig und frei von Head-of-Line-Blocking bleiben. Betrachten Sie hier eintreffenden Datenverkehr als Zeichen dafür, dass ein Stream keinen eigenen QUIC-Stream erhalten hat.
Ein Handler sollte aData unverändert in die Verbindung schreiben. Fügen Sie kein Framing hinzu: Was die Sitzungs- oder Stream-Schicht benötigt hat, befindet sich bereits im Array.
Dieses Mitglied ist derzeit nur in der Delphi/C++Builder-Implementierung verfügbar. Die .NET-Klasse besitzt eine entsprechende Eigenschaft internal WriteDataHook, die aus Anwendungscode nicht zuweisbar ist. Sie wird dort etwas anders verwendet: Das verwaltete OpenStream bindet sie direkt als Writer des neuen Streams, wenn kein OpenStreamHook gesetzt ist, statt über einen Dispatcher auf Sitzungsebene zu leiten.
// What a custom QUIC transport assigns. This mirrors the library's own
// TsgcHTTP3Client_Base.DoWebTransportWriteData. Applications never do this.
procedure TMyTransport.WireSession(const aSession: TsgcWebTransportSession);
begin
aSession.OnOpenStream := DoOpenStream; // gives streams real writers
aSession.OnWriteData := DoWriteData; // fallback if that fails
aSession.OnSendDatagramData := DoSendDatagram;
end;
procedure TMyTransport.DoWriteData(Sender: TObject; const aData: TBytes);
begin
// Session-level fallback: no stream context is available here, so all we
// can do is put the bytes on the connection's default (CONNECT) stream.
GetQUICComponent.Write(FHost, FPort, aData);
end;