Difference between revisions of "Message Bus Messages"

From truxwiki.com
Jump to navigation Jump to search
Line 352: Line 352:
  
 
==Website Visit==
 
==Website Visit==
The <code>[https://github.com/Probity/Truxton/blob/master/Libraries/Truxton/TruxtonWebsteVisit.h WEB_SITE_VISIT]</code> structure is as follows:
+
The <code>WEB_SITE_VISIT</code> structure is as follows:
 
<syntaxhighlight lang="c++">
 
<syntaxhighlight lang="c++">
 
struct WEB_SITE_VISIT
 
struct WEB_SITE_VISIT

Revision as of 13:26, 18 May 2020

The core of Truxton is the message bus.

Message Structure

Here's the C/C++ structure:

struct TRUXTON_MESSAGE
{
    GUID      file_id;
    GUID      parent_id;
    GUID      media_id;
    GUID      depot_id;
    uint64_t  offset;
    uint64_t  length;
    uint8_t * file_contents;
    uint32_t  queue_is_empty;
    uint32_t  route_id;
    uint32_t  priority;
    uint32_t  signature;
    uint32_t  dont_route;
    uint16_t  file_type;
    uint16_t  types[16];
    char      depot_filename[MAX_PATH];
    char      md5[33];
};

The TRUXTON_MESSAGE structure is 440 bytes long.

Message Database Record

Truxton uses PostgreSQL to be the message queue server. The template for a message queue is defined in the C:\Program Files\Truxton\Database\create-tmb-tables.sql file. All message queues have the following schema:

CREATE TABLE "queue template" (
    "QueueItemID" uuid DEFAULT (md5(((random())::text || (clock_timestamp())::text)))::uuid PRIMARY KEY,
    "QueueItemAvailable" boolean NOT NULL,
    "Priority" integer DEFAULT 1000 NOT NULL,
    "RouteID" integer NOT NULL,
    "FileID" uuid NOT NULL,
    "ParentID" uuid NOT NULL,
    "MediaID" uuid NOT NULL,
    "DepotID" uuid NOT NULL,
    "Offset" bigint NOT NULL,
    "Length" bigint NOT NULL,
    "MD5" character(32) NOT NULL,
    "Signature" integer NOT NULL,
    "Type" smallint NOT NULL,
    "Types" smallint[],
    "DepotFilename" text NOT NULL,
    "Don't Route" boolean NOT NULL,
    "File Contents" varchar(64000)
);

Mapping Other Messages to this Structure

By mapping structures that have nothing to do with files to the Truxton Message structure, we can leverage all of the message queue code. We map several other types of message to this message structure.

Camera Information (EXIF)

The WEB_SITE_VISIT structure is as follows:

struct EXIF_OFFSETS
{
    uint64_t exif{ 0 };
    uint64_t make{ 0 };
    uint64_t model{ 0 };
    uint64_t body_serial_number{ 0 };
    uint64_t lens_serial_number{ 0 };
    uint64_t latitude{ 0 };
    uint64_t longitude{ 0 };
    uint64_t altitude{ 0 };
    uint64_t heading{ 0 };
    uint64_t focal_length{ 0 };
    uint64_t shutter_count{ 0 };
    uint64_t gps_time{ 0 };
    uint64_t device_time{ 0 };
    uint64_t thumbnail_offset{ 0 };
    uint64_t thumbnail_length{ 0 };
};

struct EXIF_DATA
{
    EXIF_OFFSETS offsets;
    uint64_t     gps_time{ 0 };
    uint64_t     device_time{ 0 };
    double       latitude{ 0 };
    double       longitude{ 0 };
    double       altitude{ 0 };
    double       heading{ 0 };
    double       focal_length{ 0 };
    int32_t      shutter_count{ 0 };
    uint32_t     thumbnail_offset{ 0 };
    uint32_t     thumbnail_length{ 0 };
    wchar_t      make[128]{ 0 };
    wchar_t      model[128]{ 0 };
    wchar_t      body_serial_number[64]{ 0 };
    wchar_t      lens_serial_number[64]{ 0 };
};

Truxton Message Mapping

The structure members map to the Truxton Message structure as follows:

TRUXTON_MESSAGE EXIF_DATA
depot_id (high 64) gps_time
depot_id (low 64) device_time
offset latitude
length longitude
types[0] - types[3] altitude
types[4] - types[7] heading
types[8] - types[11] focal_length
signature shutter_count
depot_filename make, model, body_serial_number, lens_serial_number
types[12] - types[15] offsets.exif

Event

The CALENDAR_EVENT structure is as follows:

struct CALENDAR_EVENT
{
    uint32_t     event_type_id;
    uint64_t     start;
    uint64_t     end;
    std::wstring title;
    std::wstring description;
};

Truxton Message Mapping

The structure members map to the Truxton Message structure as follows:

TRUXTON_MESSAGE CALENDAR_EVENT
signature event_type_id
offset start
length end
depot_filename title
depot_filename description

The remaining data items are:

TRUXTON_MESSAGE Data Item
file_id A GUID that corresponds to the ID column of the File table in the database. It holds the identifier of the file this event came from.
media_id A GUID that corresponds to the ID column of the Media table in the database. It holds the identifier of the media this event came from.
parent_id A GUID that corresponds to the ID column of the Event table in the database.

ETL Status

The TRUXTON_STATUS_MESSAGE structure is as follows:

struct TRUXTON_STATUS_MESSAGE
{
    TGUID    ETL_ID;
    TGUID    Media;
    uint64_t Sent;
    uint64_t Received;
    uint32_t Stage;
    uint32_t SentFromProcessID;
    char     FriendlyName[64];
};

Truxton Message Mapping

The structure members map to the Truxton Message structure as follows:

TRUXTON_MESSAGE TRUXTON_STATUS_MESSAGE
parent_id ETL_ID
media_id Media
length Sent
depot_filename Received
offset Stage
signature SentFromProcessID
md5 FriendlyName

The remaining data items are:

TRUXTON_MESSAGE Data Item
file_id A GUID with the first two bytes set to 0xFA 0xCE (FACE).

How it Works

Each ETL will report what it is doing via status messages. Here is what each message means:

Dump

When this message is sent from an ETL, it tells the Load Status Monitor (Les) to generate a debugging dump.

TRUXTON_STATUS_MESSAGE Value
Stage 253
ETL_ID DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD
Media DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD
FriendlyName Dump

Ping

This tells Les that the ETL process is still processing a file. Les has no way to know if an ETL process dies since Les may be running on a different machine than the ETL process. For this reason, Les will give an ETL a certain amount of time to process a file before it assumes that ETL is either stuck in an endless loop or died. Sending a ping message to Les will prevent him from timing the ETL out.

TRUXTON_STATUS_MESSAGE Value
FriendlyName Ping

New

This tells Les that the ETL process is starting to process new media.

TRUXTON_STATUS_MESSAGE Value
FriendlyName New

Idle

This tells Les that the ETL process isn't processing anything, it is waiting for something to do.

TRUXTON_STATUS_MESSAGE Value
FriendlyName Idle

Verbose On

This tells Les to turn verbose logging on.

TRUXTON_STATUS_MESSAGE Value
Stage 200
ETL_ID 56565656-5656-5656-5656-565656565656
Media 4E4E4E4E-4E4E-4E4E-4E4E-4E4E4E4E4E4E
FriendlyName Set Verbose On

Verbose Off

This tells Les to turn verbose logging off.

TRUXTON_STATUS_MESSAGE Value
Stage 200
ETL_ID 56565656-5656-5656-5656-565656565656
Media 66666666-6666-6666-6666-666666666666
FriendlyName Set Verbose Off

Website Visit

The WEB_SITE_VISIT structure is as follows:

struct WEB_SITE_VISIT
{
    char const * account;
    char const * url;
    uint64_t     when;
    uint64_t     offset_of_url;
    uint64_t     offset_of_account;
    uint16_t     type;
    uint16_t     method;
    char         local_filename[256];
};

Truxton Message Mapping

The structure members map to the Truxton Message structure as follows:

TRUXTON_MESSAGE WEB_SITE_VISIT
types[0] type
signature method
offset offset_of_url
length when
depot_filename url

The remaining data items are:

TRUXTON_MESSAGE Data Item
file_type Type_Website_Visit
file_id The GUID of the file the website visit came from
media_id The GUID of the media the website visit came from
parent_id The GUID of the website visit. This corresponds to the ID column of the WebsiteVisit table in the database.

Note: Long URLs

If TRUXTON_MESSAGE.types[1] is set to 1, it means that the entire contents of WEB_SITE_VISIT.url could not be stored in TRUXTON_MESSAGE.depot_filename When this happens, the receiver of the message should retrieve the full record from the WebsiteVisit table where the ID column is equal to the GUID in parent_id.