@bubuche said:
Also, there is this part that disturb me :
Especially the part “including any internal handshaking”.
For me, the name of the game and its version should be a part of the handshaking, and we should have a way to add some more “handshaking” things, like a verification of a name+password or stuff like that. As this kind of stuff is not “standard”, we should have a way to do it ourself, before the “client connection” is yelled. So, what we can do is :
You do have a way to do it yourself. Register a ClientStateListener and to the validation on connected. At that point, SpiderMonkey has already determined that you are connected to the proper game name and version because without at least that you can do no communication at all. You won’t even know what messages to use.
@bubuche said:
- modify the wiki. Hey, it’s easy, but not really helpfull here.
- add a way to set a “client connection validator” which, by default, do only the standard job but can be changed to a more complete one.
- add a state to the connection like “doingAdditionnalHandshaking” so the listener will have 2 call, the first one with this new state and the second one throw by us with the “connected” state.
4.add a “session” concept above that (see below)
Right now, i don’t use the clientstatelistener for its connection part at all, i “initialize” the connection after i received and verified the “game version+name message”. So the connection is etablished in a messagelistener which is a bit
Why do you do this game version + name thing when Spider Monkey is already doing it in a way that won’t break if the message serialization is different?
@bubuche said:
strange. But, except to detect ddos the "clientstatelistener" is only usefull for the "disconnected" part. I mean : what i am suppose to initialize when i am even not sure that the client is running the right game ?
When client state listener is called you already know it’s the right game. Game name and version has already been checked. When client state listener is called, game name and version has already been checked.
The game name and version is checked before client state listener is called. You will get a disconnect error (pretty sure that’s how I notify you) when their is a version mismatch.
@bubuche said:
And right now i am even not talking about login.
And, also, make a link between a disconnection of the client’s socket and the disconnection of the client is not a good thing. I may want to have a protocole with many short connection (where the client diconnect when he has nothing to say) and have a “session” concept over it. So, even the “disconnect” part of the client statelistener should be reworked.
Then you should use a different networking API as this one is intended for persistent connections. But I’m still not sure I see what the problem is. You just have to manage your session separately from the connection objects.
@bubuche said:
If i can put my hands on connection and disconnection signals, i can "smooth" that to create a session concept (if the client reconnect soon enough and identify himself i can pretend that he didn't leave in the first time).
I CAN do it right now, but i shouldn’t need to implement myself such low level things. And if i use sessions, i would like to keep the same “hostedconnection” during it (at least keep datas i put in it).
HostedConnection has one main job: letting you send stuff to a specific client. It also provides some nice book-keeping with the session attributes. Without the connection back to the client (and the connection setup is not really cheap), there isn’t really a great reason to have a HostedConnection around. It’s super-trivial to keep your own map of state. SpiderMonkey would have no reliable way of verifying that it was the same connection coming in again anyway. You’d have to go through the whole game-specific connection process again every time. Everyone will want to do this a different way because each of them will have some way to attack it.
A game with many short lived connections may be better served by some kind of REST API on the server using standard HTTP(S) connections.
For the record, “internal handshaking” in this case is the setup of the various channels (two by default) and the client and server agreeing on what those callback ports are and such. Even a UDP round trip is performed so that the server knows where in your NAT firewall to send back UDP packets. During this process, as part of the initial message to the server, the game name and version are checked. The client is kicked if they don’t match.
When ClientStateListener is called, you will know that the channels have been fully setup and the game name and version verified. At that point, (assuming you are setting up your messages properly) you can be reasonably sure that you will not fail with strange serialization errors.
SpiderMonkey’s serializer leans towards tiny messages rather than robust messages. It’s not like Java’s serialization that sends along a ton of other data so that errors can be properly checked on the other end. SpiderMonkey has no such assurances. A message with a single string field ends up as four shorts and some character data (off the top of my head). The message size, an ID for the message class, an ID for the String class, a size, and the characters.
