[X] My Assistant

I can keep my client on 10000 Quality with jre11 most of the time.

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

Haha, actually, I didn't check if the parameters are in effect. You should be right.
I have simply additional installed the unstable package openjdk-8-jre version 8u232 and starting the 1.5.1 client with it.
After a while, I will look at Quality again.

------------------------------------------------------------------------------------------------------------------------
Although quality looks normal with openjdk 8u232, I got a lot of warn:
[WARN] java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)

I remove it, downgrade dependency package, then update package libnss3 from 2:3.42.1-1+deb10u1 to 2:3.47-1.
Test starting the 1.5.1 client with openjdk 11.0.5 again.

This post has been edited by j800930: Oct 28 2019, 19:05

Unfortunately I don't have a way to see what Java version/TLS protocols clients use, at least without probing them directly which would take some effort, but after some experimentation on the test clients, it does actually seem to make a significant difference for some reason - not enough for the test clients to drop below 10000 quality but enough to be evident in the raw numbers. Seeing as Java's TLSv1.3 implementation is kinda shit and doesn't actually support 0-RTT which is its main selling point, I'll probably disable it for now.

Edit: 1.5.2 was released. The only change is disabling TLSv1.3.

Going back to 1.4.2 got me back to >7000 quality again. Guess I'll stay there for now

Going back to 1.4.2 got me back to >7000 quality again. Guess I'll stay there for now

Could try 1.5.2 instead if you are using Java 11. 1.5 does average a higher (adjusted) quality than 1.4, so unless you were hitting the TLSv1.3 quality issues, I'm not sure why it would drop for you.

Could try 1.5.2 instead if you are using Java 11. 1.5 does average a higher (adjusted) quality than 1.4, so unless you were hitting the TLSv1.3 quality issues, I'm not sure why it would drop for you.

I'll try 1.5.2 with the same port I had on 1.4.2 and let it run for a few days and then see how it goes. I'm indeed running java 11 btw.

updated 1.5.2 version..

still quality drops (IMG:[invalid] style_emoticons/default/sad.gif)

updated 1.5.2 version..

still quality drops (IMG:[invalid] style_emoticons/default/sad.gif)

All your clients seem to be at 9000+? (no meme intended)

All your clients seem to be at 9000+? (no meme intended)

before 1.5 version update,

my clients had top quality

after update, their qualities fall to 6000~8000 in GMT 15:00~18:00

This post has been edited by hellweekdays: Oct 30 2019, 10:16

1.5.2 seems to behave a lot better for now than others from 'SSL update'.

1.5.2 seems to behave a lot better for now than others from 'SSL update'.

I can only agree. Since my update to 1.5.2 yesterday I'm back at 9,5k+ quality even with a non 443 port. If that doesn't change in the next few days, I guess I'll stay at 1.5.X

I use 1.4.2 before update my client had 10k or 9k quality

but release 1.5.x i update my client

now my client had 7k~3k using 443 port or non 443 port

Can I use 443 port in H@H if I host HTTPS websites on my servers running H@H?

Can I use 443 port in H@H if I host HTTPS websites on my servers running H@H?

Not unless there is a separate IP for H@H. (Technically you *could* have a reverse proxy use SNI to distribute requests between your webserver and H@H, but the quality hit of running on a non-standard port is insignificant compared to the hassle of setting that up and additional complexity of running it.)

On the other end of things, in my browser (Chrome 78) I'm getting an SSL error maybe every 1/10 times I view a gallery page or try to download a full resolution image. Refreshing does work most of the time.

"OPENSSL_internal:WRONG_VERSION_NUMBER"

Edit: This of course mostly happens when I have images set to load from the H@H network, but still rarely seems to happen even if I don't.

This post has been edited by fallen_mei: Nov 2 2019, 03:27

I never checked the News section and H@H 1.5 came as a surprise, I learnt it's a thing just now.

So I guess this is the reason my upload speed has dropped to below 100kb/s recently? I have tried contacting my ISP, checking router to see if my roommate has been pulling my leg to no avail... Will try 1.5 asap

I had been running 1.4.2 since that version became available. I noticed that somewhere in the last two weeks, the hit rate on my HatH at dropped to almost nonexistent. The sever access curve had gone from variably busy to a hit or 2 every 5-8 minutes. I've seen behavior like this when my ISP reset my connection or when I've performed an OS reset for the first few minutes. After about two days I was reading up on the 1.5 branch and setting that up hoping this was related to the problem. After another day or so the hit rate is still poor and it looks like some other thing is afoot.

I've been running the HatH client on a windows 10 box with regularly updated oracle java 8.

I have not changed the open port have been using to the https port as of yet. I have not yet looked into using the open java I've seen mentioned here.

Though my client's trust is +1000 and the quality 10000, currently the hit rate/hath rate is 1.4 per min/0.0 per day.

I could use some guidance. Thanks.

mithwyrm

On the other end of things, in my browser (Chrome 78) I'm getting an SSL error maybe every 1/10 times I view a gallery page or try to download a full resolution image. Refreshing does work most of the time.

"OPENSSL_internal:WRONG_VERSION_NUMBER"

Edit: This of course mostly happens when I have images set to load from the H@H network, but still rarely seems to happen even if I don't.

If it happens with H@H turned off or when downloading full-resolution images, it's not related to H@H, and almost certainly something on your end.

I have a problem compiling hath 1.5.2 due to broken characters at hath/base/ProxyFileDownloader.java:66.

CODE

/home/dcnick3/.cache/yay/hath/src/src/./hath/base/ProxyFileDownloader.java:66: error: unmappable character (0xE2) for encoding US-ASCII
                // this will NOT work with HTTPS (see FileDownloader), but upstream can be kept as HTTP so This Is Fine???
                                                                                                                       ^
/home/dcnick3/.cache/yay/hath/src/src/./hath/base/ProxyFileDownloader.java:66: error: unmappable character (0x84) for encoding US-ASCII
                // this will NOT work with HTTPS (see FileDownloader), but upstream can be kept as HTTP so This Is Fine???
                                                                                                                        ^
/home/dcnick3/.cache/yay/hath/src/src/./hath/base/ProxyFileDownloader.java:66: error: unmappable character (0xA2) for encoding US-ASCII
                // this will NOT work with HTTPS (see FileDownloader), but upstream can be kept as HTTP so This Is Fine???
                                                                                                                         ^
3 errors

Please fix it to ease the compilation process.

I have a problem compiling hath 1.5.2 due to broken characters at hath/base/ProxyFileDownloader.java:66.

CODE

/home/dcnick3/.cache/yay/hath/src/src/./hath/base/ProxyFileDownloader.java:66: error: unmappable character (0xE2) for encoding US-ASCII
                // this will NOT work with HTTPS (see FileDownloader), but upstream can be kept as HTTP so This Is Fine???
                                                                                                                       ^
/home/dcnick3/.cache/yay/hath/src/src/./hath/base/ProxyFileDownloader.java:66: error: unmappable character (0x84) for encoding US-ASCII
                // this will NOT work with HTTPS (see FileDownloader), but upstream can be kept as HTTP so This Is Fine???
                                                                                                                        ^
/home/dcnick3/.cache/yay/hath/src/src/./hath/base/ProxyFileDownloader.java:66: error: unmappable character (0xA2) for encoding US-ASCII
                // this will NOT work with HTTPS (see FileDownloader), but upstream can be kept as HTTP so This Is Fine???
                                                                                                                         ^
3 errors

Please fix it to ease the compilation process.

Just remove the comment yourself.

That's a silly java parser to check comment encoding. How you actually managed to install a non-utf java parser (by default even very old java is utf-16)?