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.
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
You may send a
Ping message but don't wait for the
You may never receive the corresponding
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.
GET requests the fields in the parameters are appended to the URL.
POST requests the fields in the parameters are inside the body field
For Bitcoin messages, the Payload is similar to the Body of a
The Bitcoin message header,
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:
That is quite doable, as each node is connected either
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
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
This is when we pull out the thesaurus and attempt to find words which could be used in place of
Response for Bitcoin messaging
The words must be verbs, not nouns.
Doing words, action words.
You're waiting for a response
From this we could use words similar to
Dispatch" seems a reasonable choice for sending data out on the wire.
Push" and "
Pop" data ?
We're definitely pushing data to the other node.
Not really popping data back from it though.
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
Each node in a peer network is both a
Consumer of data.