Lab 4

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:

Messages must be sent and received in the order specified.
The type of data within each message must be transmitted and received in the format that is specified. For example, if the protocol specifies a 4-byte integer, then it should be sent using writeInt and received using readInt, or code should execute that sends or receives the equivalent values.

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.

An observing client will observe the next game that is started with two players.
The server simply sends all messages sent to any player to each observer.
In this way, an observer client can show both boards in progress during the game.
The only input an observer can furnish to the server is a message, whose content is then sent to all players and observers.
So, an observer can help a player cheat since the observer sees both boards.

Procedure

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

A dummy client that signs into a game but plays randomly
A visual client that allows you to play the game with your server
These clients will allow you to test your server code. At least one client connecting to your server can be the dummy client, and then you can either have another dummy client play randomly against the other, or you can play against the dummy.
You must demonstrate your server with a local visual client and with another visual client on a different machine and with an observer to show all features of the server.
A server will be provided running on shell.cec.wustl.edu as a reference.

Demo

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

Commit all your work to your repository!
If you do not commit, the TAs cannot grade your work and you will receive a 0 for this assignment!

Fill in the form below with the relevant information
Have a TA check your work
The TA should check your work and then fill in his or her name
Click OK while the TA watches
If you request propagation, it does not happen immediately, but should be posted in the next day or so

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

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