Documentation
¶
Overview ¶
Command turnclient moves data through a pipe connection that is forced onto a TURN relay, and reports what it measured.
By default it starts its own STUN and TURN server in-process, so the whole thing is one command:
go run ./examples/turnclient
Squeeze the relay to see the effect on a pipe connection. The rate is per relay socket per direction, and it is enforced by delaying and dropping datagrams — so SCTP inside the pipe meets real congestion, not a simulated number:
go run ./examples/turnclient -rate 512KiB -bytes 4MiB
Point it at a server you started separately — `go run ./examples/turnserver`, or coturn, or a cloud TURN service — with the URL and credentials:
go run ./examples/turnclient -embedded=false \ -turn 'turn:127.0.0.1:3478?transport=udp' -user admin -pass admin
Credentials are read from TUNNEL_TURN_USERNAME and TUNNEL_TURN_PASSWORD when the flags are empty, which is how they should reach a real deployment.
Two things are worth noticing in the output. The candidate types report `relay/relay`, which is proof the bytes went through TURN rather than finding a local shortcut. And with a rate set, the relay counters show exactly how much was metered and how much was dropped.
Do not expect application throughput to equal -rate. The transfer is an echo, so every byte crosses the relay four times — out through the client's allocation, in through the server's, and the same again on the way back — and each crossing is metered separately. Datagrams over budget are dropped, and SCTP inside the pipe responds to that loss by backing off, exactly as it would on a congested link. The measured number is what the application really gets, not what the token bucket was set to.
Source Files