updatesTooLong indicates that there are too many events pending to be pushed to the client, so one needs to fetch them manually.
Events inside updateShort constructors, normally, have lower priority and are broadcast to a large number of users, i.e. one of the chat participants started entering text in a big conversation (updateChatUserTyping).
The updateShortMessage, updateShortSentMessage and updateShortChatMessage constructors are redundant but help significantly reduce the transmitted message size for 90% of the updates. They should be transformed to updateShort upon receival.
-Two remaining constructors updates and updatesCombined are part of the Updates sequence. Both of them have the seq attribute, which indicates the remote Updates state after the generation of the Updates, and seq_start indicates the remote Updates state after the first of the Updates in the packet is generated. For updates, seq_start attribute is omitted, because it is assumed that it is always equal to seq.
Two remaining constructors updates and updatesCombined are part of the Updates sequence. Both of them have the seq attribute, which indicates the remote Updates state after the generation of the Updates, and seq_start indicates the remote Updates state after the first of the Updates in the packet is generated. For updates, the seq_start attribute is omitted, because it is assumed that it is always equal to seq.
Each event related to a message box (message created, message edited, message deleted, etc) is identified by a unique autoincremented pts, or qts in case of secret chat updates, certain bot updates, etc.
Each message box can be considered as some server-side DB table that stores messages and events associated with them.
@@ -88,7 +88,7 @@ Secret chats, certain bot events and other kinds of updates have yet another
The common update state is represented by the updates.State constructor.
-When the user logs in for the first time, call to updates.getState has to be made to store the latest update state (which will not be the absolute initial state, just the latest state at the current time).
+When the user logs in for the first time, a call to updates.getState has to be made to store the latest update state (which will not be the absolute initial state, just the latest state at the current time).
The common update state can also be fetched from updates.differenceTooLong. The channel update state is represented simply by the The secondary update state is represented by the Fetching state
pts of the event sequence: when first logging in, the initial channel state can be obtained from the dialog constructor when fetching dialogs, from the full channel info, or it can be received as an updateChannelTooLong update.qts of the secret event sequence, it is contained in the updates.State of the common update state.
pts: checking and applyingHere, local_pts will be the local state, pts will be the remote state, pts_count will be the number of events in the update.
If local_pts + pts_count === pts, the update can be applied.
-If local_pts + pts_count > pts, the update was already applied, and must be ignored.
-If local_pts + pts_count < pts, there's an update gap that must be filled.
local_pts + pts_count === pts, the update can be applied.local_pts + pts_count > pts, the update was already applied, and must be ignored.local_pts + pts_count < pts, there's an update gap that must be filled.For example, let's assume the client has the following local state for the channel 123456789:
local_pts = 131Now let's assume an updateNewChannelMessage from channel 123456789 is received with pts = 132 and pts_count=1.
@@ -118,12 +120,15 @@ Since local_pts + pts_count > pts (133 > 132), t
Now let's assume an updateDeleteChannelMessages from channel 123456789 is received with pts = 140 and pts_count=5.
Since local_pts + pts_count < pts (137 < 140), this means that updates were missed, and the gap must be recovered.
The whole process is very similar for secret chats and certain bot updates, but there is qts instead of pts, and events are never grouped, so it's assumed that qts_count is always equal to 1.
The whole process is very similar for secret chats and certain bot updates, but there is a qts instead of pts, and events are never grouped, so it's assumed that qts_count is always equal to 1.
seq: checking and applyingOn top level when handling received updates and updatesCombined there are three possible cases:
-If local_seq + 1 === seq_start, the updates can be applied.
-If local_seq + 1 > seq_start, the updates were already applied, and must be ignored.
-If local_seq + 1 < seq_start, there's an updates gap that must be filled (updates.getDifference must be used as with common and secret event sequences).
On the top level when handling received updates and updatesCombined there are four possible cases:
+seq_start === 0, the updates can be applied: this is a special case for updates that aren't ordered and should just be applied immediately.local_seq + 1 === seq_start, the updates can be applied.local_seq + 1 > seq_start, the updates were already applied, and must be ignored.local_seq + 1 < seq_start, there's an updates gap that must be filled (updates.getDifference must be used as with common and secret event sequences).If the updates were applied, local Updates state must be updated with seq and date from the constructor.
For all the other Updates type constructors there is no need to check seq or change a local state.