Worked out networking
authorSam Moore <matches@ucc.asn.au>
Sat, 21 Jan 2012 05:30:52 +0000 (13:30 +0800)
committerSam Moore <matches@ucc.asn.au>
Sat, 21 Jan 2012 05:30:52 +0000 (13:30 +0800)
commit341297b4dce9528d54fe9dceeff0d6dc33f70abe
tree482fb4a19dbc5e9255904ffbf4176640f3b645f0
parent73d5a5dab8881b9ed5f93a675d64f86a9b45e6bc
Worked out networking

Wasn't thinking straight with the initial approach

Basically:
 - Each stratego program is running ONE AI program locally
-> That AI's responses need to be sent accross the network to the other stratego program
-> Each stratego program keeps state seperately and sends instructions to its local AI, so actual instructions (ie: "Its your turn") aren't sent
 - A special controller is needed to recieve the responses

So we have NetworkSender, which wraps around an AI_Controller and simply sends its responses (exactly as they are) to the network
and NetworkReceiver which waits for responses from the network.

As far as networking itself is concerned, its not that important who is the Client and who is the Server.
If an IP address is specified, then Client is used, if no IP address is specified, Server is used.

NOTE: It isn't possible to use networking for both AI programs yet.
(ie: stratego @network @network) will fail when the Blue server attempts to bind the socket already used by the Red server.
I may consider fixing this at some point.

Going to test on mufasa.

I've just thought, if the stratego programs have different timeout sequences, there may be problems.
Oh well.
judge/manager/Makefile
judge/manager/ai_controller.h
judge/manager/game.cpp
judge/manager/game.h
judge/manager/graphics.h
judge/manager/main.cpp
judge/manager/network.cpp [new file with mode: 0644]
judge/manager/network.h [new file with mode: 0644]
judge/manager/network_controller.cpp
judge/manager/network_controller.h

UCC git Repository :: git.ucc.asn.au