问题描述
我的客户端经常从电报服务器收到以下消息容器,似乎是随机的:
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}]})
您可能会注意到:'error code': 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 还可以采用以下值:
- msg_seqno 太低(服务器已经收到一条消息,其 msg_id 较低,但有一个更高或相等且奇数的 seqno)
- msg_seqno 太高(同样,有一条消息具有较高的 msg_id 但具有较低或一个相等和奇数的序列号)
- 预期的偶数 msg_seqno(不相关消息),但收到奇数
- 期望的奇数 msg_seqno(相关消息),但即使收到
正式定义: 消息序列编号 (msg_seqno)
一个 32 位数字,等于内容相关"数量的两倍消息(需要确认的消息,尤其是那些需要确认的消息)不是容器)由发件人在此消息之前创建并且如果当前消息是一个,则随后加一内容相关的消息.容器总是在它之后生成全部内容;因此,它的序列号大于或等于其中包含的消息的序列号.
注意事项:
- 每个新会话从 seq_no = 1 --> (0 * 2) + 1 开始
- 您发送的每个序列号的计算方式为:(number_of_content_messages_ already_sent * 2) + 1 因此您发送的所有序列号总是奇数
- 容器消息 seq_no == 其内容消息的最大 seq_no
- 服务器将始终以正确的
server_seq_no
回复您,该server_seq_no
应该比您的正确最大seq_no大1. - 因此,一个好的检查/seq_no 校正方案是使用最新收到的
server_seq_no
(应该始终是偶数)来确认您的current-expected
seq_no 应该是什么,并根据需要进行调整.
- Every new session starts from seq_no = 1 --> (0 * 2) + 1
- 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
- A container messages seq_no == the max seq_no of its content messages
- 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. - 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 yourcurrent-expected
seq_no should be, and adjust as required.
上述技术对我来说完全避免了这些间歇性错误消息.
The above technique has worked for me in avoiding these intermittent error messages completely.
这篇关于什么是错误代码 35,由telegram.org 服务器返回的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!