К сожалению.Я думаю, что я, возможно, ответил на ваш вопрос в другом потоке и заставил вас поверить, что поддержка управления потоком UDP в Twisted немного более надежна, чем на самом деле.Тем не менее, вы можете получить то, что вам нужно сделать ...
1.Какой метод будет вызывать Twisted после того, как сокет станет доступным для записи?
К сожалению, протоколы UDP в Twisted не контролируются на доступность для записи, исходя из того, что UDP всегда может завершиться ошибкой и поэтому он никогда не должен повышать EWOULDBLOCK.(За исключением фактического, иногда это происходит, и это ошибка в Twisted , которую я только что обнаружил, отвечая на этот вопрос. Это происходит только в том случае, если Twisted отправляет UDP с большей скоростью, чем локальная скорость передачи, что требуеточень быстрое приложение и очень медленная сеть.)
В качестве обходного пути ваше приложение может просто перехватить EWOULDBLOCK.Для любого другого протокола этот тип обходного пути может представлять серьезную проблему, но в случае UDP вы уже должны быть готовы к потере любых исходящих пакетов, поэтому вам все равно нужен механизм потока внутриполосного управления.
Помогите нам получить эту ошибку в процессе рассмотрения тоже всегда есть вариант.
Если вы хотите сделать действительно модным, вы можетенаписать свою собственную альтернативу udp.Port (путем реализации IFileDescriptor самостоятельно) вместо написания протокола UDP и переопределить doRead и doWrite (которые вызываются, когдабазовый сокет читается и записывается соответственно).Это обеспечит вам идеальное управление потоком на уровне записи, но, вероятно, в этом нет необходимости, поскольку, опять же, UDP будет иногда отбрасывать ваши пакеты, а в сетях без возможности правильно обрабатывать сообщения «ICMP source quench» (которые настроены на немые межсетевые экраны).блок ICMP будет просто блокировать), отброшенные пакеты - ваш только источник информации управления потоком.Я не говорю, что вы не должны исправлять эту ошибку в Twisted по-настоящему, но этот факт жизни в мире UDP является вероятной причиной, по которой еще никто не удосужился сделать это.
2.Как мне вызвать метод startWriting (), если его нужно вызывать в определенные промежутки времени, чтобы ограничить исходящую полосу пропускания UDP определенной суммой дейтаграмм / секунда?
Из-за ограничений, описанных в части 1 этого ответаУ транспортов UDP нет полезного метода startWriting.
Однако, startWriting / stopWriting на самом деле не является правильным способом ограничения временной полосы пропускания исходящего UDP в любом случае.
Просто позвоните self.transport.write(...) в соответствующее время, после планирования указанных вызовов с помощью соответствующего механизма планирования.LoopingCall, например, был разработан для вызова UDP-посылок для потоковой передачи мультимедиа RTP с соответствующим интервалом для передачи звукового образца.Но вы также можете просто рассчитать собственную задержку и напрямую использовать callLater .В любом случае, вам, скорее всего, понадобится использовать какой-то механизм очереди в случае, если вам потребуется выполнить какие-либо повторные передачи исходящих данных, поставленных в очередь для передачи по UDP, поэтому просто наберите
Если вам нужнопри входящем управлении потоком, UDP-транспорты все еще поддерживают это довольно хорошо, с stopReading и startReading.
Надеюсь, что ответбыло полезно, и извините, если я ранее вводил вас в заблуждение относительно возможностей Twisted в этой области!