Tidy Duck Installation

Dependencies

MySQL Setup

Database Configuration

Put the connection details in the file:
conf/server.conf

Enable Strict Mode

Edit /etc/mysql/my.cnf, add the following line below the 'query-cache-size' property (under the [mysqld] heading):

sudo vim /etc/mysql/my.cnf
sql_mode = TRADITIONAL

(This will enable strict mode in order to enforce data integrity constraints.)

Create MySQL User

Create the application sql-account (with limited access)

Be sure to modify the command below to use the password set within conf/server.conf

mysql -u root -p tidy_duck -e "CREATE USER 'tidy_duck'@'%' IDENTIFIED BY '__PASSWORD__'; GRANT SELECT, INSERT, UPDATE, DELETE ON tidy_duck.* TO 'tidy_duck'@'%'; FLUSH PRIVILEGES;"

If the above command fails the tidy_duck user already exist and needs re-created, the following command will delete it:

mysql -u root -p tidy_duck -e "DROP USER tidy_duck;"

Create User Accounts

  1. Update the accounts sql-script:

    The default password provided is "quack quack".

    vim sql/init-accounts.sql
  2. From the tidy-duck directory, connect to MySQL and run the sql script:
    mysql -u root -p
    use tidy_duck;
    source sql/init-accounts.sql

Compilation

Tidy Duck uses Java with Gradle to compile the application.

Be sure a java-jdk is installed for your system.

It may be a wise choice to compile the project on your local machine instead of the server.

A convenience script is located at:
scripts/make.sh

This script will output all of the necessary application files to the local out directory.

Deployment

After building the application with the make.sh script, upload the contents of the out directory to a desired location on your server.

You may start the application using the generated run.sh. Alternatively, you may setup a systemctl service or daemon of your choice to run the run.sh script or emulate the script's behavior.

Web Access

Tidy Duck uses a lightweight Java servlet that is configured to listen on port 8080 by default.

Depending on your network configuration, it may be best to setup a reverse proxy.

Alternatively, you may configure Tidy Duck to listen on the port of your choice by adding the server.httpPort property to the conf/server.conf file. You may also specify the TLS port with the server.tlsPort property.

Troubleshooting

Depending on the server setup prior to installation you may need to take some additional steps to get started.

Can't access application on configured port

It's possible that a firewall setting is preventing traffic to the configured port. Try temporarily disabling iptables or working with a system administrator to check any other firewall or network settings that might be preventing access.

Permission denied error when accessing the database

This can be caused by SELinux not allowing name-based resolution of the database server or some other restriction.

Application fails to connect to embedded database

This can occur when running the application as root server user. It is recommended to start the application as another user.



Definitions

Tidy Duck's MOST Function Catalog is largely a collection of collections where:

  • A Function Catalog is represented as a collection of Function Blocks.
  • A Function Block is represented as a collection of Interfaces.
  • An Interface is represented as a collection of Functions.
  • A Function is represented as a collection of Operations.

Since the MOST Function Catalog is released in XML, all strings must comply with XML 1.0 requirements. The XML schema must comply with those required by MOST 3.0E2. Naming of objects is expected to comply with the API Style Guide.

Function Catalogs

In order for a Function Catalog to be considered valid, it must contain the following identifying information:

  • Release Version
    • The version is a string in the form Major.Minor.Revision, where Revision is optional.
  • Release Date
    • The date is a string representing the release date of this Function Catalog in the form of DD-MMM-YYYY (2 digit Date, 3 character abbreviation for Month, 4 digit year).
  • Author
    • The Author is a string indicating the name of the release engineer for the Function Catalog (e.g. Joe Smith) A Company. The Company is a string indicating the name of the company responsible for the Function Catalog (e.g. Software Verde, LLC.).
  • One or more valid Function Blocks.

Function Blocks

In order for a Function Block to be considered valid, it must contain the following identifying information:

  • ID
    • A single byte used to address and uniquely identify the Function Block within a Function Catalog, displayed in Hexadecimal (e.g 0x22).
  • Kind
    • A field reserved by MOST to indicate the classification of Function Block, should be "Proprietary" by default.
  • Name
    • A string used to identify the Function Block in a descriptive manner (e.g. "Amplifier").
  • Description
    • A detailed description of the Function Block that provides guiding information to the user (e.g. "Contains functions relevant to controlling audio output via the Amplifier").
  • Release Version
    • The version is a string in the form Major.Minor.Revision, where Revision is optional.
  • Author
    • The Author is a string indicating the name of the release engineer for the Function Block (e.g. John Smith)
  • Company
    • The Company is a string indicating the name of the company responsible for the Function Catalog (e.g. Software Verde,LLC).
  • One or more valid Interfaces.

Interface

In order for an Interface to be considered valid, it must contain the following identifying information:

  • ID
    • An integer that uniquely identifies this interface within a Function Catalog.
  • Name
    • A string used to identify the Interface in a descriptive manner (e.g. "IQuery").
  • Version
    • A byte that increments with every released change of the interface.
  • Description
    • A detailed description of the Interface that provides guiding information to the user (e.g. "IQuery defines the contract required for querying implemented interfaces within a Function Block").
  • One or more valid Functions.

