Project

General

Profile

Feature #24382

Create v2 of DPM protocol

Added by Richard Neswold 6 months ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Category:
Protocol
Target version:
-
Start date:
05/07/2020
Due date:
% Done:

0%

Estimated time:
Duration:

Description

After using v1 of the DPM protocol for several years, we've found some deficiencies. This issue will document and track an update to the protocol.

Setting Up Lists is Slow

Each DRF string is sent as an individual request/reply. Many apps have hundreds of devices (some have over a thousand!) and setting up lists takes a while. We've reduced the time for the biggest lists to few seconds, but it could be much faster. The ADD_TO_LIST request should take an array of RefID/DRF string pairs. Even though the packet will be much larger, it'll greatly reduce the number of transactions needed to set up the list:

struct drf_entry {
    int64 ref_id;
    string drf;
}

request AddToList {
    drf_entry data_req[];
}

reply AddToList {
    int16 status[];
}

Need to Support FTP

We want DPM to seamlessly switch to FTP for data requests faster than 15Hz. The clients should see the same messages for all acquisition, though. Currently, Charlie and Beau have abused the current protocol to get FTP to work but it shouldn't be the final solution. Under the new protocol, all data returns will be an array of timestamp/data pairs. For slow acquisition, the array will have one entry. Clients will always process the entire array that is returned which means they'll automatically handle fast and slow rates.

(This example is going to be optimistic and assume #11454 will have been completed so we can use union types.)

enum DataType {
    RawVal(binary),
    ScalarVal(float),
    TextVal(string),
    ScalarArray(float[]),
    TextArray(string[])
}

struct Sample {
    int64 timestamp;
    DataType value;
}

reply DeviceData {
    int64 ref_id;
    Sample data[];
}

Settings Protocol

Settings should probably get pulled out of this protocol and placed in a new one. The client shouldn't fill in the username because it can be faked. The DPM should be able to pull the user from whatever credential scheme we use.

History

#1 Updated by Richard Neswold 6 months ago

  • Description updated (diff)

Even after proofreading, there were mistakes in the content.

#2 Updated by Richard Neswold 6 months ago

  • Description updated (diff)

Add a comment about settings.

Also available in: Atom PDF