Lab : Network Security



Development & Deployment of a Real-Time, Networked Application on Mobile Devices

Telecommunications Program

Part I: Objective

The goal of this lab is to introduce the student to a development of a real-time, networked application for wireless devices such as mobile phone and the personal digital assistants (PDAs). Student will experiment a development cycle and face with the performance issues from developing a real-time game, called “Slugs”.

Part II: Equipment List

1. A personal computer with Windows OS

2. Two handheld devices (Palm Pilot or Handspring Visor) with Palm OS 3.5 or higher with at least 4 MB memory

3. Java 2 Standard Edition Development Kit (JDK) Version 1.4.2 or higher

4. Java 2 Micro Edition Wireless Toolkit Version 2.2 or higher

5. IBM WebSphere Micro Environment Toolkit Software

6. Palm Desktop software

7. Any text editor of your choice

Part III: Introduction

Stand-alone applications do not take full advantage of the resources available on many small devices today, such as cell phones. Such devices are connected to a wireless network that allows the devices to communicate with one another. Communication can be incorporated into the game play. With this type of networked game, you might be on a bus riding somewhere and playing a game with your friend in a movie theater waiting for the movie to start.

In this lab, you will experiment a development of a networked game called “Slugs”. All the source codes are provided. You need to compile, set them up, run the tests on both emulators and real devices, and conduct some performance analysis.

Part IV: Game Description

Slugs is a two-player, level-based game, in which players control their character (a slug) through their own device. Players are constantly on the move and need to avoid running into obstacles. For slugs, these obstacles include level boundaries, brick walls, poison, and the opponent. Slugs leave slime in their tracks, and for the purpose of this game, the tracks also represent an obstacle. The goal for each level is to be the first player to reach the one slug house present in the level.

A few things have been added to the basic scenario to make the game more interesting. Some levels have extra lives which can be picked up by the first player at that level. Also, some places have heads of lettuce, which will boost player energy upon consumption. For a short period of time, the player moves twice as fast as usual. If the player runs into one of the aforementioned obstacles, they lose a life. Each player starts out with three lives, and when the life count goes to zero, the game is over.

Finally, some levels contain shovels and/or jetpacks. Upon picking up a jetpack and pressing '1' on their device, the player starts flying. When flying, the player can cross most obstacles unharmed. Walls, poison, and tracks are not harmful to the player in this state. However, colliding with a level boundary or into the opponent is still harmful. The flying state is indicated on screen by painting the player differently than in the normal crawling state. The player stays in the flying state only for a brief period of time. Once that time has passed, the usual obstacle restrictions apply.

The same rules apply when the player enters the digging state, which happens when a player picks up a shovel, and presses '3' on the player's device. Note that for the players to actually collide, they need to be on the same elevation level; that is, they both need to be crawling, flying, or digging. They can cross paths unharmed as long as they move on different planes. In the game state, the bottom of the screen displays the number of remaining lives, jetpacks, and shovels held by each player.

A splash screen is displayed when starting the game. This screen is a terse introduction and help screen. In a compact amount of space, this screen explains the primary goal for each level, lists the controls available to the player, and shows and explains the icons found in the levels. Unless your game is trivial to play, you should consider following this approach. You don't want people to have to wade through a lengthy manual or help section to get started playing the game, but you don't want to leave them completely stranded either. Remember that games for small devices are often used in a different context than games for desktop machines. For the former, chances are that the person playing the game just wants to kill a few minutes waiting for something and does not want to read lengthy instructions to get started.

Part V: Design

The complexity of slugs is considerably higher than that of the stand-alone game, primarily because slugs is a real-time, non-turn based, networked game. In a turn-based networked game, such as network- enabled chess, both players take turns to move (they never move at the same time) and it is always clear whose turn it is. While the design of a turn-based game is not necessarily trivial, it does not pose the same challenges as the design of a non-turn based game. For the latter, players can move at any time and there is no defined sequence to how players alternate their moves.

A naive implementation might put the game engine onto the client devices and have the clients connect to each other directly, with each client forwarding events generated by the player (generally key events such as left, right, up, down) to the other player. This makes for a simple design with little overhead, but there is a problem - network latency.

