Increase efficiency of communication between GUI and daemon

[jackBzzz]

Right now, with GUI 5.18 and daemon 3.0, there is high network chatter between the two.
With ~2000 torrents loaded by a daemon, I see 45-55 Mbps traffic spikes every few seconds when the GUI queries the daemon. This might be okay on a 100+ Mbps link, but results in a very slow experience on slower links.

Therefore, I propose implementing:

• an option (defaulted to True) to suspend most, if not all network traffic from the GUI when the main and secondary GUI windows are not in focus.
• an option (defaulted to True) to query torrent information for only the ones that are actually shown on screen.

[Mrnofish]

While you may have a point, it does seem that what little spurt of development activity has taken place a few months ago, has died down again and the project is stalled.

There hasn't been a new binary release in over two years now, and the first chart on this page is not painting a pretty picture.

[lighterowl]

Each UI refresh iteration executes the torrent-get RPC call without specifying any torrent IDs, i.e. it requests data for all torrents loaded in the given Transmission session. The number of fields requested depends on the columns that you have selected to display in your UI.

In my case, with 1899 torrents, and the following request generated by transgui :

POST /transmission/rpc HTTP/1.1
Keep-Alive: 300
Connection: keep-alive
User-Agent: Mozilla/4.0 (compatible; Synapse)
Content-Type: application/json; charset=UTF-8
Content-Length: 427

{ "method" : "torrent-get", "arguments" : { "fields" : ["id", "name", "status", "errorString", "announceResponse", "recheckProgress", "sizeWhenDone", "leftUntilDone", "rateDownload", "rateUpload", "trackerStats", "metadataPercentComplete", "totalSize", "status", "peersSendingToUs", "seeders", "peersGettingFromUs", "leechers", "eta", "uploadRatio", "downloadedEver", "uploadedEver", "addedDate", "doneDate", "downloadDir"] } }

The JSON reply is 2424015 bytes in length.

45-55 Mbps sounds a little excessive. Perhaps try right-clicking on the table header in the main display, selecting "Setup columns..." and unchecking the ones you don't care about that much, or the ones that you don't use to sort the table.

The suggestion is valid, however I wouldn't hold my breath to see it implemented, as @Mrnofish is right here in saying that there's little development taking place.

Transmission 3.0 also added the format request key to torrent-get, which when set to table usually results in a more compact JSON. Perhaps this would help a bit, but again would need development work on transgui side.

* an option (defaulted to True) to suspend most, if not all network traffic from the GUI when the main and secondary GUI windows are not in focus.

This is actually already available under Tools -> Application options -> Data refresh interval when minimized .

[namazso]

Some optimizations would indeed be welcome, the current communication is very ineffective:

This is more data usage than what the daemon did for torrenting operations.

In other news, transmission 4.0.0 beta 1 added gzip compression, is this used with transgui?

[lighterowl]

In other news, transmission 4.0.0 beta 1 added gzip compression, is this used with transgui?

No.

[lighterowl]

#1438 Should make things a bit better.

[lighterowl]

In other news, transmission 4.0.0 beta 1 added gzip compression, is this used with transgui?

The gzip thing that the release notes are referring to is the "gzipped bundle" for all the WebUI files. This has nothing to do with RPC.

Gzip compression has been supported by Transmission's RPC server since 2.10, and was introduced in this commit made in 2010 : transmission/transmission@ad2cf3c .

It looks like transgui branched off Synapse revision 207 with a very minor set of changes. Unfortunately, the newest version of Synapse at the time of writing doesn't support gzip encoding.

[lighterowl]

Requesting gzipped payloads from Transmission is implemented in #1439.

Testing with both #1438 and #1439 merged in , the size of the HTTP payload is just 198 KiB instead of 2436.

[enchained]

Testing with both #1438 and #1439 merged in , the size of the HTTP payload is just 198 KiB instead of 2436.

Are there any builds available with those fixes?

[lighterowl]

Testing with both #1438 and #1439 merged in , the size of the HTTP payload is just 198 KiB instead of 2436.

Are there any builds available with those fixes?

Yes, have a look at my fork.