[Minetest-dev] Protocol version 25 design
mtest31 at yandex.com
Sat Apr 11 19:39:38 UTC 2015
I have seen your changes in the code, and I agree to the TOCLIENT_ACCESS_DENIED change. The TOCLIENT_DELETE_PARTICLESPAWNER change doesn't touch the early protocol I'm changing right now. I like the TOCLIENT_AUTH_ACCEPT and TOCLIENT_HELLO changes.
I agree that the server should be kept compatible with the old protocol (this is a must!).
The opcode TOCLIENT_PASSWORD should be removed I think, because when the client changes their password, it should be srp only, not the old hashed method. My PR will add another opcode instead which manages SRP setup. Only TOCLIENT_PASSWORD_LEGACY should remain for compatibility with older <=24 clients.
I want to release the PR this night (still non-functional), perhaps we can then discuss more about it.
For the implementation of srp, I have ported csrp (https://github.com/cocagne/csrp) from OpenSSL to Libgmp on request of hmmm, to lessen the burden. I will also add the required srp opcodes.
I have designed a system, where the server looks up the player's database entry and determines whether the user is new, has the old password hash, or the new srp verifier. Then it sends the client a list of choices the client can do (extensible for future additional authentication methods), so that
About the TOSERVER_AUTH package. As srp consists of multiple messages which are sent back and forth, the password field has to be removed. The only thing this message would send then would be the player's name. The server has to know the player's name in order to send it the authentication mechanism list as described above, and only thereafter auth can start, so we have two options now:
1. After TOSERVER_INIT and TOCLIENT_HELLO, there is a TOSERVER_PLAYER_NAME message which only contains the player's name. The server answers with a TOCLIENT_AUTH_METHODS message which only contains the auth methods and a legacy username (this is the approach from my last email)
2. (which I favour) The playername is sent in TOSERVER_INIT, and the auth methods and the legacy username are sent in TOCLIENT_HELLO.
For both options, the authentication then starts upon choice of the client based on the list of authentication mechanisms sent by the server.
I agree that option 1. would be "cleaner" in the sense that future implementations with a centralized login system wouldn't require to send an empty username. However, it adds two additional messages to the protocol, isn't required for a centralized login system, and it isn't even decided yet whether to implement such login system at all. It not only makes the protocol more complicated (and the implementation), it also adds additional waiting time to the login process. Therefore I think option 2 is the better one.
07.04.2015, 17:52, "loic.blot at unix-experience.fr" <loic.blot at unix-experience.fr>:
> as i see est31 wants to talk about protocol version 25. I think we need to design it before coding more implementation to be sure we go to the right way.
> The first step is implemented server side, i cutted TOCLIENT_INIT_LEGACY in two parts, TOCLIENT_HELO which send only the server version and some supported things, like compression modes (server presentation to client) and TOCLIENT_AUTH_ACCEPT to answer the client that the authentication was accepted.
> Some packets have been added to fix some design issues:
> TOCLIENT_ACCESS_DENIED has a new opcode and use now a code to define the client-side error. One code permit to read a custom error string, for compat with Lua modes. old packet is now named TOCLIENT_ACCESS_DENIED_LEGACY.
> TOCLIENT_DELETE_PARTICLESPAWNER has a new opcode permit to fix the u16 read which must be a u32 read. The old packet was suffixed as _LEGACY.
> TOCLIENT_PASSWORD has a new opcode and use a dynamic string size instead of static size. Old packet was suffixes as _LEGACY.
> The server is now fully compatible with old and new protocol design, as designed at this moment.
> est31: you want to work on SRP, why not, it's also used on World of Warcraft if i'm right. Look at mangos emulator for server side implementation (the database contains 3 fields, a sha1 hash, the P and the V).
> I think we must change one thing in the server code: health and breath handling should be server side the client prediction is a pain and the server should send events to client when happening.
> If there are more suggestions on the protocol itself, please tell me.
> Minetest-dev mailing list
> Minetest-dev at lists.minetest.net
More information about the Minetest-dev