Due to network latency and lack of synchronization between the devices on a wireless network, game state slowly starts to drift apart. Consider a scenario where player A is headed towards a wall. A realizes the situation at the last second and makes a left turn to narrowly avoid the wall. On A's device, the crash is avoided and the game continues normally. As part of the networking code for the game, A's key press is sent out to B's device. It arrives at the device fractions of a second later. However, on B's device, another clock tick has happened just as the event arrived. This clock tick drives A into the wall, before the game has a chance to process the newly-arrived remote key press. Player A is now alive and well on A's device, but needs to be scraped off the wall on B's device. Even with extremely small network latency, this situation is bound to happen sooner or later. Synchronization problems such as this make the game unplayable, and thus they need to be avoided.

There is going to be a server which acts as an independent arbiter between both players. The server is the sole responsible party for managing game state. Both clients have the ability to continually deliver key events to the server. The server coalesces these events and processes them at a fixed-rate interval. At the completion of each interval, the server updates the game state based on existing and new player state, and generates events exactly reflecting the changed game state. No events are generated when the player state is unchanged. The server distributes events to both clients, which update the display based on the received data. The clients keep no local state information; instead, they forward all received input to the server for processing. Effectively, the client devices are remote terminals with a screen and input keys.

The server portion of the game consists of two parts: game-independent networking code and the actual game engine. The networking code opens a server socket and listens for incoming connections. It also instantiates an appropriate game engine based on a name parameter passed to it as an argument. When it detects an incoming connection, the networking code spawns a connection object. This connection object acts as an intermediary between the game engine and the client, freeing the server game engine from knowing about how clients connect to it.

As mentioned previously, the server game engine deals only with game state. It does not concern itself with networking issues or graphical representation of the game state on the client. In fact, the (indirect) interface between game engine and clients is kept sufficiently abstract so that it can deal with completely different kinds of clients. Although for this document we only implement a simple MIDP client, the engine can handle much more powerful clients with no modification. To reiterate, input to the engine consists of potentially irregular updates of client state (in the form of key press events), while output consists of regular batches of events regarding changed game state. This output effectively implements a synchronized clock for both clients.

The game state is designed such that differences between individual states can be transmitted with a minimum amount of data. Each level consists of a relatively small number of cells, each cell has a state (empty, shovel, player 1 track, and so forth) associated with it. Players are always on exactly one cell and they move to the next cell in one move. Aside from a few specialized game state events, most events during the game consist of state updates to cells (consisting of the x, y location of the cell in question and an ID for the new state).

The client code can also be divided into two parts: a game-independent networking portion and the actual client visualization component. The networking code signs the player on to the server and instantiates the appropriate visualization component through a property read from the MIDlet descriptor file. It determines the actual server address in the same fashion. Thus, changes to both attributes can be made without recompiling the code. The visualization code does two things:

1. It captures the player key presses and forwards them to the server through the networking component.

2. It processes the game state events sent from the server and updates the screen of the client device accordingly.

The clients and the server must be able to exchange data to communicate new events and notify each other of changed game state. We have chosen TCP/IP sockets as our underlying communication mechanism. Sockets are fast and have low overhead, but they do not provide a very rich interface for exchanging complex data types. In fact, the data we can transmit over sockets is basically limited to arrays of numbers. Although the J2SE platform has a mechanism called object serialization, which allows the developer to represent most Java objects as arrays of numbers, that API is not available for small devices. More information related to source codes can be found in [1].

Part V: Before You Begin

1. Install J2ME Tool Kits (the lab machine is already installed for you).

2. Download slugs source code client and server packages from the followings:

1. Client:

2. Server:

(You may also receive these two .zip files from GSA by email.)

3. Delete the following directory (if exists) on PC.

• C:\WTK22\apps\Slugs

4. Delete the “Slugs” application (if exists) on the Palm device (Palm Tungsten T5).

1. Go to the Applications page

2. Tap the clock display located at the top left of the screen and then choose “Delete”.

3. Select Slugs and then tap “Delete” button to delete the Slugs application from the palm device.

