University stuff.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
mortie 6cce9fdc1c having this in git is probably good 7 years ago
..
jobfiles having this in git is probably good 7 years ago
src having this in git is probably good 7 years ago
15252.tgz having this in git is probably good 7 years ago
Makefile having this in git is probably good 7 years ago
README.txt having this in git is probably good 7 years ago
client having this in git is probably good 7 years ago
server having this in git is probably good 7 years ago

README.txt

Main source files: src/server.c, src/client.c

# Comments

For utility functions in their own files (tcp.c, job.c, etc),
the corresponding .h file contains documentation,
while the .c is mainly source code.

# Protocol

I made one addition to the protocol: I added an optional extra 4 bytes
as an uint32_t to the "G" message, specifying how many jobs we want.
This means a message which gets jobs can look either like this:
G
or like this:
G<4 bytes uint32_t>
In the first case, the server will default to sending one job.

The bytes after G specify how many jobs the server sends at most,
but the server will send less jobs if less jobs are available.
This means providing a sufficiently high number will return all
the jobs available. I do this by just setting all the bits to 1,
which is the highest value of an unsigned int.

When the client exits normally, the server should also exit,
however there's no specification for what happens when the client
exits incorrectly before all jobs are read. I decided to make the server
exit if it gets a message of type E. If there's an error reading
from the client, the server does not exit, but rewinds the file
such that the next client can start anew. If this is incorrect,
removing the rewind(jobsf) calls in request_handler would fix it.

# Notes

This might go without saying, but while child 1 only outputs to stdout,
and child 2 only outputs to stderr, the main process also outputs
to stdout and stderr, so not everything printed to the streams are from
the child processes. Most notably, the "> " for the prompt is also written
to stdout.

The server can't know that a job is the last one; it can only know that
it has reached the end of the file when reading the next job. Therefore,
a job of type Q won't be sent right after the last job; it will be sent
when the client again asks for a job after the last one has been sent.

When running the client with valgrind, it reports some memory is
"still reachable". That memory is allocated by the GNU readline library,
and there is no way to free it. I do clear all history entries though.
Runningn with `valgrind --leak-check=full --show-leak-kinds=all` shows us
that all "still reachable" memory is allocated by a call to readline.

Compile with `make noreadline` for a version which doesn't use readline.
Valgrind will then report that no blocks are "still reachable".