什麼是錯誤代碼35，由telegram.org服務器返回

我的客戶經常接到電報服務器的以下消息容器，看似隨意：什麼是錯誤代碼35，由telegram.org服務器返回

{'MessageContainer': [{'msg': {u'bad_msg_notification': {u'bad_msg_seqno': 4, u'bad_msg_id': 6330589643093583872L, u'error_code': 35}}, 'seqno': 4, 'msg_id': 6330589645303624705L}, {'msg': {u'msgs_ack': {u'msg_ids': [6330589643093583872L]}}, 'seqno': 4, 'msg_id': 6330589645303639041L}]})

您可能會注意到：「錯誤代碼」：上面提到了35，但沒有描述錯誤代碼的含義。到目前爲止，我一直忽略它，但這不是一個好的長期解決方案恕我直言。任何想法是什麼錯誤代碼的意思？

來源

2016-09-15 Kenny Cason

你有沒有找到適合的解決方案？ –

如果發送MsgsAck解決了這個問題，那麼是的。我現在正在實施。我會讓你知道，如果這是訣竅。 –

與'bad_msg_seqno'相關的錯誤只是與從您的末端錯誤計算msg_sequence數字有關 –

存在與bad_msg_seqno

相關聯從一組誤差文檔：

在這裏，error_code也可以取下列值：

msg_seqno太低（服務器已經接收的消息具有較低MSG_ID但無論是更高或相等的和奇數的SeqNo）

msg_seqno過高（類似地，存在具有更高MSG_ID但無論是較低或相等且奇數的SeqNo的消息）

偶數msg_seqno預期（無關消息），但奇數接收

奇數msg_seqno預期（相關消息），但即使收到

形式化定義：Message Sequence Number (msg_seqno)

一個32位的數等於「內容相關的」消息數的兩倍（那些需要確認，並且特別是那些是而不是容器），如果當前消息是內容相關消息，則由發送者在此消息之前創建，並且隨後遞增1。一個容器始終在其全部內容後生成;因此，其序列號大於或等於其中包含的消息的序列號。

注：

每一個新的會話從seq_no = 1開始 - >（0 * 2）+ 1
計算每個發出的序列號爲：（number_of_content_messages_ already_sent * 2）+ 1因此您發送的所有序列號始終爲奇數
容器消息seq_no ==其內容消息的最大seq_no
服務器將始終回覆您正確的server_seq_no應該是1大於您的正確 max seq_no到目前爲止。
因此，一個很好的check/seq_no更正方案是使用最新收到的server_seq_no（應該始終是偶數）來確認您的current-expected seq_no應該是什麼，並根據需要進行調整。

上述技術對我來說完全避免了這些間歇性錯誤消息。

來源

2016-09-28 19:03:22

如何通過編程方式知道消息是「內容消息」？例如，用於創建身份驗證密鑰的方法不是內容消息（據我瞭解），但似乎使它們在編程上唯一的唯一東西是它們以未加密方式發送，因爲身份驗證密鑰需要進行加密。還有什麼區別內容與非內容？例如，「MsgAcks」是否考慮了內容消息？ –

最佳經驗法則：查看文檔：構成**主應用程序API **的一部分的任何內容都是內容https://raw.githubusercontent.com/telegramdesktop/tdesktop/master/Telegram/SourceFiles/mtproto/scheme.tl –

我很害怕這樣，客戶無法「看文檔」。似乎唯一的答案是硬編碼非內容消息的列表，這可能是有問題的，因爲API模式受到層更新的影響。 –

作爲Telegram API docs說，與代碼35的錯誤是「奇數msg_seqno預期（相關信息），但即使接收到的」

來源

2016-09-15 16:34:53 Yardanico

謝謝，我沒有看到那個頁面。你能解釋一下如何處理這些消息嗎？從文檔來看，我不清楚這種情況是怎麼發生的以及它的後果。 –

此外，文檔狀態消息必須被確認。這是否意味着我需要確認回服務器？如果是這樣，用什麼方法來實現呢？ –

你可以向你發送你的下一個請求，或積累你的acks然後在一段時間後發送 –

什麼是錯誤代碼35，由telegram.org服務器返回

回答

相關問題