mojira.dev
MC-137

Ping packet doesn't include host information

The ping packet used to populate the server browser doesn't include the host it is trying to connect to.

This doesn't match the rest of protocol. The host information is included in other packets and enables services (like Minefold) to host Minecraft in cloud environments.

Because of the lack of host information in the ping packet virtually hosted servers appear not to have any players when the appear in the server list "???". (Add minebnb.chrislloyd.minefold.com for an example) as there isn't any way of knowing which server the ping is intended for.

Linked issues

Attachments

Comments 3

Hi Bruce! I may not have been clear enough with the original bug report. I run Minefold and helped write most of the networking stack to run over 60,000 Minecraft servers. The server software is vanilla Minecraft. The bug is in the protocol (the language that the servers speak to clients with). Well, it's not really a bug, it's an inconsistency.

The "???" is because we don't know what host the ping packet is trying to connect to and therefore can't offer back accurate player counts.

This is intentional. I would recommend switching away from proxy servers for multiple routing and towards SRV based routing.

The ping process is very fail-fast. It's an impatient system and times out after just 3 seconds (now; it used to be much smaller). To add the host into this, the process would look like:

  • Send extra data (strings ain't small!)

  • On the server, try to read string. Spend up to a second waiting for string because packets aren't usually nice and whole.

  • If on the server we don't get a string by then, pretend they didn't have one and act normally. (For back compat)

  • [If proxy] figure out what server they asked for and route all data to/from that

  • Respond with the data ASAP

  • Assuming the client is still listening, because quite some time has passed by now, the client will measure the trip time and display that as a lagometer.

From the client starting the request, to the client finishing processing the server's response, this must take no more than 3 seconds.

Great to hear from you Nathan. However, I'm really disappointed that this is intentional and I strongly disagree with your reasoning. Firstly, let me outline some misconceptions you have. I'll then go onto explain some of the history, alternatives & benefits to virtual-hosting.

[media]
  1. "Strings ain't small". I scraped the first 10 pages of mcserverlist.net (script) and found that the average size of a hostname (including IP addresses and ports) is 17 characters. Assuming you want to encode them the typical Java way (1 byte length with UTF16 encoded chars) that would take on average 35 bytes. If you wanted to do the same but limit hostnames to ASCII characters (none of the servers in those top 10 pages had non-ASCII chars), it would only be 18 bytes. If you wanted to include the port that would be another 2 bytes.

  2. "Packets aren't usually nice and whole". For broadband connections on Windows, the default MTU is 1500 bytes. No (practical) network interface has a MTU of less than 1,200 bytes. Even with the existing magic byte, the ping response will practically never hit this limit and therefore be nice and whole.

  3. Pt 3, "Act normally". I'd propose that the hostname is always sent and always ignored by the official MC Server. It only means something if you're running a proxy (like us).

  4. "Respond with the data ASAP". Our proxy keeps an in memory cache of player counts, it can respond very quickly.

  5. "Quite some time has passed now". If our proxy isn't able to respond in about 30ms then we've failed.

Your worry that a server can't respond to a TCP request with a practical maximum of 300 bytes in 3s seem to be based on intuition rather than reason.

You mention that SRV based hosting is a viable option. We bring up servers dynamically: when nobody is playing the process isn't running. Even if the TTL was set very low, and every ISP honoured low TTLs, we just can't do this with DNS. We would have to start a server on every DNS lookup which would be very inefficient. We also dynamically adjust servers (either to move the processes around or at least hold the connection) and bill customers based on their connection to their connection to them. SRV records dictate what sort of infrastructure we should be running. It's good for traditional hosts (like Gameservers). Virtual-hosts lets us be free to experiment with more cutting-edge architectures.

EDIT: Removed misunderstanding about SRV records and slight troll.

The entire http internet is based on virtual hosting. It's a proven concept. Websites all around the world have proven reliability and performance by allowing an intermediary to act as an endpoint to the user. In a cloud environment where we bring machines are being brought up and down dynamically, buffer connections as resources are allocated etc. a virtual-hosts based proxy is a must.

In addition, the hostname and port are already included in the handshake request. It feels unusual to me that you should be so anti virtual-hosts based routing but still enable it elsewhere in the protocol.

The only work needed to make this change is to add the hostname and port in the ping-request, and then ignore it in the server. I understand that it might not seem like a massive win for Minecraft but it's a simple change that would make the 65,000 players of Minefold very happy.

Scienced!

Chris Lloyd

Erik Broes

Unconfirmed

multiplayer

Minecraft 1.4.1, Minecraft 1.4.2

Minecraft 1.6

Retrieved