RFC: Protocol Messages #1
Conversation
78c70cf to
ea9bcba
Compare
bdc8802 to
0fc78f2
Compare
| | 2 |Length| 2 | Length of message (65 KB max)| | ||
|
|
||
| #### Handshake | ||
| The handshake message is the first message which must be sent and received to/from a neighbor. It is used to construct the identity of the neighbor. If the advertised server socket port, coordinator address or mwm does not correspond to the receiving node’s configuration, the connection is dropped. It also sends its support for message types as a bitmap. Each index of the bitmap corresponds to a message type. If the bit on that index is turned on, then the corresponding message type is supported by the node. For example, `[01101110, 01010001]` denotes that this node supports message types 2, 3, 4, 6, 7, 9, 13 and 15. Thus, the length of the bitmap depends on the number of message types supported. The nodes can use that information to know what message types can be realyed to the peers. |
There was a problem hiding this comment.
The explanation of the supported versions is wrong. It's not about message types but versions.
There was a problem hiding this comment.
yeah I wanted to do a change earlier but it didn't catch
will fix
| |Order | Description | Length (bytes) | | ||
| | ---- | ------------- | ------------- | | ||
| | 1 | First solid milestone index | 4 (Big Endian)| | ||
| | 2 | Last solid milestone index | 4 (Big Endian) | |
There was a problem hiding this comment.
I think these are reversed ?
| | 2 |Length| 2 | Length of message (65 KB max)| | ||
|
|
||
| #### Handshake | ||
| The handshake message is the first message which must be sent and received to/from a neighbor. It is used to construct the identity of the neighbor. If the advertised server socket port, coordinator address or mwm does not correspond to the receiving node’s configuration, the connection is dropped. It also sends its support for message types as a bitmap. Each index of the bitmap corresponds to a message type. If the bit on that index is turned on, then the corresponding message type is supported by the node. For example, `[01101110, 01010001]` denotes that this node supports message types 2, 3, 4, 6, 7, 9, 13 and 15. Thus, the length of the bitmap depends on the number of message types supported. The nodes can use that information to know what message types can be realyed to the peers. |
There was a problem hiding this comment.
For example,
[01101110, 01010001]denotes that this node supports message types 2, 3, 4, 6, 7, 9, 13 and 15.
Doesn't this bit array has the indices 2,3,5,6,7,10,12,16 set?
There was a problem hiding this comment.
Nope, but it is not your fault for not understanding. My explanation wasn't clear.
Tell me if it is better now
| | 2 |Length| 2 | Length of message (65 KB max)| | ||
|
|
||
| #### Handshake | ||
| The handshake message is the first message which must be sent and received to/from a neighbor. It is used to construct the identity of the neighbor. If the advertised server socket port, coordinator address or mwm does not correspond to the receiving node’s configuration, the connection is dropped. It also sends its support for message types as a bitmap. Each index of the bitmap corresponds to a message type. If the bit on that index is turned on, then the corresponding message type is supported by the node. For example, `[01101110, 01010001]` denotes that this node supports message types 2, 3, 4, 6, 7, 9, 13 and 15. Thus, the length of the bitmap depends on the number of message types supported. The nodes can use that information to know what message types can be realyed to the peers. |
There was a problem hiding this comment.
yeah I wanted to do a change earlier but it didn't catch
will fix
| | 2 |Length| 2 | Length of message (65 KB max)| | ||
|
|
||
| #### Handshake | ||
| The handshake message is the first message which must be sent and received to/from a neighbor. It is used to construct the identity of the neighbor. If the advertised server socket port, coordinator address or mwm does not correspond to the receiving node’s configuration, the connection is dropped. It also sends its support for message types as a bitmap. Each index of the bitmap corresponds to a message type. If the bit on that index is turned on, then the corresponding message type is supported by the node. For example, `[01101110, 01010001]` denotes that this node supports message types 2, 3, 4, 6, 7, 9, 13 and 15. Thus, the length of the bitmap depends on the number of message types supported. The nodes can use that information to know what message types can be realyed to the peers. |
There was a problem hiding this comment.
Nope, but it is not your fault for not understanding. My explanation wasn't clear.
Tell me if it is better now
| |Order | Description | Length (bytes) | | ||
| | ---- | ------------- | ------------- | | ||
| | 1 | First solid milestone index | 4 (Big Endian)| | ||
| | 2 | Last solid milestone index | 4 (Big Endian) | |
| | 1 | Handshake | | ||
| | 2 | Legacy Tx Gossip | | ||
| | 3 | Milestone Request| | ||
| | 4 | Transaction Broadcast | |
There was a problem hiding this comment.
Saying "Broadcast" implies that this msg type is only used for broadcasting, however that's not true. During syncing while the node requests txs, nodes respond with this msg type (which has nothing to do with broadcasting). Remove the "Broadcast" part.
There was a problem hiding this comment.
ok, you don't want to call replies broadcasts
I agree it is confusing
| # Summary | ||
| Defines the changes that were introduced during the network rewrite. [iotaledger/iri#1072](https://github.com/iotaledger/iri/issues/1072). This is mainly the introduction of new TLV (type-length-value) messages. A header was added to each message, allowing us to create different message types and support different versiond of the protocol. A handshake message was also inroduced to help establish manageable connections with neighbors. | ||
|
|
||
| Will also define the STING protocol introduced by the Hornet team. It seperates between transaction requests and broadcasts, allows to request milestones by index, and introduces the concept of heartbeats. |
There was a problem hiding this comment.
Remove "Broadcast" in favor of saying something like: "It separates between transactions and transaction request, .."
| # Motivation | ||
|
|
||
| ***The network rewrite change*** | ||
| 1. Ability to kick-out a compromised/malfunctioning neighbor while preserving overall architecture performance. This means that a malfunctioning neighbor will only affect its own relationship with the node and will not affect how then node treats other neighbors |
There was a problem hiding this comment.
Missing dot at the end of the bullet point.
| 6. Enabling the addition of new message types and versioning the protocol. Thus paving the way for STING. | ||
|
|
||
|
|
||
| ***STING (Still TrInary Network Gossip)*** |
There was a problem hiding this comment.
Please just call it STING as it does not stand for "Still TrInary Network Gossip".
There was a problem hiding this comment.
Gotta find some acronym for it :-P
There was a problem hiding this comment.
STeady Interval Network Gossip? This would refer to the heartbeat message sent upon solidification of a new milestone or pruning.
There was a problem hiding this comment.
I like it
let see if @luca-moser likes it
|
|
||
| ## STING (Still TrInary Network Gossip) - Protocol Version 2 | ||
|
|
||
| STING is an extension to the IOTA protocol. It breaks the transaction gossip into Transaction Broadcast and Transaction Request. Besides that it adds the Milestone Request and Heartbeat messages. |
|
|
||
| #### Milestone Request | ||
|
|
||
| Requests a range of milestones by index. Expects to receive in response the milestone bundle for the specified index. |
There was a problem hiding this comment.
It requests a single milestone and not a range of milestones. Milestone being the complete bundle.
| | ----- | ----------- | --------------------- |---------------- | | ||
| | 1 | Milestone Index | uint32 (Big Endian) | 4 | | ||
|
|
||
| #### Transaction Broadcast |
|
|
||
| #### Transaction Broadcast | ||
|
|
||
| Broadcasts the transaction trytes with a 5 trits to a byte encoding. Doesn't expect any message in return. The size remains dynamic to due to signature message compaction. |
There was a problem hiding this comment.
"Broadcast" implies it is always sent to many recipients but this text should simply describe that this particular message type encapsulates a single transaction. That it is used in broadcasting new transactions shouldn't define this message type's name. In HORNET we simply call it "Transaction Message"
|
|
||
| #### Heartbeat | ||
|
|
||
| Relays the neighbor last and first solid milestone indexes. The first one depends on what the pruning. This is used to help a syncing node know what data their neighbor has. |
There was a problem hiding this comment.
This description is not correct. A heartbeat message contains the peer's indexes about the solid milestone and the milestone at which it pruned at. This allows a node to assess whether a given connected peer should have a transaction it needs to sync up.
It should also be noted in the RFC that the heartbeat message is sent every time the solid milestone is updated or pruning was done.
There was a problem hiding this comment.
I think it was but I made it clearer now I hope
Added the extra info
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
|
|
||
| #### Transaction | ||
|
|
||
| Broadcasts the transaction trytes with a 5 trits to a byte encoding. Does not expect any message in return. The size remains dynamic to due to signature message compaction. |
Co-authored-by: Thibault Martinez <thibault.martinez.30@gmail.com>
Co-authored-by: Thibault Martinez <thibault.martinez.30@gmail.com>
* ed25519-validation * add headers * Address review comments (#1) * Update 0000-ed25519-validation.md * Fix typos * rename file * Apply suggestions from code review Co-authored-by: charlesthompson3 <74603461+charlesthompson3@users.noreply.github.com> * Resolve open questions * Address review comments * add test vectors * calrify hash inputs * Use Unicode subscript small letter i * linebreak before equation * Fix review comments Co-authored-by: Wolfgang Welz <welzwo@gmail.com> Co-authored-by: charlesthompson3 <74603461+charlesthompson3@users.noreply.github.com>
Rendered: https://github.com/GalRogozinski/protocol-rfcs/blob/protocol-packets/text/0001-protocol-messages/0001-protocol-messages.md