Network Topology
Select a protocol layer to visualize different communication patterns
REST API mode
Message Log
No messages yet — click Request Ride to start a simulation.
Compare Protocols
Side-by-side view of all three communication patterns
REST API
Rider
→ POST /ride
Server
→ ASSIGN
Driver
- HTTP/1.1 Request / Response
- Centralized routing via server
- JSON payloads with status codes
- Stateless — each request is independent
3Hops
~120msLatency
HighReliability
TCP / UDP
Rider
→ SYN
Server
→ ACK
Driver
- TCP Reliable streams + UDP fast datagrams
- Persistent socket connections
- Binary frame protocol
- Connection state: SYN → ACK → DATA
2-3Hops
~45msLatency
MixedReliability
P2P Mesh
Rider
→ DISCOVER
Driver
→ DIRECT
Rider
- DHT Distributed hash table lookup
- No central server required
- Direct peer connections
- Gossip protocol for discovery
1Hops
~20msLatency
VariesReliability
Layered Architecture
How the communication stack is structured
Layer 3
Application Layer
REST API endpoints for ride requests, driver matching, and status updates. JSON serialization with HTTP verbs (GET, POST, PUT).
RESTJSONHTTP/1.1
Layer 2
Transport Layer
TCP for reliable ordered delivery of ride confirmations. UDP for real-time location broadcasts with minimal overhead.
TCPUDPSockets
Layer 1
Network / P2P Layer
Peer-to-peer mesh for direct rider-driver communication. DHT-based discovery eliminates single points of failure.
P2PDHTGossip
Cross-cutting
Lamport Logical Clocks
Every node maintains a logical clock. On send: clock++. On receive: clock = max(local, received) + 1. Ensures causal ordering across the distributed system.
LamportCausal OrderVector Clocks