Check-in [a80c9e0cd7]
Overview
Comment:Added more documentation
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: a80c9e0cd72933cdc903e5fce8ec96d43d38edde770bfaf77f036a895bf0d92d
User & Date: rkeene on 2018-12-08 03:06:06
Other Links: manifest | tags
Context
2018-12-08
03:36
Added start of documentation on Bulk_Pull_Account check-in: 15de2d5606 user: rkeene tags: trunk
03:06
Added more documentation check-in: a80c9e0cd7 user: rkeene tags: trunk
02:33
Added node script check-in: 9d3190fba9 user: rkeene tags: trunk
Changes

Modified nano.man from [59acc08d34] to [4521f209c2].

404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424

425


426






427
428
429
430
431
432
433
434
435
436
437
438
439


440
441
442
443
444
445
446
447
448
449





450
451
452
453






454
455
456
457















458
459
460
461
462
463
464
The messageType field indicates what type of message is being relayed, and
must conform to the following enumeration
.TS
allbox tab(:);
cb cb cb cb cb
c l l l c.
messageType:Name:On Bootstrap:On Realtime:Version
0x00:Invalid:Yes:Yes:0+
0x01:Not_A_Type:?:?:0+
0x02:Keepalive:No:Yes:0+
0x03:Publish:No:Yes:0+
0x04:Confirm_Req:No:Yes:0+
0x05:Confirm_Ack:No:Yes:0+
0x06:Bulk_Pull:Yes:No:?
0x07:Bulk_Push:Yes:No:?
0x08:Frontier_Req:Yes:No:?
0x09:Bulk_Pull_Blocks:Yes:No:11+
0x0A:Node_ID_Handshake:Yes:No:12+
0x0B:Bulk_Pull_Account:Yes:No:12+
.TE


.B "TODO: Extensions"









Following the message header comes the payload for the particular message
type.

.TP
.B Invalid
TODOC

.TP
.B Not_A_Type
TODOC

.TP
.B Keepalive


The Keepalive message serves as an introduction and beaconing mechanism for
the Nano real-time network.
The Keepalive message requires exactly 8 IPv6 address and port number
tuples to be sent as its payload.  The IPv6 addresses are each 128-bits
(16-bytes) long and the port numbers are 16-bit integers sent in little endian
byte order.  The payload for the Keepalive message type is 144 bytes in size.

.TP
.B Publish
TODOC






.TP
.B Confirm_Req
TODOC







.TP
.B Confirm_Ack
TODOC
















.TP
.B Bulk_Pull
The Bulk_Pull message is used to pull the entire chain for an account, down to
its beginning or to a given block.  It takes 2 arguments, both of them 256-bit.
The first argument is the account, so its 256-bit public key should be encoded
as binary in big-endian notation.  The second argument is the block hash to







|
|
|
|
|
|
|
|
|
|




>
|
>
>

>
>
>
>
>
>













>
>
|








|
>
>
>
>
>



|
>
>
>
>
>
>



|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
The messageType field indicates what type of message is being relayed, and
must conform to the following enumeration
.TS
allbox tab(:);
cb cb cb cb cb
c l l l c.
messageType:Name:On Bootstrap:On Realtime:Version
0x00:Invalid:Yes:Yes:1+
0x01:Not_A_Type:Yes:Yes:1+
0x02:Keepalive:No:Yes:1+
0x03:Publish:No:Yes:1+
0x04:Confirm_Req:No:Yes:1+
0x05:Confirm_Ack:No:Yes:1+
0x06:Bulk_Pull:Yes:No:1+
0x07:Bulk_Push:Yes:No:1+
0x08:Frontier_Req:Yes:No:1+
0x09:Bulk_Pull_Blocks:Yes:No:Deprecated
0x0A:Node_ID_Handshake:Yes:No:12+
0x0B:Bulk_Pull_Account:Yes:No:12+
.TE

.TP
.B Extensions
The following message types have extension bits used as flags:
.IR Node_ID_Handshake ", " Bulk_Pull .

The following message types encode a block type in the extension bits:
.IR Publish ", " Confirm_Req ", and " Confirm_Ack .
The block type is encoded in the lower 4 bits of the first byte of the
extensions field (i.e., (extensions & 0x0f00 >> 8)).

.SS Payload
Following the message header comes the payload for the particular message
type.

.TP
.B Invalid
TODOC

.TP
.B Not_A_Type
TODOC

.TP
.B Keepalive
The
.I Keepalive
message serves as an introduction and beaconing mechanism for
the Nano real-time network.
The Keepalive message requires exactly 8 IPv6 address and port number
tuples to be sent as its payload.  The IPv6 addresses are each 128-bits
(16-bytes) long and the port numbers are 16-bit integers sent in little endian
byte order.  The payload for the Keepalive message type is 144 bytes in size.

.TP
.B Publish
The
.I Publish
message serves as a mechanism to introduce new blocks into the
Nano real-time network.  The block type is encoded in the
.I Extensions
field as described above.  The payload is the contents of the block.

.TP
.B Confirm_Req
The
.I Confirm_Req
message requests that all online representatives "vote" on a block.
The block type is encoded in the
.I Extensions
field as described above.  The payload is the contents of the block
to be voted on.

.TP
.B Confirm_Ack
The
.I Confirm_Ack
message is sent in response to either a new block being observed
by a representative or in response to an explicit
.IR Confirm_Req .
The block type is encoded in the
.I Extensions
field as described above.
If the block type is specified as
.I Not_A_Block
then the payload is a sequence of hashes.  Due to IPv4 fragment
size limits this typically does not exceed 12 hashes.  If the
block type is something other than
.I Not_A_Block
then the payload is the contents of the block that is being
voted on.

.TP
.B Bulk_Pull
The Bulk_Pull message is used to pull the entire chain for an account, down to
its beginning or to a given block.  It takes 2 arguments, both of them 256-bit.
The first argument is the account, so its 256-bit public key should be encoded
as binary in big-endian notation.  The second argument is the block hash to