У меня есть N входные потоки (очереди) и N соответствующие соединения. Поток планировщика сканирует входящие запросы, расставляет их приоритеты на основе некоторых критериев и отправляет их по соответствующим соединениям (запрос из очереди x переходит к соединению x). Аналогичная вещь происходит и на приемной стороне.
В традиционной настройке можно создать соединения с O_NONBLOCK. Если запись в соединение будет блокирована, оставьте запрос во входной очереди и повторно зайдите в очередь, чтобы поток планировщика не блокировался на одном медленном соединении.
Такое возможно с tokio::net::TcpStream, et c? Похоже, в прошлом было tokio::io::{TryRead, TryWrite}, которое было удалено.
Одним из вариантов может быть создание очереди на соединение для каждого соединения с выделенной задачей для каждой очереди. Это просто удаляет и делает write_all().await на соединении. Это создает еще один прыжок и добавляет сложности. Заставляет меня задуматься, является ли Токио правильным выбором для этого приложения.