This document is current as of Mnet v0.6. There are some small inaccuracies about the structure of some messages, but nothing that really changes the meaning.

Mnet Messages Overview

Note: the purpose of this document is to inform about the contents of Mnet network messages and their rationale at a high level of abstraction. It is a technical document and contains much technical fact; some of the details are glossed over or altered for clarity and simplicity. Do not use this document for an accurate specification of the actual messages down to the last bit. However, once you have understood the general idea from this document, it should be easy to understand the specific details from the well-documented reference source code, or from other more precise specification documents which have not yet been written.

See "OurMessage.py", "OurMessagesTokens.py", and "OurMessagesPublicKey.py" files for more detailed specifications. Those files contain templates used to validate the contents of the messages. They also provide a readable specification of the message formats and contents.

The messages in the Mnet system are grouped according to the major feature of the system that they implement: network maintenance, block search and retrieval, message relay service, and content tracking.

Conventions used in this document:

Representing data:

{ }
a table of "key: value" pairs separated by commas
[ ]
a list of items separated by commas
' '
a string literal
2358203 and other numbers
integers of arbitrary size
true and false
boolean values
'01CDEFGHIJKLMNOPQRSTUVWXYZA'
a string literal that contains a 160-bit unique ID
"7H8J9K0L"...65536 bytes total..."A2D3G5H7"
a string literal that contains a 65536 bytes

Message descriptions:

Each message description is in this format:

Introductions: Building and Maintaining the Network

Introducing One Node To Another

contact info

Contact info contains an RSA public key, a list of one or more "comm strategies", and a list of zero or more services offered by the node. It also includes an incrementing counter (called a "sequence num") so that newer contact info can be used in preference to older. The version number of the node is included for debugging purposes.

Contact info is not actually a stand-alone message, it can be appended onto other messages. The "hello" message is a message that gets sent from nodes to metatrackers which contains nothing but contact info. In addition, any other message between any two nodes may also contain contact info for zero or more other nodes. (This piggybacking of contact info on other messages enables the network to adapt and heal during normal operaton without sending separate messages.)

Example:
{
    'pubkey': {
        'key header': {
            'cryptosystem': 'RSA',
            'type': 'public',
            'usage': 'only for communication security'
        },
        'key values': {
            'public exponent': 3,
            'public modulus': "8vJcUz7w"...128 bytes total..."JhJho1Wi"
        }
    }
    'comm strategies': [ {
            'comm strategy type': 'TCP',
            'IP address': '140.184.83.25',
            'port number': 20035
        }, {
            'comm strategy type': 'Relay',
            'relay server ID: '098765432112345678901234567'
        }
    ],
    'sequence num': 16,
    'services': {
        'block server': {
            'centerpoint': 9249037,
            'stddev': 2358203
        },
        'relay server': true,
        'content tracker': true
    }
    'node version': '0.5.1.19-STABLE'
}

Original Introduction

bootpage
The bootpage is a tiny text file served via HTTP used to bootstrap a node onto the system by providing it with the contact info for one or more meta trackers. Example: http://www.haknam.de/bootpage.txt

Block Search and Retrieval: Delivering Data

Block Publication: Storing Data

Relay: Routing Around Obstacles to Communication

Content Tracking: Providing a Directory of Available Content

Zooko, mnet-devel mailing list
Last modified: Mon Oct 6 08:16:09 EDT 2003