AUBus Premium

A campus carpooling system built around the network

AUBus Premium was my EECE 351 course project at AUB. I built a desktop prototype that lets passengers request rides and lets available drivers accept them, with the server coordinating accounts, schedules, matching, and live notifications.

The interface covers connection setup, account creation, passenger and driver dashboards, settings, localization, and a simulated in-ride view. The networking path is concrete: a ride request travels through an explicit protocol and persisted state instead of remaining a UI-only demonstration.

Framing messages on top of TCP

TCP delivers a byte stream, so one receive call is not guaranteed to contain one complete application message. I gave each UTF-8 JSON payload a four-byte, big-endian length header. The client and server read exactly that many bytes before decoding the message, which keeps adjacent or fragmented payloads from being confused.

data = json.dumps(payload).encode("utf-8")
length = struct.pack("!I", len(data))
conn.sendall(length + data)

The protocol stays small and inspectable. Actions such as login, request_ride, and accept_ride share the same envelope, while unsolicited events such as incoming_ride_request use the same framing in the opposite direction.

Keeping network work away from the Qt event loop

The desktop client receives messages on a daemon thread and places them in a thread-safe queue. A Qt timer drains that queue on the UI thread every 100 milliseconds. This prevents socket reads from freezing the window and avoids updating Qt widgets from a background thread.

On the server, each connection gets a dedicated handler thread. A locked registry maps authenticated usernames to active handlers, which lets the ride matcher push requests to drivers who are currently connected and notify a passenger when a driver accepts.

Matching drivers and closing the ride loop

A ride request is stored in SQLite before notifications are sent. The matcher filters drivers by area, weekday, a 15-minute schedule window, and an optional minimum rating. Acceptance changes the persisted request from pending to accepted and sends the passenger the driver's username, rating, and peer-to-peer port.

SQLite opens a connection per operation, which keeps the small threaded prototype straightforward. The matcher also falls back to drivers in the same area when no schedule matches. That behavior makes the classroom demo easier to exercise, but a real service should surface an empty result or rank alternatives instead of silently relaxing the constraint.

Authentication, localization, and supporting context

The PyQt client includes an installed-app Google OAuth flow and email verification codes sent through SMTP2GO or SMTP. OTP values are hashed in memory, expire after 10 minutes, and allow five attempts. A weather panel fetches current conditions for Lebanese areas through WeatherAPI.

The interface is translated into English, Arabic, and French. Switching to Arabic also changes the application direction to right-to-left, while the same screens support light and dark themes.

What building it taught me

AUBus changed how I think about state in a networked application. A screen can appear complete while the system behind it still has several competing versions of the same ride, user, or connection. Following one request through the Qt event loop, TCP protocol, server handler, and SQLite database made state ownership a concrete design problem rather than an abstract rule.

It also showed me how choices made for a classroom demonstration shape the architecture. Fallback matching and local demo profiles kept the full workflow easy to present, but they blurred which guarantees belonged to the server. If I revisited the project, I would start by defining one owner for each piece of state, then design the protocol and interface around those boundaries. That clarity would improve the system more than adding another visible feature.