TsgcWebTransportStream › Eigenschaften › StreamId
Die QUIC-Stream-Id, die diesem Stream zugrunde liegt. Der Transport setzt sie; Anwendungen lesen sie.
property StreamId: Int64 read FStreamId write FStreamId;Int64 (__int64 in C++Builder, long in C#).
-1 für einen von OpenStream erstellten Stream, bis der Transport die echte ID innerhalb von OnOpenStream einträgt. Ein vom Peer geöffneter Stream wird mit seiner echten ID erstellt und ist nie -1.
StreamId ist die ID, die QUIC dem darunterliegenden Stream zugewiesen hat. Der Hauptzweck im Anwendungscode ist die Korrelation: zu erkennen, von welchem Stream ein OnData- oder OnClose-Callback stammt, und einen Stream einem Log oder einer Paketaufzeichnung zuzuordnen.
In Delphi und C++Builder ist sie les- und schreibbar, aber schreiben Sie sie nicht. Der Setter existiert, damit der Transport die ID aus OnOpenStream eintragen kann, sobald der echte QUIC-Stream zugewiesen ist. Wenn Sie sie selbst zuweisen, verschiebt das den Stream nirgendwohin; es beschädigt nur die Sicht des Demultiplexers, sodass FindStreamById beginnt, den falschen oder gar keinen Stream zu treffen. Behandeln Sie sie als schreibgeschützt. In .NET ist sie tatsächlich schreibgeschützt.
Die Nummer lesen. QUIC packt zwei Bedeutungsbits an das untere Ende jeder Stream-ID: Bit 0 identifiziert den Öffner (0 = Client, 1 = Server), Bit 1 die Richtung (0 = bidirektional, 1 = unidirektional). Somit sind 0, 4, 8... vom Client geöffnete bidirektionale Streams, 1, 5, 9... vom Server geöffnete bidirektionale, 2, 6, 10... vom Client geöffnete unidirektionale und 3, 7, 11... vom Server geöffnete unidirektionale. IDs sind innerhalb einer QUIC-Verbindung eindeutig, nicht global, und stehen in keinem Zusammenhang mit IDs in einer anderen Verbindung.
Verwechseln Sie dies nicht mit Session.SessionId. Beide sind QUIC-Stream-IDs in derselben Verbindung, aber die Session-ID benennt den Extended-CONNECT-Stream, während diese einen Datenstream innerhalb der Sitzung benennt.
Eine StreamId von -1 bedeutet, dass nie ein QUIC-Stream gebunden wurde. Im ausgelieferten HTTP/3-Client und -Server geschieht das nur, wenn der QUIC-Stream nicht geöffnet werden konnte, sodass der Stream beim Fallback-Writer auf Sitzungsebene verbleibt. Es lohnt sich, dies nach OpenStream zu prüfen, wenn Sie sich auf die Id verlassen.
.NET-Unterschied, wissenswert. Auf dem verwalteten Stack erhält ein Stream, den Sie selbst geöffnet haben, eine synthetische ID: Die Sitzung vergibt einen Zähler ab SessionId, und der Transport-Hook ersetzt sie nicht durch die echte QUIC-Stream-ID. Vom Peer geöffnete Streams tragen auf beiden Stacks die echte QUIC-ID. Unter .NET stimmen IDs aus einer Paketaufzeichnung daher nur mit vom Peer geöffneten Streams überein, und die ID eines lokal geöffneten Streams ist ein lokales Handle. Die Bytes auf der Leitung sind identisch; nur der Wert, den Sie zurücklesen können, unterscheidet sich.
procedure TfrmClient.OnStreamData(Sender: TObject; const aData: TBytes);
var
oStream: TsgcWebTransportStream;
begin
// A single handler can serve many streams: StreamId says which one
oStream := TsgcWebTransportStream(Sender);
memoLog.Lines.Add(Format('stream %d: %s',
[oStream.StreamId, TEncoding.UTF8.GetString(aData)]));
end;
// Check the id after opening, when you depend on it
FStream := FSession.OpenStream(False);
if FStream.StreamId < 0 then
memoLog.Lines.Add('warning: no QUIC stream was bound to this stream')
else
memoLog.Lines.Add('bidi stream opened: id=' + IntToStr(FStream.StreamId));