mirror of
https://github.com/MarshalX/telegram-crawler.git
synced 2024-12-13 02:11:00 +01:00
151 lines
12 KiB
HTML
151 lines
12 KiB
HTML
|
<!DOCTYPE html>
|
|||
|
|
<html class="">
|
|||
|
|
<head>
|
|||
|
|
<meta charset="utf-8">
|
|||
|
|
<title>Client-Side Optimization</title>
|
|||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|||
|
|
<meta property="description" content="Ways to boost API interactions.">
|
|||
|
|
<meta property="og:title" content="Client-Side Optimization">
|
|||
|
|
<meta property="og:image" content="cc8d9aa19196b9a2dd">
|
|||
|
|
<meta property="og:description" content="Ways to boost API interactions.">
|
|||
|
|
<link rel="shortcut icon" href="/favicon.ico?4" type="image/x-icon" />
|
|||
|
|
|
|||
|
|
<link href="/css/bootstrap.min.css?3" rel="stylesheet">
|
|||
|
|
|
|||
|
|
<link href="/css/telegram.css?214" rel="stylesheet" media="screen">
|
|||
|
|
<style>
|
|||
|
|
</style>
|
|||
|
|
</head>
|
|||
|
|
<body class="preload">
|
|||
|
|
<div class="dev_page_wrap">
|
|||
|
|
<div class="dev_page_head navbar navbar-static-top navbar-tg">
|
|||
|
|
<div class="navbar-inner">
|
|||
|
|
<div class="container clearfix">
|
|||
|
|
<ul class="nav navbar-nav navbar-right hidden-xs"><li class="navbar-twitter"><a href="https://twitter.com/telegram" target="_blank" data-track="Follow/Twitter" onclick="trackDlClick(this, event)"><i class="icon icon-twitter"></i><span> Twitter</span></a></li></ul>
|
|||
|
|
<ul class="nav navbar-nav">
|
|||
|
|
<li><a href="//telegram.org/">Home</a></li>
|
|||
|
|
<li class="hidden-xs"><a href="//telegram.org/faq">FAQ</a></li>
|
|||
|
|
<li class="hidden-xs"><a href="//telegram.org/apps">Apps</a></li>
|
|||
|
|
<li class="active"><a href="/api">API</a></li>
|
|||
|
|
<li class=""><a href="/mtproto">Protocol</a></li>
|
|||
|
|
<li class=""><a href="/schema">Schema</a></li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div class="container clearfix">
|
|||
|
|
<div class="dev_page">
|
|||
|
|
<div id="dev_page_content_wrap" class=" ">
|
|||
|
|
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/api/optimisation" >Client-Side Optimization</a></li></ul></div>
|
|||
|
|
<h1 id="dev_page_title">Client-Side Optimization</h1>
|
|||
|
|
|
|||
|
|
<div id="dev_page_content"><h3><a class="anchor" href="#simplified-acknowledgment-of-message-delivery" id="simplified-acknowledgment-of-message-delivery" name="simplified-acknowledgment-of-message-delivery"><i class="anchor-icon"></i></a>Simplified Acknowledgment of Message Delivery</h3>
|
|||
|
|
<p>An outgoing message may be considered sent once the server has assigned it an identifier. Normally, a client would learn of this from the result of the <a href="/method/messages.sendMessage">messages.sendMessage</a> method.
|
|||
|
|
The MTProto server provides a mechanism for <a href="/mtproto/mtproto-transports#quick-ack">“quick acknowledgments"</a>. Upon receiving such an acknowledgment, the client may be certain that the call to the send message method has at least been fully received by the server and placed in a processing queue, and can inform the user that the delivery was successful.
|
|||
|
|
It is possible that the server’s actual response will never be received by the client (an interrupted connection; or the app restarts at exactly the wrong time). To correctly handle these situations, you can use a special type of notification generated by the server when <a href="/method/updates.getDifference">updates.getDifference</a> is called: <a href="/constructor/updateMessageID">updateMessageID</a>. When processing this notification, the client can use the <strong>random_id</strong> identifier to associate the previously transmitted message with the one delivered to the server.
|
|||
|
|
If such a notification is not issued when <a href="/method/updates.getDifference">updates.getDifference</a> is called for one of the previously sent messages, the message must be marked as undelivered.</p>
|
|||
|
|
<h3><a class="anchor" href="#server-salt" id="server-salt" name="server-salt"><i class="anchor-icon"></i></a>Server Salt</h3>
|
|||
|
|
<p>Server salt is a 64-bit number added to every outgoing and incoming message. At present, a single salt’s lifespan is 1 hour, following which it is considered invalid and the server will return an error for all the messages that contain it. The error message will contain the correct salt, which may be immediately used for sending. Given this approach, there will always be a period of waiting before the client receives a new salt if it connects to the server less frequently than once an hour.
|
|||
|
|
For improved performance, there is a special <a href="/mtproto/service_messages#request-for-several-future-salts">get_future_salts</a> method, which fetches in advance a list of the salts that will be valid during the course of a specified period of time following the call (1 day, for example). A start time and an end time are specified for each salt. The salts overlap one another by half an hour. We recommend always using the record with the longest remaining lifespan.</p>
|
|||
|
|
<h3><a class="anchor" href="#downloading-files-and-uploading-data-to-the-server" id="downloading-files-and-uploading-data-to-the-server" name="downloading-files-and-uploading-data-to-the-server"><i class="anchor-icon"></i></a>Downloading Files and Uploading Data to the Server</h3>
|
|||
|
|
<p>We recommend that separate connections and sessions be created for these tasks. Remember that the extra sessions must be deleted when no longer needed.
|
|||
|
|
It makes sense to download files over several connections (optimally to have a pool). When uploading data to a server one connection is enough to achieve the best results.</p>
|
|||
|
|
<p>The file handling API is designed to perform data operations in parts. In its simplest implementation, the process of uploading files to a server looks like this: send a query, wait for a response, send the next query, etc. This approach does not optimize the use of network resources and the ping time has a huge effect.
|
|||
|
|
The upload and download process is optimal when two or more queries are continuously being executed through one connection. In this arrangement, uploading to the server would look like this:</p>
|
|||
|
|
<ol>
|
|||
|
|
<li>Send Query 1</li>
|
|||
|
|
<li>Send Query 2</li>
|
|||
|
|
<li>Wait for a response to Query 1</li>
|
|||
|
|
<li>Send Query 3</li>
|
|||
|
|
<li>Wait for a response to Query 2</li>
|
|||
|
|
<li>Send Query 4</li>
|
|||
|
|
<li>etc.</li>
|
|||
|
|
</ol>
|
|||
|
|
<p>This will help reduce the effect of ping latency and maximize the channel workload.</p>
|
|||
|
|
<h3><a class="anchor" href="#sending-messages-in-bulk" id="sending-messages-in-bulk" name="sending-messages-in-bulk"><i class="anchor-icon"></i></a>Sending Messages in Bulk</h3>
|
|||
|
|
<p>Sometimes a client needs to transmit several send message method calls to the server all at once in a single message or in several consecutive messages. However, the server may execute these requests out of order (queries are handled by different servers to improve performance, which introduces a degree of randomness to the process).
|
|||
|
|
This requires that dependencies be explicitly stated when processing queries by using the function</p>
|
|||
|
|
<pre><code>invokeAfterMsg#cb9f372d {X:Type} msg_id:long query:!X = X;</code></pre>
|
|||
|
|
<p>Actually, this means padding the beginning of the query with the 32-bit number <code>0xcb9f372d</code> and the 64-bit message identifier of the query on which the current query is dependent.</p>
|
|||
|
|
<h3><a class="anchor" href="#grouping-updates" id="grouping-updates" name="grouping-updates"><i class="anchor-icon"></i></a>Grouping Updates</h3>
|
|||
|
|
<p>Generating updates (notifications about various server events) and delivering them to the client form two different parts of the system (respectively, the messenger API and MTProto). By itself, MTProto cannot modify in any way the data transmitted to the client, and the server API cannot respond to client-MTProto connection events.
|
|||
|
|
Imagine the situation where a client loses its connection (or is intentionally disconnected from the network) for some time. If lots of different events occur before a new connection is established (contacts come online, typing event messages are sent), then when a connection is established the client will receive lots of data containing all of the intervening events, despite the fact that most of the data is obsolete.
|
|||
|
|
The grouping of messages has been introduced to optimize such situations. If new events occur and the client has not managed to “collect” the previously generated updates, then the server API can combine them into a single package.</p>
|
|||
|
|
<p>A client is able to control when the MTProto server begins to consider that the connection has been lost and grouping can begin (the earlier this occurs when there is no connection, the better for the client). This functionality is implemented through a special type of Ping message, <a href="/mtproto/service_messages#deferred-connection-closure-ping">ping_delay_disconnect</a>, which specifies a time delay following which the server will close the current connection and start grouping messages. </p>
|
|||
|
|
<p>It makes sense to combine the transmission of <a href="/mtproto/service_messages#deferred-connection-closure-ping">ping_delay_disconnect</a> with that of other recurring tasks, such as updating the user status (<a href="/method/account.updateStatus">account.updateStatus</a>).</p>
|
|||
|
|
<h3><a class="anchor" href="#setting-the-typing-status" id="setting-the-typing-status" name="setting-the-typing-status"><i class="anchor-icon"></i></a>Setting the Typing Status</h3>
|
|||
|
|
<p>If a contact is not online, there is no need to invoke <a href="/method/messages.setTyping">messages.setTyping</a>.</p></div>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_wrap">
|
|||
|
|
<div class="footer_columns_wrap footer_desktop">
|
|||
|
|
<div class="footer_column footer_column_telegram">
|
|||
|
|
<h5>Telegram</h5>
|
|||
|
|
<div class="footer_telegram_description"></div>
|
|||
|
|
Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed.
|
|||
|
|
</div>
|
|||
|
|
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="//telegram.org/faq">About</a></h5>
|
|||
|
|
<ul>
|
|||
|
|
<li><a href="//telegram.org/faq">FAQ</a></li>
|
|||
|
|
<li><a href="//telegram.org/blog">Blog</a></li>
|
|||
|
|
<li><a href="//telegram.org/jobs">Jobs</a></li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="//telegram.org/apps#mobile-apps">Mobile Apps</a></h5>
|
|||
|
|
<ul>
|
|||
|
|
<li><a href="//telegram.org/dl/ios">iPhone/iPad</a></li>
|
|||
|
|
<li><a href="//telegram.org/dl/android">Android</a></li>
|
|||
|
|
<li><a href="//telegram.org/dl/wp">Windows Phone</a></li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="//telegram.org/apps#desktop-apps">Desktop Apps</a></h5>
|
|||
|
|
<ul>
|
|||
|
|
<li><a href="//desktop.telegram.org/">PC/Mac/Linux</a></li>
|
|||
|
|
<li><a href="//macos.telegram.org/">macOS</a></li>
|
|||
|
|
<li><a href="//telegram.org/dl/web">Web-browser</a></li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column footer_column_platform">
|
|||
|
|
<h5><a href="/">Platform</a></h5>
|
|||
|
|
<ul>
|
|||
|
|
<li><a href="/api">API</a></li>
|
|||
|
|
<li><a href="//translations.telegram.org/">Translations</a></li>
|
|||
|
|
<li><a href="//instantview.telegram.org/">Instant View</a></li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_columns_wrap footer_mobile">
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="//telegram.org/faq">About</a></h5>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="//telegram.org/blog">Blog</a></h5>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="//telegram.org/apps">Apps</a></h5>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="/">Platform</a></h5>
|
|||
|
|
</div>
|
|||
|
|
<div class="footer_column">
|
|||
|
|
<h5><a href="https://twitter.com/telegram" target="_blank" data-track="Follow/Twitter" onclick="trackDlClick(this, event)">Twitter</a></h5>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<script src="/js/main.js?42"></script>
|
|||
|
|
|
|||
|
|
<script>backToTopInit("Go up");
|
|||
|
|
removePreloadInit();
|
|||
|
|
</script>
|
|||
|
|
</body>
|
|||
|
|
</html>
|
|||
|
|
|