Skip to content

Network Protocal Description #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ScriptCoder opened this issue Feb 21, 2013 · 13 comments
Open

Network Protocal Description #5

ScriptCoder opened this issue Feb 21, 2013 · 13 comments
Assignees

Comments

@ScriptCoder
Copy link
Member

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

/******************************/
/*NETWORK PROTOCAL DESCRIPTION*/
/*           (NPD)            */
/******************************/

/*
    INTRODUCTION:
        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.

    TERMINOLOGY:
        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:
                msg_code[(option_name:data;)+]
            If there is no data the ':' and ';' characters will then be side by side.
            All whitespace is ignored.

    MESSAGES:

    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.
                -Options
                    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.


    COMPILED CODE FORMAT:
        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.

@LB--
Copy link
Member

LB-- commented Apr 19, 2013

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?

@Thumperrr
Copy link
Member

Luc Leiber has started really far into that
https://github.com/LukeLeber/ChessPlusPlus/tree/unstable_networking/include/network
He's been MIA lately, taking care of personal business.

@LB--
Copy link
Member

LB-- commented Apr 19, 2013

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.

@Thumperrr
Copy link
Member

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

socket << data;

@LB--
Copy link
Member

LB-- commented Apr 19, 2013

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

@Thumperrr
Copy link
Member

Where's the fun in that? :b

@LB--
Copy link
Member

LB-- commented Apr 19, 2013

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

@Thumperrr
Copy link
Member

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

@ScriptCoder
Copy link
Member Author

"I don't really see how the protocol you have laid out here would work, it
also seems incomplete"
I did not spend much time one it, just tried to give a suggestion. As I
said before I am at a loss as to what to help with.

On Fri, Apr 19, 2013 at 8:53 PM, Thumperrr [email protected] wrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/naraku9333/ChessPlusPlus/issues/5#issuecomment-16676271
.

@LB--
Copy link
Member

LB-- commented Apr 19, 2013

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.

@ScriptCoder
Copy link
Member Author

@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.

@LB--
Copy link
Member

LB-- commented Apr 19, 2013

https://github.com/udp/lacewing/blob/0.2.x/relay/current_spec.txt
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.

@ScriptCoder
Copy link
Member Author

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

Thumperrr pushed a commit that referenced this issue Apr 21, 2013
Pull in src readme changes
@ghost ghost assigned LB-- May 14, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants