Developer Guide
Project Architecture
High-Level Structure
oktopus/
├── agent/ # USP Agent configuration and examples
├── backend/ # Core backend services
│ └── services/
│ ├── controller/ # Main controller service
│ └── mtp/ # Message Transfer Protocol adapters
├── frontend/ # Next.js web application
├── deploy/ # Deployment configurations
└── docs/ # GitBook documentationBackend Architecture
The backend is built with Go and follows a modular service architecture:
Controller Service
Located in backend/services/controller/, this is the core service that manages devices and handles protocol communications.
Key Components:
API Layer (
internal/api/): REST API endpoints for device managementapi.go: Main API router and middleware setupDevice message handlers (GET, SET, ADD, DELETE operations)
CWMP Support (
internal/cwmp/): TR-069 protocol implementationHandles CWMP-specific operations like GetParameterNames, SetParameterValues
Entity Layer (
internal/entity/): Core business entities and data modelsDatabase Layer (
internal/db/): Database abstraction and persistenceBridge (
internal/bridge/): Communication bridge between services
MTP Adapters
The Message Transfer Protocol adapters handle different communication protocols:
WebSocket Adapter (
backend/services/mtp/ws-adapter/): Implements WebSocket MTP for USPMQTT Adapter: Handles MQTT-based communication
STOMP Adapter: Handles STOMP protocol
As mentioned in the USP MTP documentation, USP supports multiple MTPs including WebSockets, MQTT, and STOMP.
Frontend Architecture
The frontend is built with Next.js and located in frontend/. It provides a web interface for managing devices.
Development Setup
Prerequisites
Go: Version 1.23+
Node.js: Version 18+
NATS: Message broker for inter-service communication
Docker: For containerized development (optional)
Building the Services
Docker Development
From the root build/ directory, you can build all services at once:
Building Individual Microservices
Each microservice has its own build directory with a Makefile and Dockerfile. The general pattern is:
Available Backend Services:
Controller Service - Core device management
Built from:
cmd/controller/main.goBinary:
controllerBase image: Alpine Linux
ACS Service - Auto Configuration Server (CWMP)
Built from:
cmd/acs/main.goBinary:
acsBase image: Alpine Linux
MTP Adapters - Message Transfer Protocol handlers
WebSocket Adapter:
Built from:
cmd/ws-adapter/main.goHandles WebSocket connections for USP
WebSocket Service:
Built from:
cmd/ws/main.go
MQTT Adapter:
Built from:
cmd/mqtt-adapter/main.goHandles MQTT connections for USP
MQTT Service:
Built from:
cmd/mqtt/main.go
STOMP Adapter:
Built from:
cmd/stomp-adapter/main.goHandles STOMP connections for USP
STOMP Service:
Built from:
cmd/stomp/main.go
Generic Adapter:
Built from:
cmd/adapter/main.go
Utility Services
Socket.IO Service:
Node.js service for real-time communication
Base image: Node 16.20.2-alpine
File Server:
Serves firmware files and other static content
Bulk Data Collector
Built from:
cmd/http-bulk-collector/main.goCollects bulk data from devices [WIP]
Building the Frontend
Next.js application
Node.js 18.18.0-alpine base image
Production build with optimizations
Local Development
Backend Services (Go):
Frontend (Next.js):
Makefile Commands
Each service's Makefile supports these commands:
make build- Build Docker imagemake push- Push image to registrymake run- Create and start containermake stop- Stop running containermake remove- Remove containermake delete- Delete Docker imagemake logs- Show container logsmake bash- Access container shellmake release- Tag as latest and push
Customization:
Running the Services
The project includes:
Build configurations in
build/MakefileDocker Compose deployment in
deploy/compose/Kubernetes deployment in
deploy/kubernetes/
Code Organization
Backend Service Structure
The controller service follows a clean architecture pattern:
Pull Request Process
Fork the repository and create a feature branch
Make your changes following the code style guidelines
Write clear commit messages describing what and why
Test thoroughly with both protocols if applicable
Update documentation if you're adding new features
Submit a pull request to the main repository
Include in your PR description:
What problem does it solve?
How was it tested?
Any breaking changes?
Screenshots (for UI changes)
Understanding Key Concepts
Device Communication Flow
Device connects via MTP adapter (WebSocket/MQTT/STOMP for USP, or ACS connection for CWMP)
Adapter ingest and digest messages through NATS message broker
API endpoint at Controller processes the user requests
Message is queued and sent to the device
Response is awaited with timeout
Result is returned to the client
CWMP vs USP Implementation
The codebase supports both protocols:
CWMP (TR-069):
Synchronous request/response model
XML-based RPC
Direct parameter paths (e.g.,
InternetGatewayDevice.LANDevice.*.WLANConfiguration.*)See
internal/cwmp/for implementation
USP (TR-369):
Supports multiple MTPs (MQTT, WebSocket, STOMP)
Protocol Buffers encoding
More flexible messaging model
Documentation
When adding features, update:
Code comments: Especially for exported functions
GitBook docs in
docs/: Add user-facing documentationREADME files: Update relevant README files
API documentation: If adding new endpoints
Resources
Main Repository: github.com/OktopUSP/oktopus
Documentation: github.com/OktopUSP/docs
Community Slack: Join the Oktopus Slack
Rest API Spec: Oktopus Postman Documentation
USP Specification: Broadband Forum TR-369
CWMP Specification: Broadband Forum TR-069
Getting Help
Community Support: Available on Slack
Enterprise Support: [email protected]
Issues: Report bugs on GitHub Issues
License
Oktopus is released under the license specified in the LICENSE file. Make sure your contributions comply with this license.
Last updated