Check-in [343acb481b]
Overview
Comment:Added start of documenting the network protocol
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 343acb481bfe943dd91e7e6a1776ea3bd486c391361255172b6f5335e5ade820
User & Date: rkeene on 2018-07-16 22:03:52
Other Links: manifest | tags
Context
2018-07-17
13:56
Cleaned up man page some check-in: d91ac639f4 user: rkeene tags: trunk
2018-07-16
22:03
Added start of documenting the network protocol check-in: 343acb481b user: rkeene tags: trunk
2018-07-12
21:18
Merged in start of network branch check-in: c07e032cc7 user: rkeene tags: trunk
Changes

Modified nano.man from [64858d5e00] to [db5ba6c98c].

333
334
335
336
337
338
339




























































































































340
341
342
343
344
345
346
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
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







+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+







would be encoded as
.B 0000.DC1512154EB72112B8CC230D7B8C7DD467DA78E4763182D6CAFAADB14855A5E8.9C46A37418
which when encoded in base32 and the prefix added produces the address
.BR nano_3q1o4acnxfs34cwerarfhg89uo59ubwgaxjjiddeoyofp767dbhamj5c8x1r .
The checksum is computed as a 5 byte (40 bit) Blake2b hash of the 256-bit
public key (in binary format), followed by reversing the bytes.

.SS Network
The Nano network consists of two different peer-to-peer networks.  One for
real-time block updates over UDP, and another for bulk ledger updates over
TCP
.RI ( bootstrapping ).
The real-time network is a broadcast style network where every message sent
over it are relayed to all other nodes.

The customary and default port for the real-time/UDP network is 7075/udp, while
the default port for the bootstrapping/TCP network is 7075/tcp.

The format of the messages on both networks is the same, however not every
type of message may be used on either network.  The
.B keepalive
message type is invalid on the TCP (bootstrapping) network and the
.B bulk_pull
message type is invalid on the UDP (real-time) network.  The format of
message are an 8 byte header consisting of:
.EX

   struct {
       uint8_t magicProtocol = 0x52;
       uint8_t magicNetwork  = 0x41/0x42/0x43;
       uint8_t versionMax;
       uint8_t version;
       uint8_t versionMin;
       uint8_t messageType;
       uint16_t extensions;
   };

.EE
Where the
.B magicProtocol
field must be the value
.B 0x52
(which is ASCII 'R') and the
.B magicNetwork
field must be one of
.BR 0x41 ", " 0x42 ", or " 0x43
corresponding to one of the three Nano networks.  A value of
.B 0x41
(ASCII 'A') represents the Test network;  A value of
.B 0x42
(ASCII 'B') represents the Beta network;  A value of
.B 0x43
(ASCII 'C') represents the Main network.

The various version fields control the relaying of the message to nodes running
various versions of the Nano network protocol (distinct from the Nano reference
implementation version).  The
.B versionMax
and
.B versionMin
fields indicate the inclusive range of acceptable versions to relay or broadcast
this message to.  The
.B version
field indicates what version of the Nano protocol this node is using.

The messageType field indicates what type of message is being relayed, and
must conform to the following enumeration
.TS
box tab(:);
cb cb cb cb
c l l l.
messageType:Name:On Bootstrap:On Realtime
0x00:Invalid:Yes:Yes
0x01:Not_A_Type:?:?
0x02:Keepalive:No:Yes
0x03:Publish:No:Yes
0x04:Confirm_Req:No:Yes
0x05:Confirm_Ack:No:Yes
0x06:Bulk_Pull:Yes:No
0x07:Bulk_Push:Yes:No
0x08:Frontier_Req:Yes:No
0x09:Bulk_Pull_Blocks:Yes:No
.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 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 network 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
TODOC

.TP
.B Bulk_Push
TODOC

.TP
.B Frontier_Req
TODOC

.TP
.B Bulk_Pull_Blocks
TODOC


.SH PROCEDURES
.SS Addresses
.TP
.B ::nano::address::toPublicKey
.I address