skip to Main Content

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}]})

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?

2

Answers


  1. As Telegram API docs says, error with code 35 is “odd msg_seqno expected (relevant message), but even received”

    Login or Signup to reply.
  2. There are a set of errors associated with bad_msg_seqno

    From the documentation:

    Here, error_code can also take on the following values:

    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

    Formal Definition: Message Sequence Number (msg_seqno)

    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.

    Notes:

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search