TMA03 Question 3

This question allows you to draw together much of the material that has been covered in M257. It may help you to complete Activities from Units 8 and 9 before beginning and you are strongly advised to complete Activities 9.6, 9.8 and 9.9.

The purpose of this question is to develop a small application driven by a graphical interface that incorporates aspects of collection classes, event handling, and client–server programming, with threading providing the ability for the server to cater for multiple clients concurrently.

The most important feature to implement is the client–server interaction using threading. After you have the client–server interaction working well, you should add a simple graphical interface. You are allowed to use the NetBeans GUI builder for this graphical interface, if you want to. Use of the NetBeans GUI builder is described in the NetBeans Guide.

You are provided with two skeleton projects, TMA03Q3Client and TMA03Q3Server, both based on Activity 9.6.

TMA03Q3Client contains the following classes:

• HelloClient, which opens a connection to a server on the local host, and performs a single interaction with the server (the client-side part of the interaction is defined by the client’s processHello method)
• TestHelloClient, which runs the client.

TMA03Q3Server contains the following classes:

• HelloServer, which opens a server socket and accepts a single client on that socket; after accepting a client, the server completes a single interaction with the client (the server-side part of the interaction is defined by the server’s processHello method)
• TestHelloServer, which runs the server.

Before you begin

First run the server project and then the client project, to see that the client and server establish a connection and that the client receives a single message from the server. At the moment the server message is set to "Hello client. This is the server." After this interaction (the server sending and the client receiving the message) the client and server programs both exit. This interaction is performed by the processHello methods on the client and server sides.

Note that throughout this question we refer to an interaction as a high-level operation that can be represented by methods such as processHello on the client and server sides. In other words, an interaction represents some useful communication between the client and server within a particular scenario.

Your first task is to choose a concrete scenario that interests you for your client and server programs to implement and to describe how the client and server interact in terms of what we will call their protocol.

For example, the NameServer in Activity 9.9 and Section 8.1 of Unit 9 represents a name server scenario and understands two kinds of interactions in its protocol, which we might call quitting and retrieving. Quitting terminates the client and server programs, and retrieving allows the client to retrieve an email address associated with a name.

The client and server interactions are represented using strings. For example, the string referenced by CLIENT_QUITTING represents that the client is ready to perform the quitting interaction. The communications between client and server are themselves also strings.

In the same way, you will need to decide how to represent the different kinds of interactions that can take place between your client and server.

The scenario you choose must not be one that has already been presented as a specific example in M257 itself.

For example you might be interested in:

• a dictionary to convert SMS (Short Message Service or ‘textspeak’) abbreviations to English
• a database to record passwords of users of a computer system
• a system for recording information about athletes in a marathon.

You may want to develop your own extra classes relating to your specific example, such as an Athlete class or a Password class.

It is possible to have less serious applications – for example a guessing game such as MasterMind – but you are advised to keep the scenario quite simple and to remember that marks are awarded for meeting the requirements.

In terms of the interactions supported by your scenario we are leaving the details up to you, with some conditions:

• In coding your client–server program, you must use at least one Java collection, such as a HashMap or ArrayList, on the server side. Of course, the server should use your chosen collection in some way relating to your chosen scenario. For an example, have a look at the NameServer code in Unit 9 and in Activities 9.7, 9.8 and 9.9.
• The server should let the client know in some way that the client has connected to the server successfully, for example, by sending a ‘hello’ message. A successful or unsuccessful connection status should be visible in some way to the human user of the client program.
• You must provide a ‘help’ interaction that allows the server to send some descriptive text to the client describing the kinds of interactions that the server supports. This text is intended to be read by a human using the client program, so it does not have to conform to any careful specification: it should just help the human user to understand the kinds of things that can be done with the server and how to do them. It could consist of some lines of text specifying the commands the server supports and what they do, for example.
• You must provide a ‘quit’ interaction that lets the server know that it can drop the connection to the client. This interaction would be initiated by the user when he or she is ready to stop using the client program. The client program should shut down without errors as the last step in the ‘quit’ interaction; the server would normally continue running.
• You must include at least one interaction that returns to the client a number of lines of output where the exact number of lines returned may vary according to the request itself or the server’s state. That is, the client will not know when it performs this interaction how many lines of output it should expect. (The server will need a way of indicating to the client that the interaction is complete.) An example of such an interaction might be for the server to return all the items in a list that begin with the letter ‘A’. If the ‘help’ function behaves in this way, it will fulfil this requirement.
• You must write a server that is capable of dealing with more than one client at a time, concurrently. You are advised to leave the implementation of concurrent interaction until you have a successful interaction between a single client and the server.
• You must provide at least two other interactions with the server relating to your chosen collection class(es) and chosen scenario.
• Your client and server programs should not crash as a result of checked exceptions being thrown or incorrect forms of input from the client.

You are not constrained by the provided skeleton code: you should employ techniques such as creating helper methods, renaming class members, documenting your code and possibly making use of inheritance and composition, if they make sense within your application. However, you must not rename the projects themselves or the classes that start the client and server programs.

