Due date: 4/08 @ 5pm
Objective: to develop some basic understanding of distributed
programming via the remote proxy pattern
Background: The modern world needs distributed computing. In this
world, a system consists of many components that communicate via message
exchanges, which typically correspond to method calls and returns. People tend
to call ordering and formatting of these message exchanges a "protocol".
Over the past few years, XML has emerged as the dominant format for these
messages. You can find abbreviations such as SOAP, XML RPC, etc. when you look
for distributed protocols. Not all languages have bindings for libraries that
support these protocols so I have decided to have you implement one from
scratch.
Protocol: (interaction diagrams for remote proxy communication) The
following suggestive interaction diagrams show how the game administrator might
communicate with the players. The diagrams are refinements of your game (or what
yours should have looked like) that include hints on how the distributed game
works. Do not take these diagrams as accurate dedscriptions of how my
server works or how your server should work.
Each diagram comes with a definition of the format th
- Use case: a player registers with the administrator
This diagram specifies how players register with the game administrator
in the local case:
admin player
| register(name) |
| <-------------------------------------------- |
| |
| ret:follower or false |
| --------------------------------------------> |
| |
The player sends a message to the administrator and receives either a
follower (a string denoting a color) or false in return.
Using the remote proxy pattern the interplay looks slightly different:
SERVER CLIENT
==============================================================
admin server proxy-admin player
| | | |
| | | |
| proxy-player new(p) | register(name) | |
| | <------ | <------------------- | <- |
| | | | |
| | register| | |
| | <----- | | |
| | | | |
| | | | |
| ret:tesult | ret:resu|t | |
| -----------> | --------|--------------------> | -> |
| | | |
the proxy-admin sends
<call name="register">
<li><string value="... words ..." /></li>
</call>
to the server
the proxy-player sends a Result to the proxy-admin
Result = <return><string value="ColorString" /></return>
| <return><boolean value="false"></return>
ColorString = red | yellow | cyan | black | green | magenta
The diagram contains several new objects:
a server that listens for tcp/ip requests;
a proxy-player, which is created from the new tcp/ip port
and plays the role of a player to the administrator; and
a proxy-admin, which is created in parallel with
the player on the client side and plays the role
of the administrator there. It implies that the server and
proxy-administrator exist from the very beginning. The proxy-player comes
about when the server receives a request to register another player.
- Use case: the administrator grants a player a turn
SERVER CLIENT
==============================================================
admin proxy-player proxy-admin player
| | | |
| t=new() turn | | |
| ------> | | | |
| | | | |
| take(t) | | | p=new() |
| | | take() | proxy-turn |
| ------------>| --------------------> | -----> | |
| | | | | |
| | | | take(p)| |
| | | | ----------> |
| | | | | |
| | | | | |
. . . . . .
. . . . . .
. . . . . .
| | | | | |
| <------ |<-- | <------------------- | <----- |<--- |
the proxy-player sends
<call name="take-turn" />
to the proxy-admin
the proxy-admin sends back
<return><void /></return>
to the proxy-player
QoS contract: a turn may not take more than 10 seconds
Again, we need one new class of objects: proxy-turns. They play the role
of a turn on the client side. That is, they only represent the turn on the
remote machine but actually just communicate their method calls to the
proxy player on the server side. The following diagrams explain how the
proxy-turn interacts with the proxy-player.
- Use case: the player requests the index of the turn's tile
SERVER CLIENT
==============================================================
admin turn proxy-player proxy-turn player
| | | | |
| | | | g-i |
| |<---------- |<---------------- |<----- |
| | ---------- | ---------------> |-----> |
proxy-turn sends
<call name="get-index" />
to proxy-player
proxy-player sends
<return><number value="Index" /><return>
to proxy-turn
Index = 00 | 1 | ... | 24
- Use case: the player requests the list of potential tile locations from
the turn
SERVER CLIENT
==============================================================
admin turn proxy-player proxy-turn player
| | | | |
| | | | plt |
| |<---------- |<---------------- |<----- |
| | ---------- | ---------------> |-----> |
proxy-turn sends
<call name="potential-locations-for-tile" />
to proxy-player
proxy-player sends
<return>ListOfTile<return>
to proxy-turn
ListOfTile = <list>TileItem+</list>
TileItem = <li>Tile<li />
Tile = <tile index="Index"
x="Number"
y="Number"
orientation="Orientation" />
Orientation = 0 | 90 | 180 | 270
Number = Integer
- Use case: the player places a tile
SERVER CLIENT
==============================================================
admin turn proxy-player proxy-turn player
| | | | |
| | | | pt |
| |<---------- |<---------------- |<----- |
| chgGraph | | | |
| <---------- | | | |
| | ---------- | ---------------> |-----> |
proxy-turn sends
<call name="place-tile">
<li>Tile</li>
</call>
to proxy-player
proxy-player sends
<return><void /></return>
back to proxy-turn
- Use case: the player requests the potential locations for followers
SERVER CLIENT
==============================================================
admin turn proxy-player proxy-turn player
| | | | |
| | | | plf |
| |<---------- |<---------------- |<----- |
| | ---------- | ---------------> |-----> |
proxy-turn sends
<call name="potential-locaions-for-followers" />
to proxy-player
proxy-player sends
<return>
ListOfPos
<return>
to proxy-turn
ListOfPos = <list>PosItem*</list>
PosItem =
<li>
<list>
<li>Tile<li />
<li><number value="Position" /><li />
</list>
<li />
Position = 0 | 90 | 180 | 270 | -100
The Place values
0,
90,
180,
270, and
-100
represent
the northern edge,
the eastern edge,
the southern edge,
the western edge, and the inside of the tile.
- Use case: the player places a follower
SERVER CLIENT
==============================================================
admin turn proxy-player proxy-turn player
| | | | |
| | | | pf |
| |<---------- |<---------------- |<----- |
| chgGraph | | | |
| <---------- | | | |
| | ---------- | ---------------> |-----> |
proxy-turn sends
<call name="place-follower">
<li>Tile</li>
<li><number value="Position" /></li>
</call>
to proxy-player
proxy-player sends
<return><void /></return>
back to proxy-turn
- Use case: the turn sends the player a score and returns some followers
SERVER CLIENT
==============================================================
admin turn proxy-player proxy-turn player
| | | | |
| | score_token| | |
| | ---------> | ---------------> | ----> |
| | <--------- | --------------- | <---- |
proxy-player sends
<call name="score-and-token">
<li><number value="Number"></li>
<li><number value="Number"></li>
</call>
to proxy-turn
proxy-turn sends
<return><void /></return>
back
- Use case: the administrator sends a message to the player
SERVER CLIENT
==============================================================
admin proxy-player proxy-admin player
| | | |
| inform | | |
| ------------>| --------------------> | -----------> |
| | | |
| | | |
the proxy-player sends
<call name="inform">
<li><string value="... words ..." /></li>
</call>
to the proxy-admin
the proxy-admin sends
<return><void /></return>
back
You may infer the proper XML messages for the observer methods:
placed-tile,
placed-follower, and
other-score-and-token. The
get-graph method is
not implemented.
Task: Your task is to implement a distributed version of your
Carcassonne project so that the player and the administrator run on different
computers. They will communicate according to the specified protocol over tcp/ip
sockets. [POINTS: 60]
As you do so, you may not touch your code base. Instead, you must create
remote "proxies" that play the role of the administrator on the CLIENT machine
and the role of the player on the SERVER machine. The proxies only know how to
forward method calls and returns to the other side of the world.
Product: Mail a tar bundle with a two subdirectories labeled
YourName_Project12 and YourName_Project11. Each
subdirectory must contain a README file and a file RUN. The former contains
the require documentation; the latter runs the project in a standard or
conventional fashion. [POINTS: 5]