long polling

[digital-dreamer]

long polling

[digital-dreamer]

Hi Tschaul,

so basically, we would need to change twister-html so that it won't make the synchronous RPC calls every second. Instead, twister-proxy would be making these calls to twister-core, and twister-html would be listening on some kind of websocket, waiting from a reply from twister-proxy, which would get triggered by a non-empty reply?

[Tschaul]

The incoming connections from twister-html would simply be kept alive and stashed aside until twister-proxy gets a non-empty reply. Thats the difference between real push and long polling, no websocket needed. So twister-html would only need a slight change. Instead of sending out the calls every second, it would have to send them out one second after it got the previous one back. Then the request can sit and wait on the proxy until something happens, and when something happens it comes back and a new request is issued. This way twister-html doesn't need to know whether or not there is a proxy doing the repeated polling for it.

[digital-dreamer]

Good idea 👍 First step is to make twister-html ready for use on a public server (I plan to solve some issues with it and make a new pull request to Miguel soon), but this will certainly be a good feature to have.

[Tschaul]

Having used the twister JSON-RPC a bit more, i think that an empty response is not a good trigger for long polling. I'd much rather have an extra getposts_longpoll method, even though this would mean that twister-html has to adapt more. Or even more advanced, a websocket on which you can subscribe to torrents. JSON-RPC would generally allow that. I found these discussions on the JSON-RPC mailing list:

https://groups.google.com/forum/#!topic/json-rpc/EWnUwcTmOjY
https://groups.google.com/forum/#!topic/json-rpc/5PcrYSfzavA

A websocket would be great, also without long polling. I don't have benchmarks but i guess with the small message bodies that are transfered HTTP has a very big overhead.

Also, related, i found out that the twister-proxy right now does not allow batch-requests but twisterd does. The batch feature is not very useful at the moment because the requests are not carried out concurrently. So there is no speed up and you have to wait for all requests to finish before you get a result back. Not worth a new issue so i mention it here.