On Bitcoin Messaging Terminology

Stream-of-Consciousness for choosing codebase terminology to help structure the code for a node repository

Most networking applications lay out a code structure for making RESTful API requests and responses.

There's a huge difference between RESTful request/ response calls and Bitcoin node messaging

When making a REST call, you make a request and wait for either the response or a timeout

A synchronous call

Bitcoin messaging is more like Send-and-Don't-Wait

An Asynchronous call

So there isn't a direct correlation between a specific request and its response.

There are some messages which are paired, i.e. Version/ VerAck, Ping/ Pong.

Though every message is treated as a stream of outputting and inputting data.

You may send a Version message but don't wait for the VerAck response

You may send a Ping message but don't wait for the Pong response

You may never receive the corresponding VerAck or Pong message

In REST calls, a request is made by a client program to a server, requesting data.

The request may include what type of data is being requested

There is a header and parameters.

For GET requests the fields in the parameters are appended to the URL.

For POST requests the fields in the parameters are inside the body field

For Bitcoin messages, the Payload is similar to the Body of a POST call

The Bitcoin message header,

the Magic Number, Type, Length, Checksum,

are analogous to a REST Post header, though one which is of fixed length and fixed parameters.

REST headers can have custom fields.

In Bitcoin messaging, the header is purposefully rigid in its design

We cannot use the term Request for an outgoing Bitcoin message, as the node could be making either a Request to another node for data or sending a Response to another node from that nodes previous Request.

Using Write to and Read from the wire is not correct either

The functions could be doubled up.

So we'd have:

• SendRequest

• SendResponse

• ReadRequest

• ReadResponse

That is quite doable, as each node is connected either client=>server or server=>client

However that is only for the initial connection.

Sockets need a "server" to be listening on a port, and "clients" to connect to it

Bitcoin messaging goes both ways on that connection

You don't need both client=>server and server=>client to get two-way communication between nodes

If there's only the one connection between nodes, then it's not possible to know whether the next incoming message will be a response to one of our requests, or a request from that other node wanting our response to it.

This means dropping the Request/ Response terminology

This is when we pull out the thesaurus and attempt to find words which could be used in place of Request/Response for Bitcoin messaging

Using https://www.thesaurus.com/

The words must be verbs, not nouns.

Doing words, action words.

You're requesting

You're waiting for a response

You're responding

From this we could use words similar to

Write, Read, Send, Receive, Get, Post, etc

"Dispatch" seems a reasonable choice for sending data out on the wire.

Maybe "Push" and "Pop" data ?

We're definitely pushing data to the other node.

Not really popping data back from it though.

Transmit, broadcast ?

What's really happening is that a server Vends data

and a client Consumes that data.

In a peer node network,

the sender is Vending data

the receiver is Consuming that data

So

• Vend, Vending, Vendor, for writing/ sending

• Consume, Consuming, Consumer, for reading/ receiving

Each node in a peer network is both a Vendor and Consumer of data.