TsgcWebTransportStream › Eigenschaften › Unidirectional
True, wenn der Stream Daten nur in eine Richtung transportiert, False, wenn beide Seiten schreiben können.
property Unidirectional: Boolean read FUnidirectional;Boolean (bool in C++Builder und C#).
Wird bei der Erstellung festgelegt. Für einen Stream, den Sie geöffnet haben, ist es das Argument aUnidirectional, das Sie an Session.OpenStream übergeben haben. Für einen vom Peer geöffneten Stream ist es das, was der Stream-Header des Peers angegeben hat: True nach einem 0x54-Header, False nach 0x41.
Schreibgeschützt. Die Richtung eines Streams wird beim Öffnen festgelegt und kann sich nicht ändern: QUIC kodiert sie in der Stream-ID selbst, und WebTransport kodiert sie erneut im Stream-Header. Wählen Sie sie über das Argument, das Sie an OpenStream übergeben.
| Value | Header | Wer schreiben darf | Geeignet für |
|---|---|---|---|
False (bidirektional) | varint(0x41) + varint(SessionId) | Beide Seiten | Anfrage und Antwort, Echo, jeder Austausch, bei dem Sie eine Antwort auf demselben Stream erwarten. |
True (unidirektional) | varint(0x54) + varint(SessionId) | Nur der eröffnende Peer | Fire-and-forget: Telemetrie, Log-Versand, Benachrichtigungen, unidirektionale Medien. |
Die Eigenschaft gilt pro Objekt, nicht pro Peer. Das ist die Feinheit, die man verinnerlichen sollte. Unidirectional = True auf einem Stream, den Sie geöffnet haben, bedeutet, dass Sie schreiben können und der Peer nicht. Dasselbe Flag auf einem Stream, den Sie über OnStream erhalten haben, bedeutet für Sie das Gegenteil: der Peer schreibt, und Ihre Kopie ist nur empfangend. Unidirectional allein sagt Ihnen also nicht, ob Sie schreiben dürfen; Sie müssen außerdem wissen, welche Seite ihn geöffnet hat. In der Praxis ist das einfach, denn die beiden Fälle kommen über unterschiedliche Wege an: Streams aus OpenStream sind Ihre zum Schreiben, Streams aus OnStream gehören dem Peer.
Das Schreiben auf das falsche Ende schlägt stillschweigend fehl. Der Aufruf von WriteData auf der empfangenden Seite eines unidirektionalen Streams löst keinen Fehler aus. Der HTTP/3-Client und -Server binden einen Writer pro Stream nur an vom Peer geöffnete bidirektionale Streams, daher behält ein vom Peer geöffneter unidirektionaler Stream den Fallback-Writer auf Sitzungsebene, und Ihre Bytes landen an einer nutzlosen Stelle. Sichern Sie den Echo-Pfad mit if not aStream.Unidirectional then ab, wie es die mitgelieferten Demos tun.
Beachten Sie, dass ein unidirektionaler Stream nicht effizienter ist als ein bidirektionaler. Verwenden Sie ihn, weil Ihre Daten tatsächlich nur in eine Richtung fließen, was die Absicht deutlich macht und dem Peer das Warten auf einen Antwortkanal erspart, der niemals etwas übertragen wird.
// Opening: the argument decides the direction
FBidi := FSession.OpenStream(False); // we can write, peer can answer
FBidi.OnData := OnStreamData;
FBidi.WriteData('request');
FTelemetry := FSession.OpenStream(True); // we can write, peer only reads
FTelemetry.WriteData('telemetry: started');
// Receiving: the flag says what the PEER opened, so check before answering
procedure TfrmServer.OnWTStream(Sender: TObject;
const aStream: TsgcWebTransportStream);
begin
aStream.OnData := OnWTStreamData;
if aStream.Unidirectional then
memoLog.Lines.Add('peer opened a receive-only stream; we cannot answer on it')
else
memoLog.Lines.Add('peer opened a bidi stream; we can echo on it');
end;
procedure TfrmServer.OnWTStreamData(Sender: TObject; const aData: TBytes);
var
oStream: TsgcWebTransportStream;
begin
oStream := TsgcWebTransportStream(Sender);
// Guard the echo: writing to a peer-opened unidirectional stream does
// nothing useful and reports no error
if not oStream.Unidirectional then
oStream.WriteData(aData);
end;