mirror of
https://github.com/coturn/coturn.git
synced 2026-10-24 00:08:57 +03:00
a97f1924bb
Under --mobility a resume does not hard-switch the allocation onto the new client path; it opens a dual-5-tuple transition and links the resuming session to the allocation via a single backlink (mobile_pending_resume). An authenticated user could resume one allocation repeatedly from fresh 5-tuples without completing any handoff: each resume disarmed the new session's un-allocated watchdog and overwrote that single backlink, orphaning the previous pending session. Orphans were unreachable by the transition-deadline sweep and owned no allocation timer, so they stayed allocated indefinitely, letting one user grow server memory without bound. --user-quota did not stop it, since pending sessions hold no quota unit. Enforce one pending resume per allocation: - mobile_begin_transition() fully tears down the existing pending session before opening a new one. It runs in REFRESH packet context, so the shutdown is synchronous and also clears the allocation's backlink via shutdown's transition-unlink path. - mobile_abort_transition() re-arms the disarmed watchdog so an abandoned pending left after the transition deadline is reaped from timer context (safe during the session-map sweep, which only schedules the timer). - mobile_complete_transition() promotes only when the session is still the allocation's current pending resume, so a superseded pending can neither clear live transition state nor steal a socket move. Add examples/run_tests_mobility_resume_flood.sh (+ raw-STUN driver scripts/mobility_resume_flood.py): it floods chained resumes and asserts every superseded pending is torn down. It passes on the fixed server and fails on the unpatched one. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This directory contains various example scripts for the TURN server functionality illustration. 1) peer.sh starts the "peer" application that serves as a peer for all examples. 2) "basic" directory contains set of scripts which works together to demonstrate very basic anynymous functionality of the TURN server. The "peer.sh" must be used, too. 3) "longtermsecure" directory contains set of scripts demonstrating the long-term authentication mechanism (peer.sh to be used, too). 4) "longtermsecuredb" shows how to start TURN server with database. The clients from the directory "longtermsecure" can be used with the relay scripts in the "longtermsecuredb" directory. Of course, the database (SQLite, PostgreSQL, MySQL, Redis or MongoDB) must be set for these scripts to work correctly. 5) "restapi" shows how to use TURN REST API. 6) "loadbalance" shows how to use the simple load-balancing mechanism based upon the ALTERNATE-SERVER functionality. 7) "selfloadbalance" shows how to use the "self-load-balance" TURN server capabilities. 8) "mobile" shows the "mobile" connections - how the TURN session can change its client address.