The client is operated using a command-line interface. Upon running the script, the client will attempt to connect to a camera at the IP indicated in the network settings file. The user will be prompted to enter a password. If accepted, the user will be granted access to a menu allowing access to the camera's features. These features include the ability to download or delete videos saved by the camera, access to a live feed of the camera data, and the ability to remotely configure settings on the camera such as resolution, server password, image parameters, encryption, and video length. The IP and ports used by these functions are user configurable on both the client and server sides: they must be properly set for the client and server to connect.

Basic .json configuration files are used on both the client and server side to allow for configuration of the camera system's parameters.

The system uses several ports to exchange data. Authentication, camera configuration, and remote file access use TCP sockets to exchange data with the client; this is due to the fact that data integrity is vital for these operations. Livestreaming data from the camera, however, uses a UDP socket to maximize throughput from the server to client.

This system makes use of a custom application layer protocol for live data exchange between the server and host. As the system uses UDP for streaming live image data, the data is subject to a relatively-small MTU value that must be overcome. This is assumed to be 65536 for a given system, but may have to be adjusted to fit a user's needs based on their system's MTU. The server gets around this by segmenting UDP data into smaller datagrams and recombining them at the client side (much like TCP). Packets exchanged between server and client for the livestream function use the following structure:

-1 bit: encryption flag (is the data encrypted?)

-32 bits: size of image payload (in bytes)

-32 bits: timestamp (Unix time)

-32 bits: packet number in sequence

-32 bits: number of packets in sequence

-32 bits: AES initialization vector

-512 bits: HMAC

-variable size: data payload

The system implements some basic features to ensure secure data transmission between the client and server components. Passwords are hashed with SHA-256 before the client transmits it to the server; this password is also stored hashed on the server side. RSA-2048 key pairs (generated by client) are used to exchange symmetric keys for AES-256 encryption, which are generated with OS.urandom(). When enabled, all image data (and password changes) transferred between the client and server is encrypted with AES-256.
 
Hash-based message authentication codes (HMAC) are appended to all data transmissions to verify their authenticity; the key used to generate these codes is initially exchanged with the RSA key pair. If the HMAC appended to any message is invalid, the data is discarded and no action is taken.

The camera is designed to automatically record videos if significant differences between frames are detected. When the mean squared error between two consecutive frames has exceeded a user-set threshold, the camera will begin recording a video of a user-configurable length (in seconds). This video is then stored on the server's filesystem. Video files are tracked by a basic .json file. A user may download these files from the server using the client program or remotely delete them. 

The user may configure some settings on the server side with the configuration script in the client program. These settings include recorded video length, camera resolution, image contrast and saturation, server password, encryption (on/off), sensitivity to trigger a video recording, and livestreaming (on/off). Updates to these settings will be reflected by changes to a .json file on the server side and will persist until changed by the client or manually changed by file manipulation on the server side.