[X] My Assistant

After a day's running all 3 of my H@H server runs fine, but when I check the log of them I get a plenty amount of crawler trying to access paths that don't exist. Now I don't think that using port 443 is a good idea, 8443 or some higher-than-1024 ports like that would be more reasonable because it's relatively safer and less chaotic(I mean the linux non-root low port thing).

Crawlers and various other crap trying to poke the port isn't dangerous in and of itself and should consume negligible amounts of resources, nor does it affect your trust/quality as the request isn't issued by the site.

The only reason I recommend 443 is that it will allow people behind restrictive firewalls/proxies to access resources on your client, and the real-life data does seem to show a statistically significant difference. Of 324 clients running 1.5, the 195 that run on port 443 average 8758 quality and 963 trust, while the 129 that do not average 8404 quality and 855 trust.

FWIW, there are 29 clients using port 8443 that average 8599 quality and 932 trust, but the sample size is probably too small to say anything conclusive about whether it is better than any other non-443 port.

I do see a real hard hit on quality since I updated to 1.5.x. I had H@H running on port 1337 for roughly 2 years now and always had >=9500 quality, usually 10k flat. Right now it fluctuates between 5000 and 7000. I sadly can't use port 443 because my webserver is using it already. Feels like I have to go back to 1.4.2 for now or at least try port 8443 as alternative.

I do see a real hard hit on quality since I updated to 1.5.x. I had H@H running on port 1337 for roughly 2 years now and always had >=9500 quality, usually 10k flat. Right now it fluctuates between 5000 and 7000. I sadly can't use port 443 because my webserver is using it already. Feels like I have to go back to 1.4.2 for now or at least try port 8443 as alternative.

I have exact same results, port doesn't change really a thing. After trying multiple variations & setups I just downgraded.

Since yesterday and a changed port to 8443 I went down to ~2500 quality. Trust is always at max, so no problem there. I'll switch back to 1.4.2 for now.

trust downed to between 300 and -100 several days on mostly 1.5.1 clients (windows and ubuntu), windows clients dropped more, and one ran in port 443.
find a template from the err log, I just backup it.
I switched the windows clients back to 1.4.2.

these errors happened once for some hours in 1.5.1 windows client id 14257 and id 14262, the cache files are different in each error.

CODE

2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)} java.nio.file.FileAlreadyExistsException: tmp\proxyfile_8394055947559377382 -> cache\37\2d\372d369a1452cec8be8d72e8b857e6c192d43882-3146926-1600-1200-png
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at sun.nio.fs.WindowsFileCopy.move(Unknown Source)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at sun.nio.fs.WindowsFileSystemProvider.move(Unknown Source)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at java.nio.file.Files.move(Unknown Source)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at hath.base.CacheHandler.moveFileToCacheDir(CacheHandler.java:681)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at hath.base.CacheHandler.importFile(CacheHandler.java:658)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at hath.base.ProxyFileDownloader.checkFinalizeDownloadedFile(ProxyFileDownloader.java:282)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at hath.base.ProxyFileDownloader.run(ProxyFileDownloader.java:210)
2019-10-25T00:42:43Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at java.lang.Thread.run(Unknown Source)
2019-10-25T00:42:43Z [WARN] CacheHandler: Encountered exception java.nio.file.FileAlreadyExistsException: tmp\proxyfile_8394055947559377382 -> cache\37\2d\372d369a1452cec8be8d72e8b857e6c192d43882-3146926-1600-1200-png when moving file tmp\proxyfile_839405594755937738

This post has been edited by morineko: Oct 26 2019, 04:03

trust downed to between 300 and -100 several days on mostly 1.5.1 clients (windows and ubuntu), windows clients dropped more, and one ran in port 443.
find a template from the err log, I just backup it.
I switched the windows clients back to 1.4.2.

I think those java errors have nothing to do with the trust problem because the file should be properly cached, I used to see the same error before, it happened when different connections requested for the same file that wasn't cached on the H@H client so multiple ProxyFileDownloader threads tried to write the same file to the disk.

Don't know how trust and quality are calculated, but my client doesn't have such error and the trust still drops, I don't see other error and the client seems to serve requests perfectly. I doubt it's caused by connection between the client and the rpc server or other h@h clients, my client sometimes fails to start because the rpc server reported "Startup Failure: FAIL_CONNECT_TEST:SSL connect error" when preparing for speedtest.

This post has been edited by mewsf: Oct 26 2019, 07:30

I do see a real hard hit on quality since I updated to 1.5.x. I had H@H running on port 1337 for roughly 2 years now and always had >=9500 quality, usually 10k flat. Right now it fluctuates between 5000 and 7000. I sadly can't use port 443 because my webserver is using it already. Feels like I have to go back to 1.4.2 for now or at least try port 8443 as alternative.

Before, I used 1.4.2 with a port (5 numbers), I had 7000~8000 quality (never 10k) and trust was always 1000.

Now, with 1.5.1 and 443 port, I have 10k quality and 1000 trust.

I moved one of my port 443 H@H 1.5.1 Client to another machine and switched to port 8443, ran for about 24 hours.