Functions

In order for a Function to be considered valid, it must contain the following identifying information:

  • An ID
    • An unsigned short used to address and uniquely identify the Function within a Function Block, displayed in Hexadecimal (e.g. 0x422).
  • A Name
    • The name is a string used to identify the function in a descriptive manner (e.g. "SetMainVolume"). A Release Version. The version is a string in the form Major.Minor.Revision, where Revision is optional.
  • A Description
    • A detailed description of the Function that provides guiding information to the user (e.g. "SetMainVolume will change the MainVolume property to the input value. If the value does not match requirements, Parameter Value Invalid error will be returned.").
  • An Author
    • The Author is a string indicating the name of the release engineer for the Function (e.g. Joe Smith).
  • A Company
    • The Company is a string indicating the name of the company responsible for the Function Catalog (e.g. Software Verde, LLC).
  • One or more valid Operations.

Operation

In order for an Operation to be considered valid, it must contain the following identifying information:

  • An OpCode
    • A nibble used to address and uniquely identify the Operation within the Function, displayed in Hexadecimal (e.g. 0xC).
  • An Associated Type
    • A list of types which must have instances provided to the function in order to execute the operation. If the operation is an input/invocation operation (i.e. IsInput is True), then Associated Types correspond to the parameters of the function. If the operation is an output/return operation (i.e. IsInput is False), then Associated Types must contain the return type and only the return type.
  • An indication of IsInput.
    • A bool used to indicate the direction of the operation on the network.
    • True is used to indicate that this operation invokes some function on the receiver or client.
    • False is used to indicate that this operation returns some result or data from the receiver or client.
  • Operation, in this object model, is considered abstract as operations must comply with one of the operations specified by the MOST 3.0E2 specification. These are: Get, Set, Status, Error, StartResultAck, ResultAck, ProcessingAck, AbortAck, and ErrorAck.

Operations

Operation, in this object model, is considered abstract as operations must comply with one of the operations specified by the MOST 3.0E2 specification.

These are: Get, Set, Status, Error, StartResultAck, ResultAck, ProcessingAck, AbortAck, and ErrorAck.

Input Operations

The Input Operations (IsInput is True) are as follows:

  • Get
    • OpCode: 0x1
    • AssociatedTypes: Void
  • Set
    • OpCode: 0x0
    • AssociatedTypes: Return type of Property
  • StartResultAck
    • OpCode: 0x6
    • AssociatedTypes: SenderHandle of Method invocation and Parameters of Method
  • AbortAck
    • OpCode: 0x7
    • AssociatedTypes: SenderHandle of Method invocation

Output Operations

The Output Operations (IsInput is False) are as follows:

  • Status
    • OpCode: 0xC
    • AssociatedTypes: Return type of the Property
  • Error
    • OpCode: 0xF
    • AssociatedTypes: ErrorCode (enumeration) and ErrorInfo (byte array)
  • ResultAck
    • OpCode: 0xD
    • AssociatedTypes: Return type of Method
  • ProcessingAck
    • OpCode: 0xA
    • AssociatedTypes: SenderHandle of Method invocation
  • ErrorAck
    • OpCode: 0x9
    • AssociatedTypes: SenderHandle of Method invocation, ErrorCode (enumeration) and ErrorInfo (byte array)

Function Stereotypes

Properties

Function Stereotypes relate directly to various attributes of objects in other languages (ex. Java, C#, etc) within the MOST Object Model, these stereotypes can be subdivided into Properties and Methods.

The property stereotypes (Event, ReadOnlyProperty, ReadOnlyPropertyWithEvent, PropertyWithEvent) contain public, identifying state information. All properties have the Status and Error Operation, and may also support the Get and/or Set Operation.

Properties are differentiated by three factors:

  • Do they support the read operation (Get)?
  • Do they support the write operation (Set)?
  • Do they support notification?

Event, similar to events in Java/C#, contains no permanent state and is used to indicate to a client that something of interest happened. Event does not support the Get or Set Operations, but must support notification.

ReadOnlyProperty contains a semi-permanent state, meaning this state is not expected change frequently (or at all). ReadOnlyProperty supports the Get Operation, but does not support notification or the Set Operation.

ReadOnlyPropertyWithEvent contains a transient state, meaning this state is expected to change frequently. ReadOnlyPropertyWithEvent supports the Get Operation and notification, but does not support the Set Operation.

PropertyWithEvent contains a transient state, which is modifiable by the client. PropertyWithEvent supports the Get and Set Operations and supports notification.

Methods

The method stereotypes (CommandWithAck and Request/Response) correspond to client-facing operations provided by the server or Function Block. All methods have the StartResultAck, ResultAck, ProcessingAck and ErrorAck Operation, and may also support the AbortAck Operation.

Methods are differentiated by one factor:

  • Is the method stateless?

CommandWithAck methods are not stateless, meaning they are allowed to trigger changes on the server, and their response may be dependent on time/state information. CommandWithAck methods are blocking, and do not support the AbortAck Operation.

Request/Response methods are stateless, meaning they are not allowed to trigger changes on the server, but they do not block and can support parallel requests. Request/Response methods support the AbortAck Operation.