> > Usage: >> $ curl --turn [IP:port] --proxy-user [user:pass] [destination] >> > > Do you think it makes sense to also support some sort of proxy protocol > prefix? Like for example setting the proxy to "turn://IP:port" in the same > vein we can do SOCKS and HTTP etc already. It makes it way simpler for > applications that want to pass on or set "a proxy". >
Yes, actually it does support that, I just forgot to mention. You can use: $ curl --turn [IP:port] --proxy-user [user:pass] [destination] or $ curl --proxy turn://[user:pass]@[IP:port] [destination] As usual. Is there perhaps any other existing clients/browsers that support TURN that > we can learn or adapt config ways from? Definitely not, and people tend to bite when you mention this :) That's why I classified it as experimental. I wanted something like this while testing some TURN servers with support to TCP: I just wanted to do some "real life" data requests (and load tests) in order to verify their robustness and stability. But in the real life usage, it can be used only for overlay networks, like to avoid eavesdropping and bypassing Internet connections subjected to censorship. - It doesn't support short term passwords (only no-auth and long-term-auth >> at this time); >> > > For someone not really versed in the details of the protocol, what's the > actual protocol differences between short term and long term auth? A short term password is normally obtained by connecting to some other Internet service, sending the long term credentials, and obtaining a user/pass tuple for using in a very short time for traversing the firewall/blocking. The old TURN RFC used a special TUN request for this (the SHARED SECRET request), but it has been deprecated. Nowadays implementations tend to use a combination of HTTP and JSON, but the standards are still new in the sense that servers are not 100% compatible at the moment. Long term passwords are set up on the TURN server, and then used by all clients. That's the main difference. > - Currently it doesn't support FTP in PASV mode, but should work fine >> with any other protocol over TURN since one doesn't use a secondary socket; >> > > If you make it like the socks proxy approach, can't you just add a > function call in ftp.c:proxy_magic() then to make PASV work? The problem is that TCP over TURN requires two sockets: one for control, another for actual data. The control socket was selected as being the FIRSTSOCKET, and the data socket the SECONDARYSOCKET. Then, the current implementation fails miserably if a protocol tries to call Curl_TURN passing SECONDARYSOCKET as the sockindex parameter. That approach of course can be solved by extending the connectdata structure, but I decided to keep it as simple as possible at this stage, as I really don't think that cURL over TURN will be used by a lot of people. Or, at least, not at this moment. Regards, -- Guilherme Balena Versiani
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
