Skip to content

fix: preserve the sign of Telegram DC ids - #578

Open
AndreyOsipuk wants to merge 2 commits into
9seconds:masterfrom
AndreyOsipuk:fix/signed-dc-ids-upstream
Open

AndreyOsipuk wants to merge 2 commits into
9seconds:masterfrom
AndreyOsipuk:fix/signed-dc-ids-upstream

Conversation

@AndreyOsipuk

Copy link
Copy Markdown

A negative DC id in the client handshake is how Telegram clients ask for the media counterpart of a DC (-2 is DC 2 media). handshakeFrame.dc() turned it into a positive number, so media requests were proxied to the regular DC.

Changes:

  • handshakeFrame.dc() keeps the sign (0 still means the default DC);
  • doTelegramCall looks addresses up by the absolute DC number and passes the signed id to the server handshake; the unknown-DC fallback keeps the sign too;
  • tests: TestNegativeDC for the frame, the fuzz target accepts negative ids.

We have been running this in production since late July (through mtg-multi); media traffic shows up as dc="-2" etc. in the Prometheus metrics. The same change for mtg-multi: dolonet#43. go vet ./mtglib/... and go test ./mtglib/... pass.

A negative DC id in the client handshake is how Telegram clients ask for the
media counterpart of a DC (-2 is DC 2 media). handshakeFrame.dc() dropped the
sign, so media requests were proxied to the regular DC.

Keep the sign from the client frame through to the server handshake. DC
addresses are still looked up by the absolute DC number, and the unknown-DC
fallback keeps the sign as well.
The fuzz test asserted the old behaviour (a negative DC id loses its sign),
which is exactly what this change fixes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant