Когда сервер STUN получает запрос от двух разных агентов STUN с тем же идентификатором транзакции, как он должен себя вести?Как работает сервер STUN, когда он получает запрос с одинаковым идентификатором транзакции от разных агентов STUN?
Идентификатор транзакции из запроса привязки STUN просто отозван обратно в ответе на привязку STUN. Сервер не пытается интерпретировать это значение ничем иным, чем, возможно, протоколированием. Он также не пытается управлять дублирующимися запросами или дублировать идентификаторы транзакций или обрабатывать их. Если два разных клиента отправляют запрос привязки с тем же идентификатором транзакции, то оба получат одинаковый идентификатор транзакции в своем соответствующем ответе.
Идентификатор транзакции просто для удобства клиента. Если клиент получает ответ от сервера с другим идентификатором транзакции, чем тот, который он использовал в запросе, он должен просто игнорировать его. Поскольку этот пакет может быть поздним прибытием с предыдущего сеанса STUN.
Об единственном времени, в течение которого может существовать дублированный идентификатор трансакции, когда клиент истекает время ожидания ответа и повторно отправляет запрос привязки. RFC 5389 ссылается на это в section 6: Resends of the same request reuse the same transaction ID.
Я не думаю, что вы должны подготовить свое программное обеспечение для обработки таких странных ситуаций. Идентификатор транзакции - это случайное значение, генерируемое клиентами, и очень маловероятно, что вы увидите такую ошибку в оглушающих клиентах.
Идентификатор транзакции - это 96-битный идентификатор, используемый для уникальной идентификации транзакций STUN для . Для транзакций запроса/ответа идентификатор транзакции выбирается клиентом STUN для запроса, а эхом отозвался сервером в ответе.
Если вы не случайно, то, скорее всего, это будет вызвано одним фиктивным клиентским программным обеспечением, и в конечном итоге вы просто отправляете плохие ответы на этот клиент, пока его разработчик не найдет это и не исправит свое программное обеспечение.
Это не должно происходить, но если тогда сервер должен проверить 5-кортеж (сочетание IP-адреса и порта клиента, IP-адреса и порта сервера и транспортного протокола (в настоящее время один из UDP, TCP или TLS)). , Если 5-кортеж не соответствует, то сервер должен продолжить рассмотрение этого вопроса как действительной транзакции, иначе он должен вести себя согласно RFC-5766.