Below is an email excerpt, with me (TA - Mike) responding to an email
with some good questions regarding A1, which includes some great
discussion about some slightly confusing topics.

=====================================================

> 1. I've been looking for this one online, and have so far been unable to
> find it (perhaps due to poor search skills :). Is there an easy way to
> define variable-argument functions for rpcgen (like "..." in C)? Since I can
> technically pass any number of arguments to the command I want to start, my
> rpc call should support that, right? Yes, I can pass a string and then
> tokenize it by spaces on the executing end, but that seems inelegant.

Not that I know of. I think the parameter marshalling (packaging) that
must take place between the stubs probably wouldn't like an
implementation supporting that. If you're looking for a way to execute
a command with multiple arguments, I suggest you pass the whole
command line as a string, and then use system() to run the program on
the server.

> 2. Do we need to handle any kind of return values from the server for
> the remote command (such as command output or return code)?

We don't require the return value of the program to be preserved, but
you can do that if you like. Just let all of the output take place on
the server machine. If you're using system(), you can easily redirect
the output to a file if you want. It would be quite hard to pipe the
output of the program (running on the server) back to the client
without using a really long string as a return value anyways.

> 3. As far as the cool-looking process table, is this something like a
> remote "top", or should we just list the running RPC processes?

Kind of like a remote "top", but I think a list of the
remotely-started (running and maybe a list of expired) programs would
be cool. We've given a lot of flexibility in what you guys can do, so
just be creative. Figure out what would be useful for observing the
behavior of your algorithm (to observe it in action) -- that's the
purpose for having it.

> 4. What does "sender-initiated protocol" mean in the context of item (3)
> in "putting it all together"?

This protocol is described specifically in the section titled "Simple
Load Balancing" (in the middle of page 1).

> 5. The "information-gathering RPC function" confuses me slightly. We
> need to have one of the servers figure out which is the best server,
> right? So, the SERVER itself queries other servers for their load
> averages, and returns the best server to the user (this is the way I
> currently have it implemented).

Exactly right.

> But the phrase "information-gathering
> RPC function" makes me think that the client is also querying the
> servers' load averages? What's up with that? :)

Yeah, and it's up to you. We thought it would be easier to have one
client query all the servers for their load/process information (maybe
have the servers return a string consisting of their load and a list
of processes) just for the purposes of creating this "cool-looking
process table". For load balancing, yes, it must all be done between
the servers. Great question.