No significant Quality or Trust drop as I can see.

However, I directly upgraded another two of my port 17171 H@H 1.4.2 clients to 1.5.1, didn't switch my port, ran for about 24 hours.

Both of them have Quality still capped at 10000 but Trust dropped to around 300 And, I believe they were still dropping as I was checking the statistics.

switching these two to 8443 now and see how would that goes.

This post has been edited by rankgrass: Oct 26 2019, 20:51

I think I figured out why some people are seeing trust drops on 1.5; it doesn't actually have anything to do with the client, but because some time cutoffs were changed for 1.5 specifically to compensate for another effect, it messed with a backend mechanism where clients that fail other clients much more often than average should be long-term disqualified to act as testers. This should be fixed now, but it will take a few hours before it's back to normal.

Move to 1.5.1 client at port 8443,the trust is 1k,but the Quality <3000.But the 1.5.0 client Quality over 8000.Maybe I need to downgrade.

This post has been edited by dargon123: Oct 27 2019, 03:38

Move to 1.5.1 client at port 8443,the trust is 1k,but the Quality <3000.But the 1.5.0 client Quality over 8000.Maybe I need to downgrade.

I have the same and no errors in my logs.

1.5.1: Port 443 routed to 62000
Trust 1k, quality <3k
1.4.2: Port 443 routed to 62000
Trust 1k, quality >7k

Move to 1.5.1 client at port 8443,the trust is 1k,but the Quality <3000.But the 1.5.0 client Quality over 8000.Maybe I need to downgrade.

There shouldn't be any quality difference between 1.5.0 and 1.5.1, but it doesn't really matter which one of those you run either.

There shouldn't be any quality difference between 1.5.0 and 1.5.1, but it doesn't really matter which one of those you run either.

Agree, moving 4 of my 1.4.2 clients to 1.5.1 seems to have no Quality hit at all, maybe it is related with port forwarding and HTTPS protocol kind of problems?

This post has been edited by rankgrass: Oct 27 2019, 09:33

I just noticed that I have been using TLS1.3 when running 1.5.1 with java 11. Running now in TLS1.2 to see if that makes a difference.

It does prefer TLS1.3 with Java 11 and newer, but it still allows old protocols all the way down to 1.0 so that really shouldn't affect quality in any way. FWIW, I generally test H@H with OpenJDK 8 and 11 on Linux and Windows, and I haven't seen any particular issues with 11/TLS1.3. (Oracle Java is no longer supported for licensing reasons, but should work as well.)

It does prefer TLS1.3 with Java 11 and newer, but it still allows old protocols all the way down to 1.0 so that really shouldn't affect quality in any way. FWIW, I generally test H@H with OpenJDK 8 and 11 on Linux and Windows, and I haven't seen any particular issues with 11/TLS1.3. (Oracle Java is no longer supported for licensing reasons, but should work as well.)

I have been running TLS1.2 with java 8 now and my quality is over 7k and still going up. With java 11 running TLS1.3 it went straight down to under 3k in a few hours.

...

Is there some human way to identify which subdomain.hath.network client is using?

(IMG:[a.uguu.se] https://a.uguu.se/cNscWKSmH1qv.png)

I have been running TLS1.2 with java 8 now and my quality is over 7k and still going up. With java 11 running TLS1.3 it went straight down to under 3k in a few hours.

Thx for your idea. I tried the 1.5.1 client again.
With openjdk 11.0.5, I tried to use the following command to start 1.5.1 client:

CODE

java -Dhttps.protocols="TLSv1.2" -Djdk.tls.client.protocols="TLSv1.2,TLSv1.3" -jar HentaiAtHome.jar --port=xxxx

--------------------------------------------------------------------------------------------------------------------------------------------
But obviously I was wrong. Please go to post #60 for details.
--------------------------------------------------------------------------------------------------------------------------------------------

This post has been edited by j800930: Oct 28 2019, 14:47

I have been running TLS1.2 with java 8 now and my quality is over 7k and still going up. With java 11 running TLS1.3 it went straight down to under 3k in a few hours.

The same with me.Thx.

Thx for your idea. I tried the 1.5.1 client again.
With openjdk 11.0.5, I use the following command to start 1.5.1 client:

CODE

java -Dhttps.protocols="TLSv1.2" -Djdk.tls.client.protocols="TLSv1.2,TLSv1.3" -jar HentaiAtHome.jar --port=xxxx

Now the quality looks normal. I'll keep on watching for a few days.

--------------------------------------------------------------------------------------------------------------------------------------------
Unfortunately, after only two hours about, the quality falls down to about 6.5k from over 9k and still going down.

I may be wrong, but this doesn't change a thing, because the part which defines TLS version is harcoded in HTTPServer.java

ok, after patching line 101 with:
sslContext = SSLContext.getInstance("TLS");

and starting with JAVA_OPTS=-Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2" -Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2"

looks like it's using the right one
(IMG:[anonymousfiles.io] https://anonymousfiles.io/f/Screenshot_2019-10-28_at_11.49.15_8UsYZ4D.png)

This post has been edited by 0xDEADC0DE: Oct 28 2019, 12:50