Telegram API Question posted in
A comprehensive official documentation can be found here.

Telegram API Layer54 C# – Questions

I’m trying to write a simple client for Telegram in C# exploiting their API layer 54.

I’m following the scheme here: https://github.com/telegramdesktop/tdesktop/blob/master/Telegram/SourceFiles/mtproto/scheme.tl

I’ve started by following the previous work made by Sochix: https://github.com/sochix/TLSharp, but this implementation refers to API Layer 23 and basically the parsing of nearly all the objects are different.

Now, since there is no documentation ( or at least I couldn’t find anything online ) about the layer 54 and the doc on the main site is not so good, I’ve a couple of questions:

1- Using the InitConnection method I specify through the “invokeWithLayer” request that I will use the Layer 54. Given that, I expect that all the following answers return objects respecting the code specified in the Layer 54 scheme, however sometimes happen that Telegram server answers me with object’s code of old API layer, somebody have an idea on why this happen?

2- Regarding the flagged objects such as User/Message etc…, I’ve found this old answer Handling "flags" types in telegram's TL schema language, but is there an official documentation on how to decode and encode this kind of objects? Moreover, following the answer proposed by Charles, shouldn’t be BAND(flags,1^2) == flags == true in order to check if a flagged field has been sent or not?

3- During the developing of such a library I’ve to make lots of tests in order to understand if my code works correctly or not, how can I avoid the “Too many requests” error? I’ve tried to reuse the session.dat created by TLSharp, but seems that it doesn’t work.

Thank you very much

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I will post answers here, maybe they will be useful in future to somebody:

    1) I've discovered that the problem was related to a wrong DC configured inside the Session.cs ( TLSharp library ).

    2) As Charles point out BinAND(flag,2^N) = 2^N.

    Example: when we read the flags: # field ( an int32 ) from an object we have:

    flag: 0000 0010 0001 0011

    if we want to know if the flag self:flags.10?true is setted or not we must test the bit 10 inside the flag int32, so:

    0000111000010011 &
0000010000000000 =
------------------
0000010000000000 -> FLAG SETTED!

    [WARNING] if the flag is setted and the type of the flag is ?true, you DON'T have to read the _true code from the binary stream, while if it is another type such as 'int' you are supposed to read its value from the stream.

    3) This error is automatically handled by the current implementation of the TLSharp library in the file MTProtoSender.cs. When you receive a "FLOOD_WAIT" error you have to wait for X second as the Telegram documentation report:

    FLOOD_WAIT_X: A wait of X seconds is required (where X is a number)

    After a sleep of X seconds you can return to make RPC to Telegram server. However, after lot of request X become around 20h, and this is a problem...


  2. 0

    Check newsest version of TLSharp, it supports layer 53. And have no problems with decoding.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search