telegram.org服务器返回的错误代码35是什么 [英] What is error code 35, returned by the telegram.org server

问题描述

我的客户似乎经常从电报服务器接收以下消息容器:

My client often receives the following message container from the telegram server, seemingly at random:

{'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 ，但是没有说明该错误代码的含义.到目前为止，我一直忽略它，但这不是一个好的长期解决方案恕我直言.知道该错误代码是什么意思吗?

You may notice: 'error code': 35 above, but there is no description of what that error code means. So far I have been ignoring it but that is not a good long term solution IMHO. Any ideas what that error code means?

推荐答案

与 bad_msg_seqno

There are a set of errors associated with bad_msg_seqno

来自文档:

在这里，error_code也可以采用以下值:

Here, error_code can also take on the following values:

1. msg_seqno太低(服务器 已经收到一条消息，该消息的msg_id较低，但其中一个 更高或相等且奇数的seqno)
2. msg_seqno太高(类似地， 消息的msg_id较高，但较低或 相等且奇数的seqno)
3. 甚至预期为msg_seqno(无关紧要 邮件)，但收到了奇怪的邮件
4. 预期msg_seqno多个(相关 消息)，但甚至收到了

1. msg_seqno too low (the server has already received a message with a lower msg_id but with either a higher or an equal and odd seqno)
2. msg_seqno too high (similarly, there is a message with a higher msg_id but with either a lower or an equal and odd seqno)
3. an even msg_seqno expected (irrelevant message), but odd received
4. odd msg_seqno expected (relevant message), but even received

正式定义:消息序列号码(msg_seqno)

一个32位数字，等于与内容相关"数字的两倍 消息(需要确认的消息，尤其是那些 不是由发件人在此消息之前创建的容器，并且 如果当前消息是 与内容有关的消息.容器总是在容器之后生成 全部内容；因此，其序号大于或 等于其中包含的消息的序列号.

a 32-bit number equal to twice the number of "content-related" messages (those requiring acknowledgment, and in particular those that are not containers) created by the sender prior to this message and subsequently incremented by one if the current message is a content-related message. A container is always generated after its entire contents; therefore, its sequence number is greater than or equal to the sequence numbers of the messages contained in it.

注释:

1. 每个新会话均从seq_no = 1->(0 * 2)+1开始
2. 您发送的每个序列号的计算方式为:(number_of_content_messages_已经_发送* 2)+ 1，因此您发送的所有序列号始终为奇数
3. 容器消息seq_no ==其内容消息的最大seq_no
4. 服务器将始终以正确的server_seq_no答复您，该正确的server_seq_no应该比到目前为止的 正确 最大seq_no大1.
5. 因此，一个好的检查/seq_no纠正方案将是使用最新收到的server_seq_no(应始终为偶数)来确认您的current-expected seq_no应该是什么，并根据需要进行调整.

1. Every new session starts from seq_no = 1 --> (0 * 2) + 1
2. Every sequence number you send is calculated as: (number_of_content_messages_ already_sent * 2) + 1 hence the all sequence numbers you send are always odd
3. A container messages seq_no == the max seq_no of its content messages
4. The server will always reply you with the correct server_seq_no which should be 1 greater than your correct max seq_no so far.
5. hence a good check / seq_no correction scheme would be to use the latest received server_seq_no (which should always be even) to confirm what your current-expected seq_no should be, and adjust as required.

以上技术对我来说是完全避免这些间歇性错误消息的工作.

The above technique has worked for me in avoiding these intermittent error messages completely.

这篇关于telegram.org服务器返回的错误代码35是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！