CSE 132 (Spring 2015)
Lab 5: Battleship!

In this lab you will implement the Battleship game, whose protocol we designed together in class.

Introduction

Programs communicate across the Internet by using protocols, which specify the order and content of messages. In class, we discussed various aspects of such a protocol for telling a HaWUp server that it should perform one of a prespecified set of tasks. The result of that discussion appears below.

In writing your server, it is important that you conform to this protocol. Failure to do so will prevent the client from communicating with your server, and a crash or failure of some sort will surely ensue. There are two aspects of a protocol that are especially important:

Some types of data and their associated Java DataOutputStream and DataInputStream methods are summarized below:
Description send receive
A single byte void writeByte(int) byte readByte()
Two-byte integer void writeShort(int) short readShort()
Four-byte integer void writeInt(int) int readInt()
Java String void writeUTF(String) String readUTF()

Protocol

The server and client observe the following protocol. Any information appearing in quotes, such as "example" is sent as a String.
Server Client
Makes service available at port 3001 and waits for a connection  
  Connects to the server at port 3001
Spawns a new thread to service this client  
  Sends the following:
  • This client's name as a String. It will help if this String is something unique.
  • The password for connection "xyzzy", as a String
  • A one-byte integer indicating:
    0
    The client just wants to observe what is going on
    1
    The client wants to join in a game
Reads in what the client sent. Send the following:
  • A String with this server's name
  • A one-byte integer that indicates
    0
    You are an observer
    1
    You are the first of two players to form a game. Your player id is 1
    2
    You are the second of two players to form a game. Your player id is 2
 
The observer story continues after this table. The player story continues below
  Waits for next message from the server
Send the following game configuration message:
  • The string config
  • The number of rows on the board, as a two-byte integer
  • The number of columns on the board, as a two-byte integer
  • The number of ships as a one-byte integer
  • For each ship s, then send
    • The length of s as a one-byte integer
 
  Receives the game configuration message and responds with the following ships placement message:
  • For each ship s
    • The orientation of ship s as a one-byte integer:
      • 0 means horizontal
      • 1 means vertical
    • The location of one end of this ship, using its upper or leftmost coordinate:
      • The row of the coordinate, as a two-byte integer
        If there are r rows, then these are numbered 0, 1, … r-1
      • The column of the coordinate, as a two-byte integer
        If there are c columns, then these are numbered 0, 1, … c-1
Receives what was sent in the row above. Sends one of the following back to the client as a String:
  • ok if everything looks good
  • bye if the client specified ships incorrectly
 
From here, the server sends all messages to both clients.
Sends one of the following messages, as appropriate:
Open a player's turn
  • The string PlayerTurn
  • The one-byte integer 1 or 2, depend on whose turn it is
Log a player's fire
  • The string PlayerFires
  • The id of the player (1 or 2) as a one-byte integer
  • The row of the fire as a two-byte integer
  • The column of the fire as a two-byte integer
  • The string hit or miss
  • The string sunk or notsunk
  • The string win or nowin
 
  Reacts to the message received from sender:
Player's turn
  • If your id matches the id on this message, you must fire a missile. Do that by sending the following message:
    • The string move
    • The row of the fire as a two-byte integer
    • The column of the fire as a two-byte integer
Log a player's fire
Update any status or display elements as needed.
Once a client has entered a an observer, or as a player who has finished the configuration stage, you must also be prepared to receive or send the following message.
  • If a client sends:
    • The string message
    • A string with the contents of that message
    then the server must send the following to all players and observers.
    • The string broadcast
    • The name of the sender as a string
    • The contents of the message as a string
Because this feature is offered asynchronously, your client and server must be prepared to receive and send from and to the socket at any time. This implies that receiving and sending must be performed in separate threads. Without a separate thread, any attempt to read from the socket would block, preventing outgoing messages from being sent.

The best way to manage this is using the single-threaded server idea discussed in class. A thread-safe queue accepts messages to be sent across the socket, and a separate thread services that queue to send the messages.

Observers

Observers connect to the server and indicate they want to observe as described in the table above.

Procedure

You are responsible only for implementing the server for this project. Clients will be provided for you:

Demo

When you done with this studio, you must be cleared by the TA to receive credit.


Features (TA, verify!): bare minimum Plays the game bewteen two players reliably, but messages are not broadcast
mostly All messages are broadcast eventually
everything Each messages is broadcast at the moment it is submitted
Last name WUSTL Key Propagate?
(or your numeric ID) Do not propagate
e.g. Smith j.smith
1 Copy from 1 to all others
2 Copy from 2 to all others

TA: Make sure they commit their code before you sign them out!

TA: Password:




Last modified 10:58:01 CDT 27 April 2015 by Ron K. Cytron