I made an upload tool that needed to handle very large files, and I used WebSockets to do it.
The strategy I used was to parse the MOV/MP4 locally, consider between 2-60 frames of data, hash it, then stream up the hashes to the server. Any hash the server didn't have got a reply to push those bytes.
The two-way nature of this dialog made WebSockets a good fit, although it certainly could have been emulated using other methods, it would have been much more code.
That's because WebSockets are more or less just sockets for web apps. You'lll want to use a protocol that deals with messages and their at-least-once delivery, such as MQTT (that can run on top of WebSocket if you need it).
Websockets are the natural choice when/if we bring Filmgrain to the browser. I actually think Websockets are really exciting, but for a mobile app just going straight socket made more sense.
And the first thing that people do when they start using websockets is to define a message layer.
HTTP is designed for transferring media types. It can transfer the application/octet-stream if you want to transfer "raw" binary.
If want you want to do is stream binary data, there are better protocols than TCP or UDP for the purpose. The use of Websockets is a way to get binary streams through the HTTP "firewall hole" on port 80/443, not because it is more efficient.
Genuinely curious coz I don’t understand mobile networks very well — why not just send frames over websockets? You still get a persistent TCP connection and there’s no need for pushing or polling of any kind.
reply