5.9. Exercises
| Exercise 5.1 | Try a loose coupling experiment with the PingPong example: start Ping before Pong. What happens? Now try starting Pong before Ping. What happens? |
| Exercise 5.2 | In the PingPong implementation, add a field to the Ball entry to hold a timestamp. Modify the PingPong code such that, if the player is Ping, a report of the roundtrip time of the message is printed each time a Ball is received from Pong. |
| Exercise 5.3 | How would our PingPong example behave differently if Pong were changed to throw a ball first and then catch a ball (as Pong does)? |
| Exercise 5.4 | In our basic channel implementation of Section 5.4, we noted some drawbacks in how we check for the existence of a channel. Our solution to creating channels ignores another potential problem: what happens if two processes execute createChannel at the same time? Implement a proper way to test for the existence of a channel that will avoid these problems: Implement a channel registry in the space that can be used to see if a channel already exists. |
| Exercise 5.5 | In the basic channel of Section 5.4 and chat channel of Section 5.5, the readers of messages are locked into a particular channel and can't switch to others (once a channel is chosen, the channelTextField of the user interface is set to be noneditable). How could you modify the code to allow “surfing” to other channels at will? One issue is that our readers start reading with message one, so if a new reader thread were created whenever a user switched channels, it would start from the beginning of that channel. Modify the basic channel implementation so that it supports channel surfing and allows a reader to “pick up where it left off” whenever it switches to another channel. |
| Exercise 5.6 | One limitation of the ChannelCreator applet we built in Section 5.6.5 is that we don't ensure that the “Create” button isn't pressed more than once for the same channel. If it is, then the pager will behave unpredictably due to multiple head and tail entries for the channel. Fix this problem by making use of the channel registry you created in Exercise 5.4. |
| Exercise 5.7 | Build a FILO (first-in, last-out) channel, in which messages are delivered in reverse order (the newest message is always delivered first, and so on). |
| Exercise 5.8 | Implement a workflow system in which messages are taken from one channel and routed to other channels. |
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.