Part VI: Procedure for Running Slugs Server

1. Upload the SlugsServer.zip to a networked machine where you will run the server. For example, you can upload to your account on paradox.sis.pitt.edu machine.

2. Unzip the zip file. You should have SlugsServer directory after the unzip.

3. Change to SlugsServer directory, then compile the source code and run the server manually or using the scripts provided*.

a. To compile the source code, at the command prompt, type “./compile.sh”.

b. To run the server, at the command prompt, type “./run.sh”.

c. If the permission is denied, you have to change an access mode of the script files. This can be done by typing “chmod 700 compile.sh” for the compile script, and “chmod 700 run.sh” for the run script.

Once you start the server, it will print an ASCII map, representing a Slugs field, on screen. This map will be distributed to clients when they are connected.

* Check the README.txt provided in the SlugsServer directory for more information.

Part VII: Procedure for Testing Slugs Client on Emulator

To use with J2ME tool kit, do the followings:

1. Start KToolbar (J2ME tool kit).

2. Press the "New Project" button.

3. Assign a project name, e.g., "Slugs", and the MIDlet Class Name "slugs.client.SlugsMIDlet".

4. Assign the server IP address where you run the Slugs server code.

a. From the menu press "Setting" button,

b. Then select User Defined tab,

c. Then "Add"

d. Then assign "ServerIP" as the key, and the server ip address as the value (the server IP address can be obtained by using a command “ifconfig –a”)

5. Place all src codes in the package to the project directory

a. Unzip “SlugsClient.zip” file.

b. Locate the project src directory, ie. "C:\WTK22\apps\Slugs\src"

c. Place all the src files (i.e., “client” subfolder and “shared” subfolder” obtained in part a) in "src" directory in part b.

6. Go back to the KToolbar, hit "Build" button.

7. Test running by hitting "Run" button. You need two instances of slugs client to play the game (i.e., hitting “Run” button once again to create another client).

Note that the server must be started before you run the client.

Part VIII: Procedure for Testing Slugs Client on a Mobile Device

1. Packaging Slugs Client source codes

a. Go back to Ktoolbar, and select "project",

b. Select "Package" and "Create Package".

c. The files "Slugs.jar" and "Slugs.jad" are created in the project bin directory, i,e., "C:\WTK22\apps\Slugs\bin".

2. Move these files to the web servers where you can download through the web. For example, ftp to your sis account in directory "public_html" and so you can access them through url and

3. Install slugs client in your device through OTA,

1. Turn on a wireless connection of the PDA (e.g., Wi-Fi).

2. The JAVA Virtual Machine is already installed on the lab PDA. Run Java Virtual Machine by clicking an icon “MIDlet HQ”, .

3. Select "install" and you will be asked for the url. Put in the url of your "jad" file, i.e.,

4. Follow the screens to complete the installation.

5. Test by select "Slugs" in the MIDlet list, and press "launch" button.

Note that you can test the game by using one real device and one emulator. In any case, do not forget to run the server first.

Part IX: Assignments

Conduct the sensitivity analysis of the update_interval regarding to the network overhead and the client response time. The update_interval parameter is defined in the SlugsEngine.java located in the “SlugsServer/src/slugs/server” directory (the default value is 1500 ms). Change its values and analyze the performance you getting in term of network overhead, and the responsiveness to the user.

Tip: Use the default update_interval as the starting point.

Questions:

1. What is the update_interval for?

________________________________________________________________________________________________________________________________________________________________________________________________________________________

________________________________________________________________________

2. From an experiment, are there any differences between testing on emulators and the real device? If so, what are they?

________________________________________________________________________________________________________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________________

3. Describe the relationship between update_interval and the network overhead, and the update_interval and client response time. ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

4. Give us suggestions how to improve the performance of the Slugs game.

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5. Describe briefly the main issues regarding to development and deployment a real-time, networked application on a mobile device.

________________________________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Reference:

[1] Kay Neuenhofen, Designing and Writing Java Action Games for Small Devices, June 2002. Available online:

-----------------------

Student Name: _________________________

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download