RC Event Booking System

Simple client/server event booking system for a Computer Networks project.

This repository contains a C implementation of a small booking platform with separate client and server programs and a shared common library.

Structure

• client/ — client source and helpers.
• server/ — server source, stores events and user data.
• common/ — shared utilities used by both client and server.

Build

The repository includes a Makefile that compiles the code and places executables in the repository root. To build everything, run:

make

Notes:

• The Makefile produces executables in the repository root. The Makefile will name the executables user and ES to avoid colliding with directories.
• make clean removes object files, the static common library and the built executables.

Running the server and client

Open two terminals (one for server, one for client).

1. Start the server (terminal A):

./ES [-p ESport] [-v]

• ESport - the port number where the event server is going to accept requests (UDP & TCP). Default value is 58041.
• If the -v option is set, the program operates in verbose mode, outputting to the screen a short description of the received requests (UID, type of request) and the IP and port originating those requests.

2. Start the client (terminal B):

./user [-n  ESIP] [-p ESPORT] 

• ESIP - the IP address of the machine where the event server is running. Default value is localhost.
• ESport - the port where the event server is accepting requests (UDP & TCP). Default value is 58041.

How to change timeout values

Both the user and the event server have a timeout value for communicating with each other. You can change this value by changing the TIMEOUT_SECS macro in common/validate.h. You then need to make clean and make again.

A value of 0 means that requests will never timeout.

Using the client

Run the client and type commands at the > prompt. Available commands include:

• login <uid> <password>
• changePass <old> <new>
• unregister
• logout
• exit
• create <name> <event_name> <event_date> <num_attendees>
• close <eid>
• myevents / mye
• list
• show <eid>
• reserve <event_id> <num_seats>
• myreservations / myr
• help

About Our Data Storage Structure

We followed the in-class guide with the following modifications:

• Instead of a single END.txt file, we use two separate files: FINISHED.txt and CLOSED.txt. FINISHED.txt indicates that the event date has already passed, while CLOSED.txt indicates the event was closed manually by its creator. Splitting these statuses makes it easier and faster to verify an event's current state.

• For reservation files, we use naming conventions that make intent and provenance clear:

  • In the EVENTS directory, reservation files follow the format RES_uid_date_time.txt (as specified in the assignment), so each file clearly identifies the user who made the reservation and when.
  • In the USERS directory, reservation files are named RES_eid_date_time.txt so it is immediately clear which event that user reserved.

These small changes improve clarity and simplify state checks when the server needs to determine whether an event is finished, closed, or which event a user reserved.

Signals and graceful shutdown

• The client handles Ctrl-C (SIGINT) and, if logged in, will attempt to logout before exiting.
• The server may install a SIGINT handler to enable graceful shutdown; check server/utils.c for details.

Contributors

Beatriz Braga

Rodrigo Santos