-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Share a port with net/http #418
Comments
hi @jech ! As long as you use different protocols (TCP for the webservice and UDP for TURN), having the same port number will not be an issue. The operating system does the "demultiplexing" for you. |
Of course. The issue is with TURN over TCP, which is required for videoconferencing to work in restrictive networks that block all UDP. |
So your webservice is doing HTTP/WebSocket/GRPC, while the TCP is of course TURN/TCP or TURN/TLS and you'd like to expose these on the same port, it that right? Now one way to solve this would be to add a gateway that will do some magic to separate HTTP traffic from pure TCP and route sessions based on that. I've never done that myself, but it certainly seems doable with Envoy (you may need to manually config Envoy though, I'm not sure envoy-gateway or Istio exposes this semi-advanced feature, but who knows?). Here is a seemingly relevant example on how to separate TLS from non-TLS TCP traffic, and here is the the corresponding Envoy API config. On the long run I'm not sure it's worth the pain. TURN/TCP latency can go terribly bad even without a proxy in front. |
There is no reason we shouldn't be able to achieve that in pure Go code, without involving a proxy. |
You mean by adding this functionality to STUNner? |
No. |
I'm terribly sorry, I replied to the wrong thread. Please ignore my last comments. I agree: adding this in Go is absolutely possible. We may not even need to modify the TURN server for this: just pass in a It is still an interesting question how to reliably tell HTTP from non-HTTP traffic apart, especially that we may need to look into encrypted HTTPS/TLS payload. Perhaps the Envoy HTTP Inspector linked above might be instructive here (at least my stupid comment was not completely in vain). |
Hi,
The strict minimum for Galene to be accessible from a retrictive network is two open ports: the webserver's port and the TURN server's port. By default, Galene uses 8443 for the web server, and 1194 for the TURN server, for the simle reason that these ports are guaranteed to be accessible from every Eduroam network1.
Ideally, we should be able to share a single port between the web server and the TURN server: perhaps a demultiplexer coud be examine the first bytes sent over a TCP connection, and dispatch the connection to either the TURN server or the web server. UDP would go to Turn for now, which will obviously break when
net/http
implementes HTTP/3.The text was updated successfully, but these errors were encountered: