23-Dec-2015, 16:26
One thing that's interesting from the first look at the protocol is that it should be possible to create a simple "proxy" tool to use an external Spark server.
It would go like this (capturing UDP only on server-side as rest of communication is via TCP):
1. Have Spark on a server with lots of space and huge music library, with external IP address.
2. Run a small tool to listen for broadcast UDP packets from Spark and publish them somewhere (or decipher announcement protocol).
3. Run a second tool which reannounces the Spark announcements on the local network, with the external IP of the Spark server.
3a. (optional) Capture communication between Phantom and Spark server to block Phantom control from Spark server, as a security measure.
4. Run local Spark and use the remote Spark server music library as if it was local.
Streaming through the standard playback mechanism seems problematic because Phantom seems to download the whole audio file from Spark to play, instead of streaming it..
It would go like this (capturing UDP only on server-side as rest of communication is via TCP):
1. Have Spark on a server with lots of space and huge music library, with external IP address.
2. Run a small tool to listen for broadcast UDP packets from Spark and publish them somewhere (or decipher announcement protocol).
3. Run a second tool which reannounces the Spark announcements on the local network, with the external IP of the Spark server.
3a. (optional) Capture communication between Phantom and Spark server to block Phantom control from Spark server, as a security measure.
4. Run local Spark and use the remote Spark server music library as if it was local.
Streaming through the standard playback mechanism seems problematic because Phantom seems to download the whole audio file from Spark to play, instead of streaming it..
