Sorry for being late to the party, maybe i'm missing something but sometimes it
is better not to add functionality which belongs elsewhere, to make boinc
"network interface aware" may open a large number of issues.
boinc is not a network monitoring application so it will struggle with this.
There a myriad of network adapters such as - dual and paired adapters /
virtual adapters / adapters in fail-over pairs to name a couple.
There are many types of wired and wireless adapters USB wireless etc.
Each OS has its own way of naming, measuring and managing them
Each users will have "preferences" of what is best - fastest least cost and
most won't care etc.
boinc would have to make sense of them all.
If the OP wants to do this, it is easy to write a basic script tailored to the
host to achieve this - this is what boinccmd is good for.
In linux this is easy with a if-up and if-down scripts
My windows skill are a little rusty but something like this - totally untested
script - which turn boinc network off when some interface is enabled.
The script will only work if the netsh output is tuned indicative of the state
for the host/adapter in question.
---------------
ECHO OFF
:REPEATLOOP
netsh interface show interface | find "Enabled Connected Dedicated
wifi" > nul
IF ERRORLEVEL 1 GOTO NoWifi
ECHO Connected to wifi
boinccmd --set_network_mode always
GOTO END
:NoWifi
ECHO Not Connected
boinccmd --set_network_mode never
:END
TIMEOUT 60
GOTO REPEATLOOP
----------------
I'd also add a current state environment variable and only run boinccmd if the
state changed to make it more efficient.
Best regards
Mike
On 02/04/17 15:04, Charles Elliott wrote:
> A computer can have as many connections to an IP address as it has free
> ports (numbered up to 65535, although many of the numbers less than 32768
> are reserved) and memory for the software implementation of an abstract
> concept called a "socket."
>
> A TCP/IP connection is defined by four numbers: client IP address, client
> port; server IP address, server port. For example, right now I have, inter
> alia, the following connections displayed in the connections table of my
> router:
>
> 192.168.0.100:61266 151.101.22.2:80
> 192.168.0.100:61368 151.101.22.2:80
> 192.168.0.100:61367 151.101.22.2:80
> 192.168.0.100:61265 151.101.22.2:80
> 192.168.0.100:61268 151.101.22.2:80
> 192.168.0.100:61269 151.101.22.2:80
>
>
> 151.101.22.2 is an IP address owned by fastly.com, a CDN, which I believe
> stands for Content Delivery Network. When a browser accesses a webpage, it
> is told to download the advertisements from fastly.com. Advertisers upload
> their content to fastly.com, and it is delivered when and where requested.
> Fastly may also help with billing issues and generating statistics on
> impressions delivered and viewed and possibly follow thru, but I am not
> certain about that.
>
> I don't understand what this discussion is about, though I suspect it is
> fundamentally about net neutrality. At one point the Oxford project person,
> David, wrote:
>
>>> It would be much easier if the clients did this. My Mac for example
>>> is able to tell me the latest network bandwidth it has for any of its
>>> interfaces.
> If by client he means his application, then all he has to do is put the
> download timing code in his application. Then if he wants to refuse to
> deliver very large files to computers with very narrow bandwidth
> connections, it is all on him and the school. I believe that if you just
> explain to people with clear, jargon-less statements why it is infeasible to
> deliver very large files in kilobit dribbles, they will not object. I did
> not like it when GPU Grid told me I could not participate when I signed up
> because my video cards were inadequate, but I got over it (and eventually
> bought new video cards, which I used elsewhere).
>
> Charles Elliott
>
>
> -----Original Message-----
> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
> Robert Miles
> Sent: Sunday, April 2, 2017 1:26 AM
> To: boinc_dev@ssl.berkeley.edu
> Subject: Re: [boinc_dev] An additional preference to prevent, downloading
> when on WiFi, to enable downloading only on when connected, to cable
>
> From what I've seen, Windows operating systems do not allow multiple
> connections to the internet to be active at once, which means that only one
> such connection can be reachable from BOINC at any one time.
>
> On 3/30/2017 8:34 AM, boinc_dev-requ...@ssl.berkeley.edu wrote:
>> Date: Thu, 30 Mar 2017 16:15:55 +0300
>> From: Vitalii Koshura <lestat.de.lion...@gmail.com>
>> Subject: Re: [boinc_dev] An additional preference to prevent
>> downloading when on WiFi, to enable downloading only on when
> connected
>> to cable
>>
>> Hello gyus,
>>
>> Maybe it would be preferably to let user choose the connection BOINC
>> uses for download/upload?
>> So in this case BOINC need to detect all available connections and
>> make a checkbox list where user can choose which connection should be
>> used when available?
>> Because doind automated testing of connection speed is not good for
>> these purposes.
>>
>> Thanks
>>
>> Best regards,
>> Vitalii Koshura
>>
>> 2017-03-30 16:08 GMT+03:00 McLeod, John <john.mcl...@sap.com>:
>>
>>> We have had this discussion before -- back in the days when dialup
>>> was common. Without doing an end to end test of the connection there
>>> is no way to tell what the connection speed is. Dialup is still the
>>> way things are in some places in the world. Based on dialup with a
>>> router and a switch, I can have a 1Gb connection locally but only a
>>> 1.3Kb connection to the outside world, and the computer cannot know
>>> without doing an end to end test. With ADSL links (much more common
>>> at the moment) it is possible to have a 1Gb connection locally and a 5Mb
> connection to the outside world.
>>> Running a check like this against some BOINC BOINC projects could tip
>>> them over into congestion where nothing gets through.
>>>
>>> So, it would require:
>>> A selection for what high speed meant.
>>> A checkbox to indicate if enabled.
>>> An end to end check to see what the connection speed was.
>>> Some idea of when to use it as doing an end to end connection check
>>> when there was only a few hundred bytes to transfer does not seem
> reasonable.
>>> At the time it was decided that this was not something we wanted to
>>> pursue. Of course, this can change.
>>>
>>> Jm7
>>>
>>> -----Original Message-----
>>> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
>>> Of David Wallom
>>> Sent: Thursday, March 30, 2017 8:28 AM
>>> To: elliott...@comcast.net; 'Nicol?s Alvarez'
>>> <nicolas.alva...@gmail.com>; Andy Bowery <andy.bow...@oerc.ox.ac.uk>
>>> Cc: boinc_dev@ssl.berkeley.edu
>>> Subject: Re: [boinc_dev] An additional preference to prevent
>>> downloading when on WiFi, to enable downloading only on when
>>> connected to cable
>>>
>>> Hi Charles,
>>>
>>> With the increasing prevalence of mobile computing devices then
>>> having the system (scheduler) doing the test is not really scalable
>>> as people move their devices.
>>>
>>> It would be much easier if the clients did this. My Mac for example
>>> is able to tell me the latest network bandwidth if has for any of its
>>> interfaces.
>>>
>>> David
>>> ________________________________________
>>> From: boinc_dev [boinc_dev-boun...@ssl.berkeley.edu] on behalf of
>>> Charles Elliott [elliott...@comcast.net]
>>> Sent: 30 March 2017 13:10
>>> To: 'Nicol?s Alvarez'; Andy Bowery
>>> Cc: boinc_dev@ssl.berkeley.edu
>>> Subject: Re: [boinc_dev] An additional preference to prevent
>>> downloading when on WiFi, to enable downloading only on when
>>> connected to cable
>>>
>>> Boinc could just download a test file from the Oxford website 5 times
>>> and average the times. If the average was above a limit deemed the
>>> minimum acceptable speed, the user would be permitted to proceed.
>>> OW, the Oxford website would post a very polite, very detailed, and
>>> very well written message to Boinc/the user explaining why a high
>>> bandwidth connection is necessary for the user's progress and enjoyment
> of Oxford's project.
>>> One of the Boinc GPU projects, as I recall in Spain, does this now
>>> WRT the capacity of the user's GPU(s). It is no fun for, or use to,
>>> anyone if the user processes a work unit on an older GPU, the GPU
>>> overheats, and the WU fails 3/4 of the way through. It is annoying
> though.
>>> Charles Elliott
>>>
>>> -----Original Message-----
>>> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
>>> Of Nicol?s Alvarez
>>> Sent: Wednesday, March 29, 2017 3:40 PM
>>> To: Andy Bowery
>>> Cc: BOINC Developers Mailing List ?[boinc_dev@ssl.berkeley.edu]?
>>> Subject: Re: [boinc_dev] An additional preference to prevent
>>> downloading when on WiFi, to enable downloading only on when
>>> connected to cable
>>>
>>> 2017-03-29 14:45 GMT-03:00 Andy Bowery <andy.bow...@oerc.ox.ac.uk>:
>>>> Hi,
>>>>
>>>> We would be interested in an additional BOINC preference, a tickbox
>>>> on
>>> the 'Network' tab, with something like 'Download only when connected
>>> to a high bandwidth connection'. Ticking the box of this preference
>>> would prevent download of the application and supporting files when
>>> the machine (for example: a laptop) was connected only to WiFi and
>>> not connected to a higher bandwidth networking cable. Would it be
>>> possible for this to be scheduled to be added as an item to be included
> in a later release?
>>>> With regards,
>>>>
>>> What does "high bandwidth connection" mean, how could BOINC know if
>>> it's connected to one?
>>>
>>> --
>>> Nicol?s
>
> _______________________________________________
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
>
--
BR
Mike
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
