Lab 1 FAQ

Q: Do we need to use Go version 1.25 locally to get everything to work properly, or would it be okay to use a different version of Go?

A: We require at least Go version 1.24 but it is best to use a recent version of Go and preferably the version we have installed on the UG machines. Your code will be tested on the UG machines so make sure that your code runs there.

---

Q: The lab handout mentions that the server expects to receive serialized messages from the client. How should I generate such messages?

A: Your client needs to serialize a Go data structure when sending a message to the server and deserialize a Go data structure when receiving a message from the server.

The encoding/gob package is part of Go's standard library for serializing and deserializing Go data structures into a compact, efficient binary format. This format is generally used to send and receive data structures across machines. Here is a simple example that shows the usage of this package.

We suggest using the ece419/labgob package for all the ECE419 labs. This package is a simple wrapper over the encoding/gob package and is especially useful for detecting subtle errors in later labs that use RPC-based communication. Look at nim/server.go to see how this package is used.

---

Q: The tester keeps showing errors such as

`nim_test.go:210: Error at line 74: LastStatus: Game Open, LastMove: {0 [] 0 0}, CurrentStatus: Game Over, CurrentMove: {0 [] 0 0}`

How should I debug my program?

A: The checkMove() function in the tester tracks the last and the current move returned by the client'sPlayMove()function. The error output above shows the line number (74) in thecheckMove()function and the last and current move at which your Nim client fails the Nim protocol requirements. You can look at thecheckMove()function to understand the expected behavior ofPlayMove()`.

---

Q: Why does the number of messages sent/received by clients and the number of operations executed change across different tester runs?

A: One reason is that these numbers depend on the initial board and the server generates random boards. The second reason is that the client needs to resend messages with an unreliable network and the number of resent messages depends on our network emulation and the client-side receive timeout.