Blog

This will automatically compile your server and link it against your implementations of the graph library
above, provided in graph.c.
The graph is created and queried by clients connecting to the server and issuing commands to the server
following the protocol outlined below. The graph created should persist between different connections to
the server, but does not need to persist if the server is stopped and then restarted. The server should listen
for and accept incoming connections on the TCP/IP port specified as the first and only) argument on the
command line, so if your program was called:
$ ./servCE 4242
where server is the name of your program, then your program should listen on port 4242.
To simplify things, we will represent the networks by an integer number between 1 and 255, and specify the
connections between two networks by specifying the source and destination network ID numbers along with
the weight (cost) of using that connection. You can assume that there is at most one link between two
networks. You should represent the networks as Vertices in your graph, and the links between networks as
edges.
Protocol
Your server should implement the following protocol, in most cases this can be done by writing C code to
parse the supplied command and arguments and then calling the appropriate function in the graph library
you implemented. Programs that do not implement all the functionality specified will still be able to obtain
marks (see the assessment criteria below) for the functionality implemented.
The client and server commu

nicate in ASCII (i.e readable text) with data being sent as a series of lines of text,
terminated by both a carriage return (CK) and a line feed ( s).” You can assume that no line of text will be
greater than 512 bytes long. All commands sent by the client to the server should be a single line long, while
the responses from the server will be at least one line long.
The first line of any response sent out by the server should indicate whether the action has been a success
or failure. In the case of success, the response should start with ‘+OK’ — in the case of an error, the response
should start with ‘-ERK’. Additional information may follow the ‘+OK’,’-ERR’ but this is optional except
where otherwise stated.
When a client connects to the server, the server will respond by sending a greeting. This is a simple line of
text that identifies the server. The greeting should begin with OK since the connection has been made.
The connection between the client and the server should be closed on receipt of the QU-T command from
the client. A single line response should be sent from the server to the client to indicate reception of the
command before the connection is terrninated by calling closei).
Your server should implement the following eight commands. As has been previously stated, most of these
commands can be implemented by making the appropriate calls to the graph library created in part one. If
your server receives any other command, it should respond with an error indicating that the command is not
implemented
Protocol Commands