Assignment 1

416 Distributed Systems: Assignment 1

Due: Jan 13th at 9PM

Winter 2015

This assignment is intended to get you started with programming in the Go language. To solve this assignment you will need to install Go, figure out how to compile, run, and debug a Go program, and implement a UDP-based protocol described below for connecting to two services: an authentication service, and a fortune service.

High-level protocol description

There are three kinds of nodes in the system: a client (that you will implement), an authentication server (aserver) to verify a client's credentials, and a fortune server (fserver) that returns a fortune string to the client. You will test and debug your solution against running aserver and fserver instances. However, you will not have access to their code. You are given initial starter code (below) which contains the expected message type declarations. Both aserver and fserver serve multiple clients simultaneously. Each client implements a sequential control flow, interacting with aserver first, and later with the fserver. The client communicates with both servers over UDP, using binary-encoded JSON messages.

The client is run knowing the UDP IP:port of the aserver and an int64 secret value. It follows the following steps:

  1. the client sends a UDP message with arbitrary payload to the aserver
  2. the client receives a NonceMessage reply containing an int64 nonce from the aserver
  3. the client computes an MD5 hash of the (nonce + secret) value and sends this value as a hex string to the aserver as part of a HashMessage
  4. the aserver verifies the received hash and replies with a FortuneInfoMessage that contains information for contacting fserver (its UDP IP:port and an int64 fortune nonce to use when connecting to it)
  5. the client sends a FortuneReqMessage to fserver
  6. the client receives a FortuneMessage from the fserver
  7. the client prints out the received fortune string as the last thing before exiting on a new newline-terminated line
The communication steps in this protocol are illustrated in the following space-time diagram:

Protocol corner-cases

  • The aserver and fserver expect the client to use the same UDP IP:port throughout the protocol. An ErrMessage will be generated if the client uses different addresses.
  • The aserver will reply with an ErrMessage in case the MD5 hex string value does not match the expected value.
  • The fserver will reply to all messages that it perceives as not being HashMessage with a new NonceMessage.
  • The fserver will reply with an ErrMessage in case it cannot unmarshal the message from the client.
  • The fserver will reply with an ErrMessage in case an incorrect fortune nonce is supplied in the FortuneReqMessage.
  • All messages fit into 1024 bytes.

Implementation requirements

  • The client code must be runnable on CS ugrad machines and be compatible with Go version 1.4.3.
  • Your code does not need to check or handle ErrMessage replies from the aserver or fserver. However, you may find it useful to check for these replies during debugging.
  • Your code may assume that UDP is reliable and not implement any retransmission.
  • You must use UDP and the message types given out in the initial code.
  • Your solution can only use standard library Go packages.
  • Your solution code must be Gofmt'd using gofmt.

Solution spec

Write a single go program called client.go that acts as a client in the protocol described above. Your program must implement the following command line usage:

go run client.go [local UDP ip:port] [aserver ip:port] [secret]

  • [local UDP ip:port] : local address that the client uses to connect to both the aserver and the fserver (i.e., the external IP of the machine the client is running on)
  • [aserver UDP ip:port] : the UDP address on which the aserver receives new client connections
  • [secret] : an int64 secret

Starter code and testing servers

Download the starter code. The aserver is running at IP:port Use 2016 as the secret value for testing against this server instance. The fserver is also running.

Rough grading scheme

  • 100%: Solution meets the above spec, retrieves the correct fortune and prints it out.
  • 75%: Solution properly communicates with aserver (retrieves the fserver IP:port and fortune nonce) but does not retrieve the fortune.
  • 50%: Solution retrieves the correct nonce from the aserver, properly computes and communicates the MD5 hash back to the aserver, but does not retrieve the fserver information.
  • 25%: Solution retrieves the correct nonce from the aserver but does not properly compute and communicate the MD5 hash back to the aserver.

Make sure to follow the course collaboration policy and refer to the assignments instructions that detail how to submit your solution.