cl2 and cl3 shoud work untill one node in cluster ready to serve requests.
Actual behaviour
cl3 do not connected (ifinite loop while connectiong)
Configuration
iOS: Telegram, Telegram X - BUG (always)
Android: Telegram - Ok, Telegram X - Bug (floating, depends dns round robin)
Desktop: Telegram - Ok
Details
Colleagues, I assume that the authors of the MTProto server work closely with the authors of the Telegram Client.
The problem at the junction. I will describe my case.
I own a large MTProto server farm, which I provide customers with the SaaS model.
Individual nodes are organized into clusters under a common DNS name.
It perfectly solves the problem of load balancing and address changes when locked.
But error handling by the client is terrible. If any (sic!, any) node in the cluster falls out, the client may stumble on it and go to infinite loop.
Instead of just like all modern network-based programs, it's easy to go through all the addresses under the same dns name and find the available one.
So we will not defeat the blockages!
I think the normalization of the search of available IP inside the cluster should become one of the priority tasks within the framework of the Digital Resistance movement.
I saw the change logs of the latest beta versions - it says about prioritizing the proxies for availability, but again there is nothing about sorting out IP addresses inside a single DNS name.
Ready for the most dense collaboration - to portray the test cases and the server for modeling, but the case seems to be extremely simple.
DNS Zone:
; BUG Support MTProto clusters in Telegram Client
; Testcase from https://t.me/iqdoctor
cl3 A 199.247.20.113; broken node
A 45.77.140.120
A 199.247.0.15
cl2 A 45.77.140.120
A 199.247.0.15
node-1.cl3 A 45.77.140.120
node-2.cl3 A 199.247.0.15
node-3.cl3 A 199.247.20.113; broken node
node-1.cl2 A 45.77.140.120
node-2.cl2 A 199.247.0.15
Steps to reproduce
Expected behaviour
cl2 and cl3 shoud work untill one node in cluster ready to serve requests.
Actual behaviour
cl3 do not connected (ifinite loop while connectiong)
Configuration
iOS: Telegram, Telegram X - BUG (always) Android: Telegram - Ok, Telegram X - Bug (floating, depends dns round robin) Desktop: Telegram - Ok
Details Colleagues, I assume that the authors of the MTProto server work closely with the authors of the Telegram Client.
The problem at the junction. I will describe my case.
I own a large MTProto server farm, which I provide customers with the SaaS model.
Individual nodes are organized into clusters under a common DNS name.
It perfectly solves the problem of load balancing and address changes when locked.
But error handling by the client is terrible. If any (sic!, any) node in the cluster falls out, the client may stumble on it and go to infinite loop.
Instead of just like all modern network-based programs, it's easy to go through all the addresses under the same dns name and find the available one.
So we will not defeat the blockages!
I think the normalization of the search of available IP inside the cluster should become one of the priority tasks within the framework of the Digital Resistance movement.
I saw the change logs of the latest beta versions - it says about prioritizing the proxies for availability, but again there is nothing about sorting out IP addresses inside a single DNS name.
Ready for the most dense collaboration - to portray the test cases and the server for modeling, but the case seems to be extremely simple.
DNS Zone:
; BUG Support MTProto clusters in Telegram Client ; Testcase from https://t.me/iqdoctor
cl3 A 199.247.20.113; broken node A 45.77.140.120 A 199.247.0.15
cl2 A 45.77.140.120 A 199.247.0.15
node-1.cl3 A 45.77.140.120 node-2.cl3 A 199.247.0.15 node-3.cl3 A 199.247.20.113; broken node
node-1.cl2 A 45.77.140.120 node-2.cl2 A 199.247.0.15
; https://t.me/proxy?server=cl2.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb ; Cluster Ok ; https://t.me/proxy?server=cl3.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb ; Cluster Broken sometimes (it depends from DNS round robin)
; cl-2 nodes check list ; https://t.me/proxy?server=node-1.cl2.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb ; https://t.me/proxy?server=node-2.cl2.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb
; cl-3 nodes check list ; https://t.me/proxy?server=node-1.cl3.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb ; https://t.me/proxy?server=node-2.cl3.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb ; https://t.me/proxy?server=node-3.cl3.drproxy.pro&port=1010&secret=dd03bd6926a81f6d2f1359f65f57eed4bb