Server starting by just visiting the multiplayer server list.

[PabloMK7]

The server is just starting by visiting the multiplayer server list, this is due to the client requesting the amount of players online as well among other info.

[gekigek99]

(are you using the lestest release right?)
yep i am aware of this problem.

It happens because this program is something completely not integrated in the minecraft server: it just listens for incoming connections and starts the server.

i tryed to solve this issue since version 1 but i wasn't able to find a never-changing packet of data representing a "real" user trying to join (to use as a reference for the start-server signal)

for what i understood (not completely sure tho) the client-server packets are encrypted in some way so this, "connect me!" string is always changing (BUT I HOPE TO BE WRONG).

anyway... when i have time i'll retry the experiment

[gekigek99]

if you are willing to help me you can just tweak a little the code so that the python prog writes to txt file everything that is sent and received and from there we can find the "connect-me!" string

[PabloMK7]

Sure! I'll do some testing in the next days, I just hoped you had some more information on how the communication is handled ^^'
By the way, I don't think manually redirecting data from one packet to another manually is a good idea, I've tested it and the performance decreases A LOT. (Even more noticeable on a raspberry pi, where the python interpreter is just too slow) Have you considered the possibility of using some kind of port redirection instead. (If that's even possible)

[gekigek99]

good! thanks for the support
what do you mean manually? do you mean redirect the traffic from one port to an other with a python script?

could you make an example of what are you thinking with port redirection? (because this script in the core is actually a very simple port forwarder)

[PabloMK7]

I mean, you take 1KB of data and forward it to the other port, however this process is slow and makes the connection between the client and the server be very laggy. If there was another way without involving python doing the job manually (like some builtin function to redirect data) then it may improve the overall performance.

[gekigek99]

well i never thought about that but it seems reasonable... it's important for bigger servers or for not that powerful hardware.
(still... if you measure the kb per seconds per player are like 8kb/s (except for the first second where it reaches 1mb/s))

the only problem is that python, since must have some logic in it (like when to start, when to stop, number of players ecc...), must be able to read (or at least have some feedback) some data.

we could make something like:

• python listens for the join signal from the client (which we need to find) (mean time it just handle the port redirection by itself)
• when it receives the join signal it makes a kind of system call asking for the system to manage the datatraffic
• python keeps track of how many system calls are active (meaning the player is online) and when it reaches 0, it starts the 60 sec countdown to stop the minecraft server

is it reasonable something like that?

[gekigek99]

or we could write a c/c++ program (that should be more efficent) to handle the redirection operations.
(i have to admit i have never programmed such a thing, but i think it's a pretty straight redirection thing that can be found somewere on internet)

this could be really helpful to write multiple programs listening on the same port:
https://lwn.net/Articles/542629/

[gekigek99]

(but for now i think its great if we can solve the initial issue, then from there we can make it more efficent)

[gekigek99]

i may have found our "connect me!" bytes:
the very first 17 bytes sent to the server from the client change by one byte depending if it's just requesting server info or it's actively trying to join the server.
here is the "send info" sequence:
b'\x10\x00\xc2\x04\t127.0.0.1c\xdd\x01'
here is the "connect me!" sequence:
b'\x10\x00\xc2\x04\t127.0.0.1c\xdd\x02'

(look at the 17th byte ehehehe...)
ahahahahah i think i got it!

this evening i am going to implement the solution hopefully

[gekigek99]

i uploaded the new version without the problem!

fell free to check it out and try to find possible errors!

[gekigek99]

see 3c06072 commit
(also 3699c6e commit)