Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Implementation of TS API for paid traffic. Clients (TorrServe\Web) use a large amount of traffic from TorrServer while idle. #389

Open
filimonic opened this issue May 7, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@filimonic
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Web UI queries TorrServer for POST /torrents in a second after previous request was completed.
TorrServe for Android seems to be acting the same way.

In my case, I have ~500 kb response.
It is ~ 30 Mb per minute, or 💥 41 GB 💥 per day! wasted just in idle mode!

Describe the solution you'd like

  1. Add some kind of "paid traffic mode" and light version API when client gets data only if it is updated:
    1.1 Send Only necessary info about torrent: do not send any extra data when torrent is "active" like file_stats
    1.2 Support ETag or similar way of indicating that response was not changed since previous request
    1.3 Make request timeouts larger (30 sec, ex)

  2. Replace requests with notifications over established connection: switch to WebSocket or HTTP LongPolling and send all necessary data only it is needed.

Describe alternatives you've considered
No alternatives, just not to forget turn off TV and do not leave WebUI opened.

@filimonic filimonic added the enhancement New feature or request label May 7, 2024
@tsynik
Copy link
Collaborator

tsynik commented May 8, 2024

Just as described: if you care about traffic much - don't leave web UI opened or don't store torrents on server, they'll be removed after timeout. In most use cases it's LAN traffic between player and local torrserver. 30 MB per minute is nothing against 1080/4K video played at the same time.

@filimonic
Copy link
Contributor Author

In most use cases it's LAN traffic between player and local torrserver. 30 MB per minute is nothing against 1080/4K video played at the same time.

Totally agree, this is because it's FR, not a bug.

@tsynik
Copy link
Collaborator

tsynik commented May 8, 2024

Also, it's not related to TorrServer directly. You can use any script to communicate with TorrServer or play torrent data. So, it's not a FR for it.

@filimonic
Copy link
Contributor Author

Also, it's not related to TorrServer directly. You can use any script to communicate with TorrServer or play torrent data. So, it's not a FR for it.

It is related directly, as it requires implementing new API for TS "ecosystem":

  • TorrServer-WebUI API
  • TorrServer-TorrServe API

@cocool97
Copy link
Contributor

cocool97 commented May 8, 2024

What about using websockets to prevent client from polling ?

@filimonic
Copy link
Contributor Author

What about using websockets to prevent client from polling ?

IMO:

  1. Websockets are good, but IDK if they work good without TLS on modern software, maybe there is a limitation?
  2. Not all API should be websocket-ized, only torrent list, and maybe cache updates.

@cocool97
Copy link
Contributor

cocool97 commented May 8, 2024

AFAIK there is no limitation caused by TLS or not, you can use ws for HTTP or wss for HTTPS.

I truly think that this should just be for these endpoints as client polling can be quite verbose

@tsynik tsynik changed the title [Feature] Optimize TS clients for paid traffic. Clients (TorrServe\Web) waste too much traffic from TorrServer while idle. [Feature] Implementation of TS API for paid traffic. Clients (TorrServe\Web) use a large amount of traffic from TorrServer while idle. May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants