Jerrylum
commented
2 years ago Hmmm, oh yea, I just remember a thing. Could you please start a local server on your computer, then try to connect it? if you can connect to a local server but not a remote server, then here's why:
In fact, did you know when you are trying to connect to a remote minecraft server, for example "minehut.com", you are trying to connect to "_minecraft._tcp.minehut.com" instead?
Here is the implemenation in net.minecraft.client.multiplayer.resolver.ServerRedirectHandler class:
You see, every time you connect to a Minecraft server, the client tries to resolve an SRV record first. If the client finds something, it uses that address, otherwise use the original one.
The reason why this is a thing is that you can separate your web server and Minecraft server easily. For example, you can browse the website and join the Minecraft server at the same domain name "minehut.com" but they actually have a different IP.
Unfortunately, Quarry doesn't have this feature. As a result, you might want to change your connect address to "_minecraft._tcp.2b2t.org" manually.
For me, I used the library "minecraft-protocol" on Node.js because I like Typescript they fixed the problem. Here is my project:
https://github.com/Jerrylum/2ndDevice
I was also inspired by LiveOverflow to make a mirror proxy. It allows you to control one player on two Minecraft clients. I first wrote my project in python with Quarry but then rewrote it in Typescript Node.js with minecraft-protocol. If you're comfortable with Javascript, you can clone the Proxy I wrote in my project and start working on it.
robigan
Copyright for this image goes to Jerry Lum
3arthquake3
LiveOverflow
Hello there, before diving in. I am making this issue here for 2 reasons. 1) To ask @LiveOverflow's opinion on the matter as he may have already encountered this time out issue and/or help him out with developing this series (For LiveOverflow, if this issue helped you I would really appreciate a shoutout :) and 2) A place to document my findings relating to this issue that shares my same goals. With that out of the way, let me get started.
Ever since the first episode, I was inspired to make a proxy for 2b2t which allows me to host the program on a remote server, use my MC client to connect and initiate a "queue wait" and then disconnect, only to reconnect once I am fairly into the 2b2t queue. I decided to use Quarry as it was easy for me to work with Python.
When I tried to make a simple proxy using episode 1's sample code. I got an issue, I was getting an SSL error. This was simply patched by setting the env variable SSL_CERT_FILE to a location with trust roots setup like so
SSL_CERT_FILE="/Users/MY_HOME_FOLDER/homebrew/lib/python3.9/site-packages/certifi/cacert.pem" python3 ./src/proxy.py -b 2b2t.org(See https://stackoverflow.com/questions/33602478/how-to-handle-openssl-ssl-error-while-using-twisted-web-client-agent-on-facebook).This led me to a second issue, when trying to log into the remote server via the proxy. I would get timed out, I searched this issue up about setting up online server proxying, this led me to the issue https://github.com/barneygale/quarry/issues/135 and the sample code published by @JerryIum but to no avail I got the same issue with the timeout. I decided to turn on more advanced verbose logging by setting
logging.basicConfig(level=logging.DEBUG)in my main function. But this wasn't enough, going through Quarry source code. I found that the protocol.py file in the net directory contained the base class for Factories (Factories are functions which initiate classes for you). In which it had a property called log_level which could be set to the enums exposed by logging to turn on more verbose logging. This is the output I finally got when launching my proxy serverIn this log, we can clearly see that there's no logging by the Upstream. So unless the upstream is dying inside with the verbosity I set it, it's basically doing nothing.
Auditing Quarry source code, I found 2 interesting things. When creating a connection using a proxy. The function (in proxy.py) called downstream_ready() is called once the client has connected to the proxy, that function calls it's connect function which causes the upstream proxy to connect. One issue I noted was that in all circumstances, the proxy creates an Offline profile to connect to all upstream servers. This is an issue as this means the connect function needs overwriting. Or specifically, the make_profile function needs overwriting so that we may introduce an Online Profile. Last thing, under normal circumstances, once the upstream has connected. It calls the bridge's upstream_ready function, this function enables forwarding by default which causes "Packet handlers in the Upstream and Downstream cease to be called". This hints to the fact that the Quarry dev has intended for developers to write their own authentication functions on the Upstream and Downstream functions. And once the connection is complete, for the rest of the logic to be handled by the Bridge. Personally, to solve this issue, I intend to grab the access token from the client when connecting to the Downstream and then send that to the Upstream for use with connection to remote servers.
Attached is the current state of my proxy.py