Even if you're not supposed to use multiple threads with TLSharp,
it might be worth it to try to make this sequence increment in
a thread-safe way. Race conditions are always bad even if you know
you are not supposed to use something in a certain way...
@Laituex was having a ErrCode=32 'msg_seqno too low' problem and this
is the first thing we looked at (even if he swore that he was not
using different threads to access the telegram network)
Now user can set directory to store sessions somewhere else
other than the folder where the program's executable is.
(Based on patch from Felony <onyfel@gmail.com> contributed
in https://github.com/sochix/TLSharp/pull/874 )
People are reporting that under some circumstances, an infinite
loop could happen when TLSharp tries to handle a reconnection to
a different DC, if the DC instructed to be used is the same as
the one that was used in the last connection.
Not sure how could this happen (although the analysis present in
this github issue [1] might help understand it), but this commit
helps to make TLSharp fail fast (with an exception) instead of an
infinite loop from now on, which will help avoiding people file
issues such as [2] and [3] and instead maybe file a proper bug
report easier to understand, to try to fix the underlying root
cause.
[1] https://github.com/sochix/TLSharp/issues/719
[2] https://github.com/sochix/TLSharp/issues/803
[3] https://github.com/sochix/TLSharp/issues/839
Load() method in ISessionStore requires public constructor of class Session in some cases.
E.g., loading session from a db or a key-value store, manual loading from text-file, JSON/XML and so on.
