Introduction Background
Example MapReduce job
Job submission Tasks
Fault tolerance Conclusion
Copyright By PowCoder代写 加微信 powcoder
This site uses Just the Docs, a documentation theme for Jekyll.
Search CS 162 HW 5
Worker registration
TABLE OF CONTENTS
1 Registration 2 Heartbeats
In this part, you will be implementing worker registration, where a worker connects to the coordinator gRPC server and requests a unique ID that the coordinator will use to identify the worker in the future. You will also implement heartbeat messages that allow the newly registered worker to signal to the coordinator that it is still alive and working.
Registration
Design and implement a new RPC call for registering workers and assigning them a unique ID (this can be done by using a simple counter). Keep your IDs as small as possible and nonnegative since these IDs are used to determine the port (an unsigned 16-bit integer) that the workers listen on. You will need to modify proto/coordinator.proto as well as src/coordinator/mod.rs . For an example of how to implement an RPC call, take a look at the Example RPC.
Keep in mind that your RPC stub needs to be asynchronous and thread safe, so it may help to take a look at the documentation for std::sync::Arc and tokio::sync::Mutex . We do not expect you to use fine-grained synchronization, so feel free to protect all of your mutable state with a single mutex.
Once you have implemented the coordinator stub for registration, you will need to modify the worker::Worker::new function to call the new RPC and store the new ID assigned by the coordinator in
the worker¡¯s id field. Here is an example of how to use the client created in worker::Worker::new :
let mut client =
coordinator_client::CoordinatorClient::connect(
format!(“http://{}”, COORDINATOR_ADDR)
let res = client.example(ExampleRequest { name: “Oski”.to_string() }).await?;
println!(“Message: {}”, res.get_ref().message);
To test if your implementation works, we recommend adding log::info! statements at relevant locations in your code to check if the coordinator is receiving registration requests when new workers are started and that each new worker receives a unique ID.
You do not need to persist worker IDs. Crashed workers are restarted by starting a new worker process, which should receive a new ID when it registers with the coordinator.
Heartbeats
Every 2 seconds, the worker should send a heartbeat to the coordinator so that the coordinator can keep track of which workers are alive, reassigning tasks currently assigned to dead workers as necessary. Implement a new RPC call for heartbeats. The coordinator should keep track of the time of the most recent heartbeat from each registered worker. While we will not be testing this explicitly, it will be necessary for implementing fault tolerance in later parts of the homework.
Once you have implemented the coordinator stub for heartbeats, you will need to modify the worker::Worker::run function to send a heartbeat to the coordinator every HEARTBEAT_INTERVAL_MS
milliseconds (constants can be found in src/lib.rs ). Since we want this to happen as long as the worker is alive, you should spawn a new tokio task that runs an infinite loop of sending a heartbeat and waiting.
To test if your implementation works, we recommend adding log::info! statements in your heartbeat RPC to verify that the coordinator receives heartbeats periodically after starting a new worker and that these heartbeats stop after the worker has been terminated.
Back to top
Copyright ý 2022 CS 162 staff.
Worker registration
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com