TsgcWebTransportStream › Methoden › ReceiveData

ReceiveData Methode

Schiebt eingehende Anwendungsbytes in den Stream und löst dabei OnData aus. Der Transport ruft dies auf; Anwendungen behandeln stattdessen das Ereignis.

Syntax

procedure ReceiveData(const aData: TBytes);

Parameter

Name	Typ	Beschreibung
aData	const TBytes	Rohe Anwendungsbytes, die unverändert an OnData übergeben werden. Der Aufrufer muss zuvor den WebTransport-Stream-Header entfernt haben: hier werden die Bytes weder geparst noch validiert.

Hinweise

Dies ist ein Transport-Integrationspunkt. ReceiveData ist das eingehende Gegenstück zu WriteData: Es löst OnData mit den Bytes aus, die Sie ihm übergeben, und tut sonst nichts. Kein Parsen von Headern, kein Puffern, keine Validierung. Anwendungscode sollte OnData behandeln, statt dies aufzurufen.

Sie erwartet ausschließlich Anwendungsbytes. Der Name sagt "receive", aber die Methode liest von nirgendwo. Es ist ein Push: Der Transport, der einen QUIC-Stream gelesen und ermittelt hat, zu welchem WebTransport-Stream die Bytes gehören, übergibt sie hier. Wenn Sie einen rohen QUIC-Lesevorgang übergeben, der vorn noch seinen 0x54- oder 0x41-Header trägt, wird dieser Header Ihrem Handler zugestellt, als wäre er Payload.

Der HTTP/3-Client und -Server rufen es auf zwei Pfaden auf, beide nachdem der Demultiplexer die Stream-ID aufgelöst hat:

• Continuation. Weitere Daten auf einer bereits bekannten Stream-ID sind per Definition rohe Anwendungsdaten, da der Header früher kam, sie gelangen also direkt hierher. Auf einem vom Client geöffneten bidirektionalen Stream ist dies der Echo-Pfad: Der Server antwortet auf demselben QUIC-Stream ohne Header.
• Nachlaufende Payload. Bytes, die im selben Lesevorgang wie der Header eines neuen Streams eingetroffen sind, werden hier unmittelbar geliefert, nachdem AddIncomingStream OnStream ausgelöst hat. Wegen dieser Reihenfolge ist es wichtig, OnData innerhalb von OnStream zuzuweisen: Tun Sie es später, sind diese Bytes bereits verloren.

Es gibt keine Prüfung auf einen geschlossenen Zustand, daher löst ReceiveData auch bei einem bereits geschlossenen Stream OnData aus. Ein leeres Array löst OnData mit einem leeren Array aus; die bibliothekseigenen Aufrufer vermeiden das, indem sie zuerst die Länge prüfen.

Wenn Sie es selbst aus dem Anwendungscode aufrufen, werden eingehende Daten simuliert: Der Handler läuft, aber es kam nichts aus dem Netzwerk. Nützlich, um einen Handler in einem Test auszuführen, überall sonst irreführend.

Dieses Member ist derzeit nur in der Delphi/C++Builder-Implementierung verfügbar. Die .NET-Klasse besitzt ein äquivalentes internal ReceiveData, das Anwendungscode nicht aufrufen kann.

Beispiel

// What a custom QUIC transport does once it knows which stream the bytes
// belong to. This mirrors the library's own routing in the HTTP/3 client
// and server; applications handle OnData instead.
function TMyTransport.RouteStreamData(aStreamId: Int64;
  const aData: TBytes): Boolean;
var
  oStream: TsgcWebTransportStream;
begin
  Result := False;
  if (aStreamId < 0) or (Length(aData) = 0) then
    Exit;

  // Known stream id: the header arrived earlier, so these bytes are raw
  // application data. Deliver them without parsing anything.
  oStream := FWebTransportSessions.FindStreamById(aStreamId);
  if Assigned(oStream) then
  begin
    oStream.ReceiveData(aData);   // raises OnData
    Result := True;
  end;
  // Unknown stream id: the bytes still carry the 0x54/0x41 + SessionId
  // header, so they must be parsed and routed through AddIncomingStream,
  // NOT pushed here.
end;

Zurück zu Methoden