Neptune Game

by: burt rosenberg
at: university of miami

   %
    \
 \O/ \
  |  
 / \    _n_ _e_ __ _u_ _n_ _e_
~~~~~   you have 2 guesses left. 
>{/}> 

Objectives

Using the netbounce code are a starter, create a hangman like game using client-server computing. This will demonstrate the elements of creating an application layer protocol in the client-server discipline. The protocol proceeds in rounds, with two messages in each round: a request from client to server, with a reply from server to client.

A message is a buffer of bytes with strictly defined fields. The zero-th byte of the buffer is the operation code. The rest of the buffer might have different formats depending on the code.

Some messages require a parameter following the operation code. In this protocol, if there is a parameter it is one byte. Depending on the operation, finally there is a text string. The text string is a C-string of non-null bytes terminated by a null byte.

These are standard elements of packet type protocols, which you will experience with the project.

Man Page

NAME
    neptune, neptuned
    
SYNOPSIS
    neptune [-v] -p port -h host
    neptuned [-lv] -p port _secret_word_
    
DESCRIPTION
    Play a hangman-like game called neptune with client-server computing.

    The client is run and is presented in interact menu with commands:
        s:     :to start a new game
        g _c_  :to guess the character _c_
        q      :to quit, both and possibly the server (-l option on server)
    
    The neptune daemon runs with a secret word that is to be guessed by the
    the client. The server returns for each guess the formated string and possibly
    ASCII art, and the number of remaining guesses.
    
    When there are no more guesses the server will not update new guesses.
    
PROTOCOL
    The client-server protocol is a simple packet protocol with the first byte
    an operation code, optionally followed by a single byte parameter, optionally
    followed by text.
    
    CLIENT->SERVER
    -----------------
    OP_HELLO
        +---+------------------------+
        | 0 | hello text\0           |
        +---+------------------------+
        
        Sent from client to server to establish connection. Client must receive
        an OP_HELLO_R reply.
      
    OP_RESET
        +---+
        | 2 |
        +---+
      
        Sent from client to server to clear the game board for a new game. Client
        must receive an OP_BOARD reply.

    OP_GUESS
        +---+-----+
        | 4 | _c_ |
        +---+-----+
      
        Sent from client to server to announce a single letter guess. Client must
        receive an OP_BOARD reply

    OP_ABORT
        +---+
        | 8 |
        +---+
      
        Sent from client to server to suggest and end of the game. Server does not 
        reply. Server daemon might exit.

    
     SERVER->CLIENT
     -----------------
     OP_HELLO_R
        +---+------------------------+
        | 1 | hello response text\0  |
        +---+------------------------+

        Sent from server to client in response to an OP_HELLO
        
     OP_BOARD
        +---+------------------------+
        | 3 | _n_ |  board string\0  |
        +---+------------------------+
        
        Sent from server to client in response to an OP_RESET or OP_GUESS. _n_ is the 
        number of guesses left, as an unsigned char.

     OP_ERROR
        +---+------------------------+
        | 9 | error text\0           |
        +---+------------------------+
        
        Send from the server to client in response to any operation, in case of error.
    
    
    
BUGS

HISTORY
    Created for the 222 (January 2022) edition of csc424.
    Last updated on: 6 February 2022

Project Overview

Netbounce is a key element. Netbounce sends a packet to a listening server, and the server replies. In the case of Netbounce, the server does minimal computing on the body of the bounce packet; it simply copies the body of the packet and returns to sender.

The Neptune protocol will make use of these message rounds to communicate when a game begins, the progress of the game, and optionally when a game ends. The first byte of each packet will be an integer that gives the message type. Each request will have a reply.

The first round is an hello exchange, where the client requests an hello from the server, and the server replies with an hello. The hello message pair can happen at any time. It is a bit useless in this protocol.

The main round is a guess message where the client formats a packet with the guess operation code followed by a character. This is the guess and the server will respond with an updated board. The return board message begins with the operation code for a board message, followed by a one byte integer of the number of guesses remaining, followed by the graphic representation of the game board.

There is also a reset message round where the client formats a packet with the reset operation code as the first byte, and the server clears its internal memory of the game, and returns a board message (of the completely cleared game board).

For the possibility of an error, the server can respond with an error message rather than the required response in a message round.

The code has been divide up for you in six files,

Internal server state

The server holds all the state of the game play including the current guess board and the number of remaining guesses. After the server records there are no more guesses, the guess messages do not update the state. The board is returned to the client in the format such as,

_ e p _ _ _ e
That is, separated by a single space a letter or an underscored, where underscores indicated unguessed letter positions.
Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Author: Burton Rosenberg
Created: 6 Feburary 2022
Last Update: 8 March 2022