From 3d6a5334431bbbfc116b1d1241deb33213bacead Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Thu, 25 Jan 2024 17:03:51 +0000 Subject: [PATCH] Update content of files --- .../corefork.telegram.org/mtproto/mtproto-transports.html | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/data/web/corefork.telegram.org/mtproto/mtproto-transports.html b/data/web/corefork.telegram.org/mtproto/mtproto-transports.html index 40c65d79d1..e77876a765 100644 --- a/data/web/corefork.telegram.org/mtproto/mtproto-transports.html +++ b/data/web/corefork.telegram.org/mtproto/mtproto-transports.html @@ -154,6 +154,14 @@ Then, payloads are wrapped in the following envelope:

  • Payload: the MTProto payload
  • Padding: A random padding string of length 0-15
    • +

    Quick ACK ยป may be enabled for this transport.

    +

    To request a quick ACK from the server for an encrypted MTProto payload, add 0x80000000 to the len field before encoding it (equivalent to doing len = len | (1 << 31), i.e. set the most-significant bit of the length).

    +

    The server will send quick ACK tokens as a standalone 8 to 16-byte packet (excluding the length of the packet itself, encoded as usual), containing a 4-byte header with all bits set, followed by the ACK token (abcd), followed by 0 to 8 random padding bytes.

    +
    +----+----+----+----...----+
+|tlen|FFFF|abcd|  padding  |
++----+----+----+----...----+
    +

    These quick ACK packets can be easily distinguished from normal intermediate padded packets because their length will be always smaller than or equal to 16, smaller than any MTProto packet.
    +They can be distinguished from transport errors because the first 4 bytes of the payload are equal to 0xFFFFFFFF, not a valid transport error.

    Full

    The basic MTProto transport protocol