Skip to main content

Crate ferogram_mtsender

Crate ferogram_mtsender 

Source
Expand description

MTProto sender pool and retry policy for ferogram.

This crate is part of ferogram, an async Rust MTProto client built by Ankit Chaubey.

Most users do not need this crate directly. The ferogram crate wraps everything. Use ferogram-mtsender only if you are building a custom dispatch layer or need direct access to the DC connection pool.

§What’s in here

  • MtpSender: Single-task MTProto sender. All TCP I/O (read, write, ping) runs inside one Tokio task that owns the unsplit TcpStream. Callers enqueue request bodies via MtpSender::enqueue and receive results through a oneshot channel. This design eliminates mutex contention between reader and writer halves and ensures ACKs are flushed on every outgoing frame.
  • DcPool: Per-DC connection pool capped at three slots. Requests are round-robined across live ConnSlots. The pool opens new connections on demand and replaces slots that have faulted.
  • DcConnection: One encrypted connection to a single DC. Handles pending msgs_ack accumulation and issues ping_delay_disconnect to keep the socket alive inside Telegram’s 75-second idle window.
  • RetryPolicy / RetryLoop: Trait and executor for retry behaviour on RPC failures. AutoSleep sleeps through FLOOD_WAIT errors; NoRetries returns the error immediately. Implement the trait to add exponential back-off or a circuit breaker.
  • CircuitBreaker: Stops issuing requests to a DC that has failed repeatedly, giving the pool time to reconnect before hammering the server.
  • spawn_sender_task / SenderHandle: Spawns the background I/O loop and returns a handle for enqueuing RPCs, subscribing to FrameEvents (updates), and issuing ReconnectRequests.
  • InvocationError / RpcError: Typed errors for failed RPC calls, including flood waits, server errors, and transport failures.

§Example: send an RPC via the pool

use ferogram_mtsender::{DcPool, InvocationError};
use ferogram_connect::TransportKind;
use ferogram_session::DcEntry;
use ferogram_tl_types::functions::help::GetConfig;

let dc_entries: Vec<DcEntry> = vec![]; // populate from your session
let mut pool = DcPool::new(2, &dc_entries, None, TransportKind::Full);
let raw = pool.invoke_on_dc(2, &dc_entries, &GetConfig {}).await?;
println!("raw response bytes: {}", raw.len());

Re-exports§

pub use mtp_sender::MtpSender;
pub use sender_task::FrameEvent;
pub use sender_task::ReconnectRequest;
pub use sender_task::RpcEnqueue;
pub use sender_task::SenderHandle;
pub use sender_task::spawn_sender_task;

Modules§

mtp_sender
Single-task MTProto sender.
sender_task
The sender task: a single tokio::spawn-ed loop that owns MtpSender and is the only entity that touches the TCP socket.

Structs§

AutoSleep
Automatically sleep on FLOOD_WAIT and retry once on transient I/O errors.
CircuitBreaker
A RetryPolicy that stops retrying after threshold consecutive failures and stays silent for a cooldown window before resetting.
ConnSlot
One slot in the per-DC connection pool.
DcConnection
DcPool
Pool of per-DC authenticated connections. Each DC holds up to MAX_CONNS_PER_DC slots. The pool lock is dropped before any network I/O so concurrent callers don’t serialize on it.
NoRetries
Never retry: propagate every error immediately.
RetryContext
Context passed to RetryPolicy::should_retry on each failure.
RetryLoop
Drives the retry loop for a single RPC call.
RpcError
An error returned by Telegram’s servers in response to an RPC call.

Enums§

InvocationError
The error type returned from any Client method that talks to Telegram.

Traits§

RetryPolicy
Controls how the client reacts when an RPC call fails.