Coursework assignment
“Stateful robot using protobuf and sockets”
CSE-111 Week 7
Background
We have now progressed to writing simple client-server C++ applications “from scratch”.
This assignment gives you a taste of what’s required to write an application which has functionality in
both a client and in a server and uses serialized messages to communicate across a TCP socket
connection.
It’s a pattern for larger applications like multiplayer games.
I’ve previously given you recipes/examples for:
• A client-server application (two versions – one using select(), one without)
• Message serialization using protocol buffers (protobuf_example)
• Generating “ticks” using a combination of sleep() and the C++ millisecond capable clock
(described in class on Wednesday 5/17/23)
• Implementing a state machine to describe the behavior of a simple robot that alternates
between waiting and moving (separate states – described in class on Wednesday 5/17/23) and
based on the reception of messages.
I’ve included two skeleton makefile based projects “robot_client” and “robot_server” in a single
“state_robot.zip” file.
These are skeleton projects with just an appropriate makefile options and main() method inside a top
level directory called “state_robot”.
The deliverable
Modify/Implement code for these skeleton projects so that robot_client can connect over TCP to the
robot_server using sockets.
You do not need to support multiple clients connected to a single server. One is fine.
A forever while loop in robot_client should sleep for a short period of time (say 500 milliseconds) and
send a serialized “tick” message to the robot_server.
The tick message should be a protobuf message, and I’ve given you a Message.proto file (in both
projects) which describes the format of the message.
On the robot server, receive the messages, deserialize them and implement a simple state machine to
make the robot alternate between sleeping and moving states; for each tick message received on the
server, output one of the strings defined in the robot_server Main.cpp file depending on what state the
robot it in.
If the operation of the client is interrupted, clean up the connection on the server appropriately, so that
the client can reconnect again.
To state the obvious, when the client is disconnected, the server should not be outputting messages, as
it doesn’t receive the tick messages from the client.
Please be sure to include the exact text from the robot messages to journal out the robot state to
std::cout. This will be used for grading; you can add stuff, but be sure these messages are included in the
output.
When you have completed the work, zip up the entire state_robot top-level directory and return this as
a submission for the coursework assignment using canvas.
Successful submission criteria
You’ll need to submit back the modified robot_client and robot_server projects (I.E. submit a zip of the
toplevel state_robot directory).
Both these projects should
a) Compile without warnings or errors
b) Work, in that they connect to each other, with the connection initiated by the client
c) Work, in that the client periodically sends messages to the server, causing the robot to change
state (with a reasonable frequency, say once a minute or ½ minute)
d) Work in that, once the client is interrupted and disconnects, you can connect it again to the
server by running the client once more.
e) Produce appropriate messages from server to std::cout indicating the state of the robot
f) Use the strings from the projects as output indicating state changes, so that we can evaluate
your submission.