Sorry I've been neglecting you guys with updates. I've barely taken ten minues away from my editor in the last few days. Not all of it has been Thud time, either, though I'd have liked it to be. We've got other clients, and they need dealing with.
I am also working on the largest update to Thud so far, and it's a bloody nightmare.
Competitive client-server dialog, particularly when the server acts as a go-between for two clients, is a nontrivial problem. Our server is currently over 1,400 lines. The client is more than 5,400, for a board game with very simple rules. The rules checking and implementation is less than 100 lines in both server and client.
The server cannot assume that the clients are in any way sane: they could quite possibly be badly (or maliciously) programmed third party programs or bots, subject to bugs like spammy dialog loops.
Of course this means that neither client can assume their opponent is sane, or has any decent grasp of the current game or dialog state.
Also, no client can assume that the opponent client received any messages that were intended for it: the server may have been down, their client may have crashed and they logged back on...
Worse, no client can even assume that it is sane itself: the server is ALWAYS right, no matter how wrong it seems.
However, neither client can assume that the server knows anything: it can quite possibly have just been crashed and restarted and forgotten all about them.
So when server or client gets a message, they need to perform a set of sanity checks on the message parameters, then interpret it in the context of previous messages.
As well as interpreting messages that arrive, they also need to deal with messages that do not arrive, and the repercussions. This is because there is no real concept of a continuing dialog: the client or server could come along into the middle of the dialog, getting an "accept challenge" without ever seeing a challenge sent. Or the opposite could happen, and a challenge could be sent but never gets a reply. Or a move for a game that doesn't exist.
Also, multiple dialogs may be in progress at the same time. So you need to deal with the case where Andy challenges Bob at the same time that Bob challenges Andy.
Finally, messy though it makes things, the user is a part of the dialog. This means that response times can be large, and that messages may be repeated (hammering on the "challenge" button, for example).
In a competitive environment, it also means that people will try to cheat. They will abandon games they are losing in order to retain their position in the league, try to move out of turn, try to move to invalid places, try to end a game while the score's in their favour...
And where there are humans, there will be assholes. Spammers, stalkers, harassers. Foulmouthed people. People that other people simply don't like.
All these issues need to be dealt with gracefully.
Not all these issues can be satisfactorily addressed at server-dialog level. Where they rely on exploiting mechanisms, those mechanisms can be secured and ruggedised (so I'll be implementing things like a curse filter, ignore ability, secure trading, IP hiding, talk/repeat rate limiting and so on and so forth). Where they rely on social factors (eg scamming, general harassment), only human policing can resolve them.
All in all, it's the programming equivalent of a jigsaw with hundreds of identical fiddly cardboard pieces, and only a sketchy picture of what it's meant to look like in the end.
And to decide that you'll try to implement all these issues in Java 1.1 without even Swing, is the programming equivalent of doing that same jigsaw puzzle, underwater.
Have you considered making your messages bulletproof?
There are techniques you can use to guarantee delivery. This will help immeasurably with syncronisation.
It's hard to say more without the protocol details, but my opinion is that moves should be fully transacted.
Re: Day 25: the dialog takes shape.
[quote="Dewi Morgan"]The client is more than 5,400, for a board game with very simple rules.[/quote]
I think I remember that Trevor once said that invalid moves are valid too, as long as your opponent doesn't spot them. Still, the sane thing to do on a server is to enforce the rules, I guess
Just for the record, ThudBoard is about 1850 lines, including everything (yes, comments too), but TB doesn't check any rules (which was great when the Koom Valley rules came out, that only required me to make the Rock moveable
)
Ciao, Mc!
The rules checking is actually startlingly small. It's the client-server interaction that takes thevast majority of the code.
It's not possible to make a dialog bulletproof since you can't tell for sure if a client has disconnected or not. So the dialog relies heavily on acknowledgement messages back from the client. Which means it must be stateful, and cient and server may believe they are in different states.
For example, the server may believe that you are in the middle of a game, and it has just sent you a move and is waiting for a response.
Your client may believe, on the other hand, that you never started that game, and in fact it has just connected and challenged a totally different player, and are waiting for an acknowledgement of the challenge.
In this conflict of beliefs, the database is always right... so if the client or server notices that they are confused, they request a status update from the DB, which refreshes both their world views.
...except, in that case, you shouldn't be forced to play a game if you have got bored and closed it. So instead that game is marked as suspended.
About the only significant improvement in the dialog that I can think of would be sending "hurryup" messages when there has been no "ACK" response in a reasonable amount of time. That would let the acknowledging party know that they missed something.