Currently, MTProto session state (including sequence numbers, message queues, and salt management) is stored in-memory within the session service (app/interface/session). This architecture creates a strong coupling between a client connection and a specific service instance.
If a session service node restarts (during maintenance, auto-scaling, or failure), all associated client sessions are interrupted, often requiring a protocol-level re-handshake or resulting in sequence number mismatches until the client resynchronizes.
Proposed Improvement
Transition to a stateless session architecture by offloading ephemeral session state to a distributed high-performance store (e.g., a Redis Cluster).
Key Components:
- Distributed State Store: Move
nextSeqNo, firstMsgId, and message queues from app/interface/session/internal/sess/session.go to Redis.
- Consistent Hashing / Any-Node Processing: Modify
gnetway (app/interface/gnetway) or the internal routing logic to allow any session node to handle a request for a given session_id by fetching the current state from the distributed store.
- Session Handoff Logic: Implement a "lock-and-fetch" or "optimistic concurrency" mechanism to ensure that two nodes don't process messages for the same
session_id simultaneously in a way that corrupts the sequence numbers.
Benefits
- Zero-Downtime Updates: Perform rolling updates of the
session service without disconnecting users or breaking MTProto state.
- Horizontal Elasticity: Seamlessly scale the
session layer based on real-time load.
- Improved UX: Users remain "online" and their message delivery remains uninterrupted even during backend infrastructure changes.
Compatibility
This change is strictly server-side and maintains 100% compatibility with the standard MTProto 2.0 protocol. No client-side changes are required.
Currently, MTProto session state (including sequence numbers, message queues, and salt management) is stored in-memory within the session service (
app/interface/session). This architecture creates a strong coupling between a client connection and a specific service instance.If a
sessionservice node restarts (during maintenance, auto-scaling, or failure), all associated client sessions are interrupted, often requiring a protocol-level re-handshake or resulting in sequence number mismatches until the client resynchronizes.Proposed Improvement
Transition to a stateless session architecture by offloading ephemeral session state to a distributed high-performance store (e.g., a Redis Cluster).
Key Components:
nextSeqNo,firstMsgId, and message queues fromapp/interface/session/internal/sess/session.goto Redis.gnetway(app/interface/gnetway) or the internal routing logic to allow anysessionnode to handle a request for a givensession_idby fetching the current state from the distributed store.session_idsimultaneously in a way that corrupts the sequence numbers.Benefits
sessionservice without disconnecting users or breaking MTProto state.sessionlayer based on real-time load.Compatibility
This change is strictly server-side and maintains 100% compatibility with the standard MTProto 2.0 protocol. No client-side changes are required.