So this project has actually been really great. When I send the
jobs to either of the compute servers, I send each job and wait for the
immediate response. This might be naive, but I have my reasons: 1) It keeps my
data in order, 2) the operations are so light/trivial that there is virtually 0
processing time, and 3) it is straightforward and easy to understand.
Otherwise, everything is pretty standard. You've got a client that takes in text
files that meet the project constraints, sends them to an edge/broker server, which
then sends them to their respective compute server. Bam, boom, done.

client.cpp/client.h - this is the client. It takes in a text file, formats its
data, and then forwards that data to the edge server. (And awaits a response.)

edge.cpp/edge.h - the edge server. This server waits for a client to connect,
then puts that connection into a thread. Inside the thread it deconstructs the
data it was sent into individual jobs and forwards them to the compute servers.
Nothing special, but as above, the threads wait for each job to complete.

server_and/or.cpp & server_and/or.h - these are the compute server. They run UDP
and reply immediately to any message with the and/or of the message's bits.

TO RUN: Nothing special! Yay!
1) make all
2) make server_and
3) make server_or
4) make edge
5) ./client ./location/of/input.txt

Message format: I almost always use char arrays over the network. It's easy.
It's straightforward. I can turn them into strings, and parse, or whatever.

Idiosyncrasies/Fail points: None that my testing revealed (including multiple
concurrent connections).

Reuse: Credit where credit is due - Beej's guide was a HUGE help during this project.