From 878054e54b5d263a67490c550c2f52b4c2b5f2ac Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Sun, 23 Jul 2023 12:02:07 +0000 Subject: [PATCH] Update content of files --- data/web/corefork.telegram.org/mtproto.html | 4 +- .../mtproto/samples-auth_key.html | 412 +++++++++--------- 2 files changed, 208 insertions(+), 208 deletions(-) diff --git a/data/web/corefork.telegram.org/mtproto.html b/data/web/corefork.telegram.org/mtproto.html index 714f9b724a..7c48d5c560 100644 --- a/data/web/corefork.telegram.org/mtproto.html +++ b/data/web/corefork.telegram.org/mtproto.html @@ -110,7 +110,7 @@ Client developers are required to comply with the described here for reference) is deprecated and is currently being phased out.

Brief Component Summary

-

High-Level Component (RPC Query Language/API)

+

High-Level Component (RPC Query Language/API)

From the standpoint of the high-level component, the client and the server exchange messages inside a session. The session is attached to the client device (the application, to be more exact) rather than a specific WebSocket/http/https/tcp connection. In addition, each session is attached to a user key ID by which authorization is actually accomplished.

Several connections to a server may be open; messages may be sent in either direction through any of the connections (a response to a query is not necessarily returned through the same connection that carried the original query, although most often, that is the case; however, in no case can a message be returned through a connection belonging to a different session). When the UDP protocol is used, a response might be returned by a different IP address than the one to which the query had been sent.

There are several types of messages:

@@ -167,7 +167,7 @@ Multiple transport protocols are defined:

Recap

To recap, using the ISO/OSI stack as comparison: