Mono

[lighta]

Could you explain the "mono" into doc ?

I'm trying to rate your current implementation with the benchmark @cdelorme have gracefully provide us here : https://github.com/rathena/trojan But I'm getting some [2017-12-29 10:48:48.598] [account] [error] Unexpected PacketType 0x64 for mono::state session [2017-12-29 10:48:48.599] [account] [error] Unexpected PacketType 0x64 for mono::state session malloc(): memory corruption Aborted (core dumped)

Which I follow the account src and understand the char_server => HA AH packets. Then I was thinking I needed to add the default structure for 0x64 in client. => CA AC packet. But you have some of those packet in mono. you have some HA and CA in there. Now I followed and see it's another session_state. but just what's the concept behind that mono ??

[elelel]

All sessions that are connected to Ares servers can have different types of states. For example, account server can have character server state type sessions and game client state type sessions. The state of the session is simply a std::variant from standard C++ library. Mono is a special session state, which is "default" state, when a client connects, but it is not known yet, if it is a character server or a game client. Conceptually it is equivalent to std::monostate (http://en.cppreference.com/w/cpp/utility/variant/monostate). Change of state (e.g. from mono to client) is done within handler for an appropriate packet. Each session state handles it's own set of packet types, for example if a session is initialized to client state, it will never handle packets with ATHENA_ packet ids. The error message you are getting means that PacketType 0x64 is not known for mono session states in the selected packet version. That is probably because that packet was not used in the client I programmed against. For the current supported packet ids you can check packets/src/base/pacekt_ids.hpp file.

[lighta]

alright so it's an undefinedstate. thank for reference. (I usually just put unknow but that good)

[cdelorme]

I coded trojan to use 0x0064, ares seems to use 0x0825.

https://github.com/elelel/ares/blob/master/packets/src/base/packet_ids.hpp#L14 https://github.com/rathena/rathena/blob/master/src/login/loginclif.cpp#L534

Creating tests or benchmarks across the various supported commands would be exponentially more complex than supporting just one. I'm assuming the same conclusion applies here, as 0x0825 appears to be the only supported command in the listed constants (though I have not read the code dealing with the login so I could be totally off).

[elelel]

Surely 0x64 should be added to the base packet version of Ares, I just didn't code it in at the time of writing that code. It's totally ok for the tester to include only one type of login.

[elelel]

I'll write a template for 0x64 now, but won't be able to actually test it.

[cdelorme]

I believe the long term goal of trojan would be to support all code paths, otherwise checking for regressions will not be possible. Same situation as you though, I didn't have enough time (or knowledge) when coding the first draft.

If you want to add 0x0064 that would be awesome, since I think the goal is to see how much better asio is. Whether we use the default login method or the token based authentication method are irrelevant to that.

[elelel]

I've drafted 0x64 support in 1024f4a, but did not check if it actually works. Most likely it has bugs.