============================== DESCRIPTION ================================
(*) this project was done with the following goals in mind:
	- better understand how TCP and UDP work.
	- familiarize myself with the C socket API.
	- understand how TCP/UDP connection multiplexation is done.
	- familiarize myself with the way server-client applications work.

(*) the project is represented by a server capable of multiplexing the
incoming connections from multiple TCP and UDP clients. The main purpose
of the server is to create a "link" between the TCP clients (known as
subscribers in this case) which will subscribe to different topics in order
to receive information and the UDP clients which give information related
to different topics. As this project was part of a course assignment, the
implementation of the UDP client will not be found in it because it was
provided to us by the TA team.
===========================================================================

============================ SERVER DETAILS ===============================
(*) all server-related files are found in the @serv directory.

(*) a command received from a TCP client can only have 200 characters at
most.

(*) a command received from a TCP client needs to have its arguments
separated by spaces and it cannot have more than 5 arguments.

(*) when a TCP client subscribes to a topic, he will remain subscribed to
that topic until he unsubscribes. (he will remain subscribed to the topic
even if he disconnects and reconnects again to the server)

(*) the server logic is divided in the following modules:
	1) connection - offers an abstractization of the sys/soscket API
			in order to be able to use it in the data
			processing and client connection processes.

	2) data - offers functions for data processing at the application
		  layer.

	3) user - auxiliary module which offers function for client
		  representation at the application layer.

(*) since the @recv and @send syscalls may not send the number of bytes
given as parameter, two wrappers were made: @tcp_send and @tcp_recv
which send and receive bytes until the required number is reached.

(*) the server doens't check if the given port has an invalid format.
(unless @strtol doesn't set the errno value or doesn't return a
negative value, the server will consider the port valid)

(*) application-layer protocol details:
	(**) the server puts the messages it receives in a payload
	to which a "header" which contains information related to
	the UDP client which sent the message is appended.
	
	(**) the server will send to the TCP clients exactly
	sizeof(struct message) byts.

	(**) when a client disconnects, he is not deleted from the list of
	clients, but marked as inactive. If another client with another IP
	address tries to connect with the same ID as a client marked as
	inactive, then the inactive client's entry will be deleted and
	an entry for the new client will be added.
	
	(**) the server expects that the TCP client will immediatelly send
	his ID after establishing the connection.

	(**) the server expects that the message received from the client
	which contains his ID to be exactly 11 bytes long.
===========================================================================

============================ CLIENT DETAILS ===============================
(*) the client doesn't check if the ID is more than 11 characters long,
the server IP address has a valid format or if the port is invalid (as
long as the syscalls do not return an error, the client will consider
all of them valid)

(*) the command given by the user can't be longer than 200 characters and
can't have more than 5 arguments separated by spaces.

(*) application-layer protocol details:
	(**) the client will send exactly 11 bytes which contain its ID
	after establishing the connection with the server
	
	(**) the client expects that the server will send exactly
	sizeof(struct message) bytes when it wants to send him a meesage
	from a UDP client.
===========================================================================