[X] My Assistant

If possible, changing the port for a 1.5+ H@H client to 443 (the standard HTTPS port) is recommended

Maybe that should be added to The Hentai@Home Project FAQ.

Is there a way to view the statistics offered in the GUI on the CLI jar?

Is there a way to view the statistics offered in the GUI on the CLI jar?

Not officially, but a custom extension could hook into the interface provided by Stats.java.

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.

I wish I could quote this at work when someone wants to use a random port due to being scared of crawlers and ends up creating a million other problems.

- Added the argument --disable-ip-origin-check that disables the requirement that RPC server requests come from a whitelisted IP. Using this is discouraged as it reduces security, but may allow H@H to work in some common non-transparent proxy configurations. Note that if the non-transparent proxy is a local network IP, speed and rate limits will not be enforced.

In <HTTPResponse.java:216> it only check if the IP is a RPC Server IP, so it's still not possible to start the server with a non-transparent proxy with --disable-ip-origin-check. I temporarily changed it to not to check origin IP. I know it brings security issue, and it need more complicated works to pass origin IP from the proxy server, but I guess I'll try.

Edit: It's not a important thing, I tried the proxy because of mtu and tcp mss caused ssl connection failure from some certain network, now I solved it so I'll just use iptables for port forwarding again.

This post has been edited by mewsf: Nov 8 2019, 04:23

In <HTTPResponse.java:216> it only check if the IP is a RPC Server IP, so it's still not possible to start the server with a non-transparent proxy with --disable-ip-origin-check. I temporarily changed it to not to check origin IP. I know it brings security issue, and it need more complicated works to pass origin IP from the proxy server, but I guess I'll try.

Hmm, right. Thanks, will fix that one for the next build.

I only signed up the other day, I have a speed limit of 2.5MB/s for the upload and 100GB of cache, my quality has gone up to 7kish and trust is at 1000 but I dont seem to be sending many files and my cache size used is only 50mb? Should I swap back down to 1.4.2 to build my cache and then go back onto 1.5.2?

I only signed up the other day, I have a speed limit of 2.5MB/s for the upload and 100GB of cache, my quality has gone up to 7kish and trust is at 1000 but I dont seem to be sending many files and my cache size used is only 50mb? Should I swap back down to 1.4.2 to build my cache and then go back onto 1.5.2?

Cache does not build faster on older versions.

Cache does not build faster on older versions.

was just wondering if this might be because of note 4 on the OP, but if not guess i'll just give it a few more days. Its got about 90MB of cache now, hopefully more as time goes on since my hit rate is like 0.1/min (probably rounded up too)

Note 4 was only really relevant the first couple of days, there are >450 live clients running 1.5 by now so this should no longer be an issue. Outside of region, the growth rate of your cache mostly depends on your quality, speed, and number of assigned ranges - the first of which is (artificially) higher for 1.5 clients.

1.5.3 Changelog

- --disable-ip-origin-check should now actually work as intended. Using this will now also disable flood control implicitly.

What is this '--disable-ip-origin-check' function?

Does it never disable 1.5.3 client to check its Country location?

What is the advantage of that function and how to turn it on when initializing H@H??

Like this?

CODE

screen java -jar HentaiAtHome.jar --port=7777 --disable-ip-origin-check

This post has been edited by Lunar Tear: Nov 12 2019, 19:45

[Help Needed]: Although the below solution works, I still want to make nginx stream proxy transparent. Currently it's non transparent, so in H@H's log all source IPs becomes 127.0.0.1, which looks ugly.

Managed to let H@H coexist with other sites on the server with nginx's TCP forwarding (haproxy, LVS and other load balancers should be able to do the same or better). A bit cleaner than the iptables port redir approach (more overhead though, but I only have one IP lol).

I appended the following stream block to my nginx.conf:

CODE

stream {
  # http://nginx.org/en/docs/http/ngx_http_map_module.html#map
  map $ssl_preread_server_name $name {
    hostnames;
    keepalive 10;
    proxy_buffer_size 600k;
    default                  others;
    *.hath.network           hath;
    *.other.domain           others;
  }

  upstream others {
    server [::]:443;
  }

  upstream hath {
    server 0.0:7777; # replace 7777 with your H@H port specified on java -jar ... --port=777 --disable-ip-origin-check; on the H@H web config, use 443.
  }

  server {
    listen 0.0:443;
    proxy_pass $name;
    # https://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_bind
    #proxy_bind $remote_addr transparent;
    # http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html
    ssl_preread on;
  }
}