We recommend that you encapsulate the sending and receiving behaviour on the client and server sides; for example, it is likely that you would want to write a single method on the client side that retrieves all the output for an arbitrary interaction.

To some extent, the collections that you choose will suggest the kinds of interaction that could occur between the client and the server – and therefore the scenario that you are coding for – so you might like to think about this first. We elaborate on this below:

Example scenarios for the server collection(s)

A Map provides a way of associating one value with another. Possible examples of such mappings include:

• a dictionary, with functions such as lookup of a meaning of a word, establishing whether a word is in the language, finding words with the same definitions (synonyms), or beginning with the same letter, or containing a certain substring
• a table of conversion multipliers from one form of measurement to another, such as from metric to imperial units, or between different currencies. Possible functions might include conversion from unit A to unit B, or B to A, translation of information from one Locale to another (a locale represents a geographical, political or cultural region and can be used to translate from one date format to another, for example), or returning a list of units supported by the table
• a database associating a key with a value, and providing interactions such as determining if a key is in the table, what value is associated with a key, finding the key associated with a particular value, or returning a list of the keys in the table.

A List provides a way of ordering items that belong together for some reason. Possible uses of a list include:

• sorting items of interest in some order, with functions such as telling whether something is in the list, finding the first or last item in the list, prioritising items, or finding all items in the list that have some interesting property (e.g. longest or shortest strings)
• recording the order in which items have been added, with functions such as telling whether an item is first or last, iterating over the items in the list, determining some property of an item in the list (e.g. when the item was added to the list), or finding all members with an interesting property.

A Set provides a way of maintaining a group of items that are unique according to some criteria. Possible uses include:

• removing duplicates from a group of items
• performing set arithmetic such as union, intersection and difference.

For any collection, interactions to add or remove items may be useful.

You are not limited to using one collection type. Remember also that your chosen scenario should be concrete, as specified at the start of part (a).

• In your Solution Document briefly describe the scenario that your program is useful for and describe in broad terms how the client and server interact. If you manage to complete a graphical interface (see part (b)), include a screen shot of it to help illustrate your answer. If you don’t manage to complete a graphical interface, then please include a sketch of a proposal for one.
• Use a table to describe the protocol you have chosen. (You may include additional descriptive text if you wish in addition to the table.) The table should have columns describing:
  • the names of the supported interactions, their meanings to the client and any impact on the client side
  • the client and server method names corresponding to the interactions
  • the message the client sends to the server for each interaction and the syntax of the client message if relevant, for example if the message may include one or more parameters
  • the server action, server response and any impact on the server side.

Your description should allow your tutor to understand the kinds of interactions understood by the client and server and should be detailed enough for your tutor to use it to test-drive your program. Here is an example of a row from a protocol table to show the level of detail required. We have used an imaginary interaction called FlipFlop. You may prefer to have separate columns for client and server method names. See image.

Note that in the example the client and server method names are based on the interaction name, and that the same name is used on the client and server sides. We recommend that you do the same as far as possible, although there need not be a one–to-one correspondence between methods on the client and server sides. You need only mention the top- level method in each case here. (The top-level methods may in turn rely on helper methods.)

Notice also that in describing the server’s action we assumed that the client and server had already determined that doFlipFlop was required. In practice, at a higher level, both sides may need to determine which interaction is required. You should explain how this takes place in part (a)(i).

As part of your protocol, you are strongly advised to have the server send a signal (such as a special string) to the client at the end of every interaction so that the client knows it has received all output expected for that interaction.

Once you have chosen a concrete scenario, start completing parts (a)(i) and (ii). You will probably want to return to these parts to refine your description as you begin developing your code.

You now need to develop your client and server classes in accordance with your chosen scenario and protocol. When you have completed your coding, copy all classes that you wrote or altered to your Solution Document. For classes that you altered, clearly indicate any changes that you made using highlighting or a similar technique. Write down any issues you have with running your code, particularly if you haven’t managed to complete it to your own satisfaction.

In this part you should develop a simple graphical user interface that supports the interactions in your scenario. You should include a screen shot of your interface in your Solution Document under part (a)(i) and in this part briefly explain its functionality and how you went about creating it. It is not important to create a beautiful interface and there are no marks awarded for aesthetics, but the interface should be understandable, readable and usable. You may use NetBeans visual GUI builder if you wish to, or code the interface by hand. You can work from the Activity 9.9 client GUI as a starting point if you wish. You are advised not to spend too much time developing the interface, unless it is for your own pleasure. You need not copy GUI code to your Solution Document, but you should explain to your tutor where to find it in your NetBeans projects.

Summary of required functionality and description of your programs:

• a concrete scenario and protocol
• at least one collection class in the server
• an initial connection interaction
• a help interaction
• a quit interaction
• an interaction supporting multiple lines of communication from the server side
• at least two other interactions
• robustness to incorrect input and checked exceptions
• handling of multiple clients concurrently
• a graphical interface on the client side