Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Network Protocal Description #5

ScriptCoder opened this Issue · 13 comments

3 participants


Might be too early for this, but I was bored and so I wrote this.

/*           (NPD)            */

        I believe that the game should use a simple, but 
        concise way of communicating data. For this reason
        I have decided to suggest a simple command type system,
        that could be easily written, but is then "compiled" to
        a more concise form.

        Throughout the rest of this description the following term will be used:
        Client: The program sending the message.
        Server: The program recieving the message. (Could be a main server or a peer)
        (NOTE: Both playing applications will take the role of both the client and server
               in every session)

        Message Options are given as follows:
            If there is no data the ':' and ';' characters will then be side by side.
            All whitespace is ignored.


    Communication Messages:
        H377O   Message sent by client to server to initiate converation. 
                (Note the 'O' is a capital 'o' and not a zero)
                [Compiled to 0x405D  (CPP base 36 in base 16, I think)]

        H3Y     Message sent by reciever of H377O message.
                Sent only if reciever is willing and able to play.
                [Compiled to 0x4ooo]

        busy    Sent by reciever in response to a H377O message.
                Sent only if reciever is unwilling or unable to play.
                [Compiled to 0x4ooo]

        bye     Sent by client to server indicating that the client has closed the
                connection, and that the server must stop sending messages.
                [Compiles to 0x4ooo]

        error   Message sent by client to server indicating that there has been an error.
                    n       no message
                    m:s     a string is attached with information of the error
                [Compiled to 0x404D]

        readyornot  Sent by client to server indicating that they are ready for the game to commence.
                    [Compiled to 0x4ooo]

        ready   Sent in response to readyornotmessage, indicating that client is ready.
                [Compiled to 0x4ooo]

        wait    Sent by client to server indicating that they are busy, and will send next message
                when the client is free. (Recievers of this message are expected to wait until they
                another message, however, recievers should end session if wait time exceads 5.0s)
                [Compiles to 0x4ooo]

    Out-Game Messages:
        Handles info like score, game type, colour.

    In-Game Messages:
        Handles info solely related to the movement of pieces.

        All Communication messages are prefixed with 0x4, Out-Game messages 0xA and In-Game messages 0xE
        All message codes are compiled to two bytes, followed two bytes indicating how many optional bytes
        there are following. The optional bytes format is as follows:
            (option_name ':' option_data '\0')*


I have included the whole file here, because I do not know how to add a file to the repository.


At some point I want to take on the responsibility of networking - I already have a lot of experience and it would be a fun challenge.

I don't really see how the protocol you have laid out here would work, it also seems incomplete.

I already have plenty of plans for how to do the networking and sever/client logic, I hope you don't mind me going in a completely different direction from what you have laid out here?


Luc Leiber has started really far into that
He's been MIA lately, taking care of personal business.


Wow, that's impressive - but at the same time it seems really overcomplicated. I'll work on my own and then we can pick the best out of each other's, then.


It's overly complicated because he's encapsulating everything and getting it to where it's as simple as

socket << data;

There are already high-level networking libraries that abstract even that ;)


Where's the fun in that? :b


The goal is simplicity and elegance, right? We're trying to show C++'s true power with this project, aren't we?


I'm not disagreeing with you.
Just playing devil's advocate.


As I said before I am at a loss as to what to help with.

You can suggest design decisions and discuss them - one of the most challenging things is actually making these decisions, and your input is valuable.

After all, we're all at the same level just trying to please the gods naraku and Thumper.


@LB-- What protocol did you have in mind? In my design I just wanted to highlight the fact that the protocol should be lightweight and optimized.

It fits the project nicely, as it does most things. It also already has a C++ implementation :)

A ChessPlusPlus server would have to support multiple games (multiple channels) with up to two users and an infinite number of spectators per game.


I never knew about that, it looks good, and captures exactly what I was trying to do :)

@LB-- LB-- was assigned
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.