SECURITY & NETWORKS / UCT · CSC3002 · Collaborative / 2024
Coordinating peers over a network
A collaborative Python socket prototype separating peer discovery from direct messaging, with explicit transport and security trade-offs.
UCT / COURSE CONTEXT / 2024
CSC3002F · Computer Science 3002
Operating-system organisation and computer networks, with an Internet-protocol focus.
ENGINEERING PERSPECTIVE
Inside the work
Separate discovery from direct communication. A central coordination path locates peers, while a second transport carries messages; that separation exposes practical questions about framing, concurrency and trust.
- Python sockets / TCP
- A threaded coordination service handles registration and peer-address discovery.
- UDP / receive thread
- Clients exchange direct datagrams while receiving messages independently of input.
Coordinate
A client connects to the TCP service and issues delimiter-based control commands.
- Control and data planes
- Server-mediated discovery and peer message delivery have different responsibilities.
- Message framing
- TCP is a byte stream; one recv call is not a reliable application-message boundary.
- Security boundaries
- Neither TCP delivery nor UDP simplicity provides encryption, identity verification or safe password storage.
What the demonstration establishes
The diagram explains retained architecture. Source parsing and isolated server startup were checked; a full multi-client session or secure deployment is not claimed.
Evidence behind this page
Collaborative report and client/server source. Plaintext credentials and unauthenticated UDP are documented; shared source remains private.
What it is
Register and discover peers through a central server, then send chat messages directly as UDP datagrams.
Why it was built
Separate registration and discovery from direct peer messaging in a sockets-based networking assignment.
My contribution
Collaborative university project with three named report contributors. The supplied report does not allocate individual client/server modules; only the shared architecture is described.
How it works
A threaded TCP control service manages users and addresses; clients run a UDP receive thread for peer messages. The protocol is delimiter-based and instructional.
- 01Client
- 02TCP coordination
- 03Peer discovery
- 04UDP message
Technical implementation
- TCP clients connect to a threaded coordination server for registration, login, online status and peer-address discovery.
- Clients then exchange direct UDP datagrams, with a receive thread handling peer traffic.
- The string protocol uses delimiter-separated command/control/data messages. TCP needs explicit framing rather than assuming one recv equals one message.
- Loopback defaults replace hardcoded network addresses in the clean copy. Source parsing and isolated server startup were verified, not a complete multi-client session.
Results & evidence
- Source has been curated with configurable loopback defaults and an explicit security review.
Engineering challenges
TCP reliability and UDP low overhead do not provide confidentiality. The historical report overstates privacy: plaintext passwords and unauthenticated datagrams remain real limitations.
Scope & limitations
Plaintext passwords, unauthenticated UDP and weak framing are known limitations. This is networking coursework, not a secure chat product; run it only in an isolated lab.
What I learned
Control-plane versus peer data paths, protocol state and the difference between networking behaviour and security guarantees.
What I would improve now
Add framed messages, authenticated transport, safe password storage and replay/error handling in a clearly labelled post-project version. Keep the current prototype lab-only.