I install Java from link on the first page.
Printable View
I install Java from link on the first page.
how do u use this
---------- Post Merged at 17:16 ---------- Previous Post was at 17:15 ----------
can u use on red
---------- Post Merged at 17:17 ---------- Previous Post was at 17:16 ----------
did u learn where 2 use
looking forward to a new BiglyBT Extreme Mod by SB-Innovation 1.9.0.0 Beta
many thanks in advance...
Btw: Imho this is the Java to use: https://adoptopenjdk.net/releases.html
- available for all platforms and then some
- Java 8 to 12 (unlike Oracle including x86 Windows for 11+)
- installer or zip
- 2 jvm options (hotspot for less cpu, openj9 for less memory)
- as a lean "jre" too - instread of just Oracle's huge jdk
=> you might want to add this link to the next copy/paste release notes :-)
Nice find (as usual :wwink:). I suppose you use this yourself and have no problems with it? I have had bad experiences with "alternative" JVMs, i.e. any binaries that didn't come from Oracle (and formerly Sun) in the form of an installer. Lack of stability and programs complaining they weren't running under the real thing. Although OpenJDK is an official Oracle project, so they should be pretty much equivalent.
To be honest, I just discovered it myself, but seems to run fine so far for BiglyBt and JDownloader.
As it's basically a compiled OpenJDK, and that's the reference nowadays, I guess it should be fine. Unlike than other 3rd-party jdk distributions, it has an installer - personally I use zips, but I guess the installer sets the usual JAVA_HOME env vars so the jre can be found for jar-exe wrappers.
Personally, I'd go for a jre because of the size. But as far as support is converned of course having different Java versions and dists will tend to create more problems. So a commercial distributor would say "check against Oracle before filing bugs" :-)
Last not least, I'm reading x86 11+ dists are less tested b/c Oracle only supports x64. But at least projects can move to 11+ without leaving x86 in the dust.
When all files are deselected when torrent being added, is the swarm average speed not available? thus rendering the following two options useless in this scenario?
- Use the swarm's average speed as fake upload speed (in speed mode++) <= When this option is checked in this scenario, the upspeedfake is always not generated.
- Stop increasing the fake upload when you are connected to less than X peers <= Suppose use number of connected to, this option is useless in this scenario, since no peer2peer connection will be established, right?
---------- Post Merged at 00:20 ---------- Previous Post was at 00:05 ----------
Is there a tool that implements a cheat mode that doesn't actually download content, at the same time be able to make different decisions (eg adjust fake speed or stop torrent) based on average swarm speed and swarm progress yet?
---------- Post Merged at 01:41 ---------- Previous Post was at 00:20 ----------
Is this understanding correct? When the option "Use the swarm's average speed as fake upload speed" is checked, assuming the swarm average speed is X, and "Speed: Between Y KB/s per torrent and Y KB/s per torrent" is set, then the actual fake upload speed will be randomly selected in range [X, Y]. and if X > Y , then fake speed = Y ?
But if X = 0 then fake speed also = 0 ?
Unfortunately, yes. You can't have an accurate or even somewhat accurate picture of the swarm if peers keep disconnecting you because they're uninterested on the nothing you have to offer (see https://wiki.theory.org/index.php/Bi...ation#Overview and https://www.sb-innovation.de/showthread.php?p=359104).
Such a thing is not possible for the reason mentioned above.Quote:
Is there a tool that implements a cheat mode that doesn't actually download content, at the same time be able to make different decisions (eg adjust fake speed or stop torrent) based on average swarm speed and swarm progress yet?
http://www.sb-innovation.de/attachme...chmentid=18711Quote:
Is this understanding correct?
When 18f is enabled, the first text field in 18k is disabled and the swarm speed is used as the minimum fake upload speed instead (and it can be as low as 0, yes). You can still control the maximum. If the swarm speed "X" is higher than your maximum "Y", the fake upload speed will effectively be set to "Y".
If this sounds too confusing, you can always experiment and check results using a public Linux torrent :happy:
I still don't understand why it's impossible.:confused:
The client can get approximate speed of other peers by have packet (and the time elapsed), and keep track of their progress by bitfield (to avoid running out of swarm progress) , and use other peers' bitfield/have to make up its own have/bitfield, keeping its own state as interested and unchoked (when "downloading"), but choke or discard the requests sent by other peers when they actually sent (pretend having busy network). - in which way, to avoid downloading actual content, at the same time try to look like a legitimate peer in the eyes of other peers.
<= Is this right?
Your peer connections won't stay open for long if you do this. On top of that, inactive peers are usually disconnected too.
If you're willing to do everything you mentioned plus keeping track of known peers and checking on them regularly, you'd get pretty close. But that's too much work just to obtain an approximation of an approximation (the "real" swarm speed is not 100% accurate in the first place).
Tracking speed is only one of considerations. Basically, I dream of a mode that:
- can fake download without actual download content
- with some degree of automation (eg if leecher<5 then upspeed=0 or if reach swarm progress then downspeed=0, etc)
- present as little cheating trait in peer-to-peer communication as possible.
mR doesn't send choke, RMP doesn't actively send handshake (which for a client lacking of port forward means no peer-to-peer communication at all, no chance to send choke), and BiglyBT Extreme Mod is pretty awesome but seems cant do these 3 together either. But indeed necessity and cost are the key considerations here. a lot more work appears once need taking care of p2p communication. I'm just concerned some strict anti-cheat trackers may catch us by checking peer-to-peer communications more closely.
I agree that any known detection vector in a cheat client should be fixed as a matter of principle, but as we discussed in https://www.sb-innovation.de/showthread.php?t=34560, peer behavior monitoring would be extremely hard to implement in a reliable and scalable manner.
I would instead be more concerned about TLS fingerprinting of tracker announces; while I don't think it will become a danger in the near future (see https://www.sb-innovation.de/showthread.php?p=356429), it would at least be much easier to perform, supplying circumstantial evidence of cheating (e.g. "uTorrent" request sent with Java 15's TLS fingerprint).
never heard of TLS Fingerprints before, googled it up, and this article describes it clearly (in case anyone else reading here doesn't know about it either) indeed this detection is relatively more reliable and feasible than p2p detection. sigh, after rereading that keepfrds post, this sentence stands out:
The reason why PTer and LeagueHD choose to spend more effort on developing that much unique features that other nexusphp trackers don't have, rather than on anti cheating, is probably because they also understand this. hopefully all trackers understand this. :wink2: