Time for a little bit of explanation, now the new streamproxy is active.
Previously:
- on 8001 (tcp4) enigma (internal streaming proxy) would listen for streaming requests
- on 8002 (tcp4) the vuplus "live" transcoding proxy would be listening
- on 8003 (tcp4) the vuplus file transcoding proxy would be listening
If you would pass a "file" request to port 8002, the live transcoding proxy would set up a connection to port 8003 and pump all data yet another time around.
Now:
- on 8001 (tcp4) still the internal enigma proxy is listening, no change there
- on 8002 (tcp4/6) now the streamproxy is running, it accepts both live and file requests, streaming and transcoding,
- on 8003 (tcp4/6) exactly the same as on port 8002
If you do a "classic" request on 8002 (i.e. only a service in the uri), you'll get the transcoded version, if you supply a file, you will get the file. Same goes for port 8003. The default is transcoding, but you can set the default action to streaming as well.
Then there is the "new" request style where you specify exactly what you want, explicitly.
- /livestream?service=service
- /live?service=service
- /filestream?file=file
- /file?=file
1 passes the service as broadcast
2 transcodes the service
3 passes the file as recorded
4 transcodes the file
Number 4 is compatible with the way vuplus does it (the other ones they don't implement explicitly).
So, with this scheme you should have compatibility with the existing situation and also have explicit behaviour using just one http port.
The internal streaming (not transcoding) proxy does not check any authentication, it relies on authentication being checked by the web interface.
The vuplus proxies handle authentication in a "pass through" manner, when the webif says "401 unauthorized" it passes the reply down to the client, which would retry with the proper authentication, which the proxy also passes on.
The streamproxy does also check authentication by itself, for two reasons: a) for people that are stubborn and still make their stb available to the internet, this at least reliefs enigma from the authentication burden, when a hacker runs a brute force attack, it would not cripple the receiver, as only one connection per two seconds is allowed. And it allows to use define group membership that is required for a user to be allowed to stream (see -g).
Authentication in streamproxy is handled like this:
- if no webif auth is configured in enigma, do nothing special
- otherwise check if the client supplies credentials for this realm
- if not, reply "401 unauthorized" to the client
- when the client supplies the credentials, decode and check them
- if not sufficient, deny the request
- if sufficient, pass the request on to the web interface (allocation of channel, demux etc.)
I have some interesting features in mind for the near future, one of them being already available: if you supply a "startfrom=h:m:s" parameter to a file streaming/transcoding uri, it will skip until that point (current limitation that no timestamp wraparound may occur in the file, these are rare anyway).
Edited by Erik Slagter, 7 April 2014 - 17:19.