Skip to content

Network Overview

Jump to bottom
Leland Miller edited this page Aug 29, 2014 · 6 revisions

SlugCam Network Overview

See the code at SlugCam/SCnet on GitHub.

The SlugCam network consists of all software written for the project that does not exist on individual camera nodes and all specifications regarding protocols and design of the network.

Introduction

SWEETnet contains all of the network software behind the SWEETcam system.

SWEETnet consists primarily of:

  • A message server responsible for sending and receiving messages to the cameras.

  • A video server responsible for receiving video from the clients and sending it to the clients.

  • An API server providing an interface to end-user applications.

We are also developing a client web app.

  • Flexible for new applications and changing protocols

  • Modular so portions can be developed independently and well tested (each section with well defined interfaces)

Milestones

In order to facilitate progress in the project we will focus on milestones as we go.

M1 (In Progress)

  • Work on the basic server structure, without worrying about security at this point. This will allow us to determine the feasibility of our approach.

  • Continue research into related areas, documenting research and all work on the project.

  • Build a basic end to end testing framework. (build unit tests as needed)

  • Continue developing protocols for storage and communication in line while communicating with the SWEETcam team, knowing that these may change in the future.

Module Overview

We use a modular design, as shown in the following diagram:

  • Insert Diagram

Message Server

API Server

The API server should present a consistent interface. The API server presents a RESTful interface as described in the API Specification.

Message Server

The message server acts as the main interface between the network and the cameras. It handles all communication to the cameras, along with all non-video communication from the cameras.

The protocol as it currently stands, is that the message server takes JSON message objects, separated by newlines.

Video Server

Data Storage

The data storage requirements for this project are can be abstracted into the following.

  • Outgoing Messages
  • Stages
  • Message Store
  • Videos
  • Cameras

A storage API exists in db.js that requires to following major functions:

  1. Store Message
  2. Queue Message
  3. Video Functions
  • Models

    • Camera

    • {
    •   name: camera_name

    •   lat: camera_latitude

    •   lng: camera_longitude

    •   lastMessage: datetime

    •   lastVideo: datetime
    • }

    Technology Choices

    MongoDB

    Using MongoDB during initial phases because it allows us to change our data structure very fluidly while protocols and data structures are being developed.

    Node.js

    Node.js is a JavaScript interpreter frequently used for server-side programming. We have decided to implement our project using Node.js in its initial stages for several reasons.

    1. Familiarity of developers.

    2. Rapid development process.

    3. Prevalence of built-in and existing libraries for network development.

    Clone this wiki locally