The downside is that we have to change other sites to run on [::]:443.

This TCP forwarder will operate on 0.0.0.0:443 (ipv4 only because H@H is ipv4 only). Additionally, to be able to select a hostname among all the HTTPS connections, we need to preread the headers in the SSL stream, which sets the variable $ssl_preread_server_name automatically. We then can switch upstreams based on that. The port 10443 or [::]:443 can still be shared by multiple sites.

Please point out if there is any easier/cleaner way to do a transparent HTTPS reverse proxy (given the .p12 remains secret, though pointless)!

-- Update 1 --
Added `proxy_bind $remote_addr transparent;` so `--disable-ip-origin-check` should no longer be needed.

-- Update 2 --
Commented out `proxy_bind $remote_addr transparent;`. Certainly I misinterpreted how this clause works. `--disable-ip-origin-check` is still needed for the code above.

-- Update 3 --
From reading [www.haproxy.com] https://www.haproxy.com/blog/howto-transpar...-load-balancer/, it turned out that multiple parts of the network stack need to be engaged. It's my first time setting this up with nginx stream but I will keep trying when I have time.
Kernel doc on transparent proxy support: [www.kernel.org] https://www.kernel.org/doc/Documentation/ne...king/tproxy.txt

-- Update 4 --
Added keepalive in upstreams for (much?) better performance.

-- Update 5 --
I was using openjdk 13 and the quality dropped to 3k from 9k (QAQ).

-- Update 6 --
Okay the quality is back.
Now I am using

CODE

java -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2" -Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2" -jar HentaiAtHome.jar --disable-ip-origin-check --port=xxxx

thanks to 0xDEADC0DE, and the quality is climbing back up. Even though in 1.5.3, TLSv1.3 is disabled in HTTPServer.java#105, the command line options (JAVA_OPTS) are still needed for the quality to be high. Not sure if client performance will change though.

-- Update 7 --
Added `proxy_buffer_size` and simplified the config. Obviously a [::]:443 upstream works on ipv4-only servers.

This post has been edited by Drawer L: Nov 18 2019, 06:21

What is this '--disable-ip-origin-check' function?

Does it never disable 1.5.3 client to check its Country location?

What is the advantage of that function and how to turn it on when initializing H@H??

As it says in the OP, it disables the IP check for the backend RPC (C&C) server. It has no advantages unless you need to run H@H behind a reverse proxy and has nothing to do with geolocation.

Managed to let H@H coexist with other sites on the server with nginx's TCP forwarding (haproxy and other load balancers should be able to do the same or better). A bit cleaner than the iptables port redir approach.
..
The downside is that we have to change other servers to run on either [::]:443 or on another port (in the above case 10443).

Yeah, that's about what I had in mind for SNI-based filtering. haproxy would be my first choice, but nginx certainly works. Another disadvantage is of course that it adds a dependency for both H@H and your other web server, but if you only have one IP and want to run both processes on the standard port, it's probably the only option.

Thanks (IMG:[invalid] style_emoticons/default/laugh.gif)

In a server with more than 1 IPv4 address, is there any way to make H@H use an address (or network interface) of my choosing?

In a server with more than 1 IPv4 address, is there any way to make H@H use an address (or network interface) of my choosing?

You could use iptables' -m owner.

Yet, in general it is almost the same cost to have *two* VPS' with two IPs or *one* VPS with two IPs. The limiting resource is IPv4. And H@H works better on the case with two separate VPS'. See this thread for some more info

My H@H always drop quality every night (9k to 3k), then it will go back to 9k next morning. I've checked and saw this. Is it normal? (IMG:[i.imgur.com] https://i.imgur.com/3AlKZT2.jpg)

if I choose to download galleries through H@H, will my client start serving that gallery as well as my assigned static ranges? or does it not work like that?

cheers

thanks (IMG:[invalid] style_emoticons/default/smile.gif)

When is IPv6 supported?