feature request for configuration file

[Ersan]

can you PLEEEEEAASE add the following options to the configuration file:

set net.outgoing_ip

disable read and write cache entirely

set net.low_cpu

randomize bittorrent port on startup

I will be eternally grateful.

PS: I don't see why every variable shouldn't be able to be changed from the utserver conf. And I also think the conf should supercede settings.dat, but that's up to you guys I can work around that.

[mcdonald]

can you PLEEEEEAASE add the following options to the configuration file:

I'll respond to each of these.

set net.outgoing_ip

It is probably an unfortunate decision that the choice of outgoing IP is made by specifying the IP address rather than by specifying the network adapter to use (and whose IP address should be used as the outgoing IP address). I believe this is likely to be changed in the future. I don't see the point to be able to specify an outgoing IP that may not be bound to any of the existing network adapters at some point in the future.

The configuration file option

preferred_interface

is an example of how configuration probably ought to have been done; this setting is read and applied at every startup, regardless of the contents of settings.dat.

I added an item to our todo list for the modified request.

disable read and write cache entirely

Tell me more about the problem for which you believe this is a solution.

set net.low_cpu

I've added it to our todo list since others have apparently used this setting to work around issues they have seen. If the value for this setting is set in the configuration file, the ability to change this setting via the HTTP interface will probably be disabled, since the administrator is indicating a configuration choice that shouldn't be changed by a user.

randomize bittorrent port on startup

I've added this request to our todo list.

I don't see why every variable shouldn't be able to be changed from the utserver conf. And I also think the conf should supercede settings.dat, but that's up to you guys I can work around that.

I think it could provide an awkward user experience to force the value of a configuration file setting to always be used, even if the user has subsequently changed the value via the HTTP interface. There are some settings for which this is appropriate - currently those settings are ones whose values can't be changed via the HTTP interface.

Currently there is no provision for the person creating the configuration file to specify whether a configuration setting should always apply (preventing changes via the HTTP interface) or should just be the initial/default value (allowing subsequent changes via the HTTP interface). This is a choice that is encoded into the program. I've added an item to our todo list to support this (which would require a change in the format of the configuration file).

[Ersan]

I didn't know the configuration file was to contain settings that shouldn't be edited by the user, but that makes sense.

The environment I'm using is one in which there are multiple utserver processes, the filesystem read and write cache are more efficient than utorrent's - with 100MB of read&write cache in utorrent I was only able to achieve 30MB/s of throughput, whereas disabling it entirely yields the maximum the interface allows, 125MB/s - this can be fixed by upping the cache to the maximum of 512MB but then I'm wasting RAM on caching things twice. Allowing the user to edit these means they can use more RAM for the utserver process than the administrator might want them to.

[mcdonald]

I didn't know the configuration file was to contain settings that shouldn't be edited by the user, but that makes sense.

Not all settings are that way - some are initial settings that can override the initial settings encoded into the program.

The environment I'm using is one in which there are multiple utserver processes, the filesystem read and write cache are more efficient than utorrent's - with 100MB of read&write cache in utorrent I was only able to achieve 30MB/s of throughput, whereas disabling it entirely yields the maximum the interface allows, 125MB/s - this can be fixed by upping the cache to the maximum of 512MB but then I'm wasting RAM on caching things twice. Allowing the user to edit these means they can use more RAM for the utserver process than the administrator might want them to.

I added an item to our todo list for your request.

[Ersan]

Thanks much.

Also for the net.outgoing_ip issue, if you want to just set outgoing_ip to bind_ip that would work great, the issue I was having is that utorrent was reporting the wrong ip to the tracker even though it was bound to the right interface.

[Ersan]

Another request for a configuration option: disable µTP

And change Encryption settings.