kopia lustrzana https://github.com/meshtastic/protobufs
1.2 WIP
Kevin Hester
rodzic
527b0fdc34
commit
f23417aa7d
|
|
@ -303,9 +303,9 @@ emitting multiple records.
|
|||
<a name=".MeshPacket"></a>
|
||||
|
||||
### MeshPacket
|
||||
A full packet sent/received over the mesh
|
||||
Note: For simplicity reasons (and that we want to keep over the radio packets
|
||||
very small, we now assume that there is only _one_ SubPacket in each MeshPacket).
|
||||
A packet envelope sent/received over the mesh
|
||||
only payloadVariant is sent in the payload portion of the LORA packet.
|
||||
The other fields are either not sent at all, or sent in the special 16 byte LORA header.
|
||||
|
||||
|
||||
| Field | Type | Label | Description |
|
||||
|
|
@ -320,7 +320,7 @@ very small, we now assume that there is only _one_ SubPacket in each MeshPacket)
|
|||
| rx_snr | [float](#float) | | Never* sent over the radio links. Set during reception to indicate the SNR of this packet. Used to collect statistics on current link waulity. |
|
||||
| hop_limit | [uint32](#uint32) | | If unset treated as zero (no fowarding, send to adjacent nodes only) if 1, allow hopping through one node, etc... For our usecase real world topologies probably have a max of about 3. This field is normally placed into a few of bits in the header. |
|
||||
| want_ack | [bool](#bool) | | This packet is being sent as a reliable message, we would prefer it to arrive at the destination. We would like to receive a ack packet in response. Broadcasts messages treat this flag specially: Since acks for broadcasts would rapidly flood the channel, the normal ack behavior is suppressed. Instead, the original sender listens to see if at least one node is rebroadcasting this packet (because naive flooding algoritm). If it hears that the odds (given typical LoRa topologies) the odds are very high that every node should eventually receive the message. So FloodingRouter.cpp generates an implicit ack which is delivered to the original sender. If after some time we don't hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic. Note: This flag is normally sent in a flag bit in the header when sent over the wire |
|
||||
| priority | [MeshPacket.Priority](#MeshPacket.Priority) | | The priority of this message for sending. See MeshPacket.Priority description for more details. |
|
||||
| priority | [MeshPacket.Priority](#MeshPacket.Priority) | | The priority of this message for sending. See MeshPacket.Priority description for more details. This field is never sent over the radio links (to keep size small) |
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
72
mesh.proto
72
mesh.proto
|
|
@ -230,41 +230,12 @@ message Data {
|
|||
* packets small).
|
||||
*/
|
||||
fixed32 source = 5;
|
||||
|
||||
/*
|
||||
* If unset treated as zero (no fowarding, send to adjacent nodes only)
|
||||
* if 1, allow hopping through one node, etc...
|
||||
* For our usecase real world topologies probably have a max of about 3.
|
||||
* This field is normally placed into a few of bits in the header.
|
||||
*/
|
||||
uint32 hop_limit = 6;
|
||||
|
||||
/*
|
||||
* This packet is being sent as a reliable message, we would prefer it to arrive
|
||||
* at the destination. We would like to receive a ack packet in response.
|
||||
* Broadcasts messages treat this flag specially: Since acks for broadcasts would
|
||||
* rapidly flood the channel, the normal ack behavior is suppressed. Instead,
|
||||
* the original sender listens to see if at least one node is rebroadcasting this
|
||||
* packet (because naive flooding algoritm). If it hears that the odds (given
|
||||
* typical LoRa topologies) the odds are very high that every node should
|
||||
* eventually receive the message. So FloodingRouter.cpp generates an implicit
|
||||
* ack which is delivered to the original sender. If after some time we don't
|
||||
* hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic.
|
||||
* Note: This flag is normally sent in a flag bit in the header when sent over the wire
|
||||
*/
|
||||
bool want_ack = 7;
|
||||
|
||||
/* The priority of this message for sending.
|
||||
See MeshPacket.Priority description for more details.
|
||||
This field is never sent over the radio links (to keep size small)
|
||||
*/
|
||||
Priority priority = 8;
|
||||
}
|
||||
|
||||
/*
|
||||
* A packet envelope sent/received over the mesh
|
||||
* Note: For simplicity reasons (and that we want to keep over the radio packets
|
||||
* very small, we now assume that there is only _one_ SubPacket in each MeshPacket).
|
||||
* only payloadVariant is sent in the payload portion of the LORA packet.
|
||||
* The other fields are either not sent at all, or sent in the special 16 byte LORA header.
|
||||
*/
|
||||
message MeshPacket {
|
||||
|
||||
|
|
@ -321,7 +292,7 @@ message MeshPacket {
|
|||
* A particular node might know only a subset of channels in use on the mesh. Therefore channel_index
|
||||
* is inherently a local concept and meaningless to send between nodes.
|
||||
*/
|
||||
uint32 channel_index = 4;
|
||||
uint32 channel_index = 3;
|
||||
|
||||
/*
|
||||
* Internally to the mesh radios we will route SubPackets encrypted per
|
||||
|
|
@ -333,8 +304,8 @@ message MeshPacket {
|
|||
*/
|
||||
|
||||
oneof payloadVariant {
|
||||
Data decoded = 3;
|
||||
bytes encrypted = 8;
|
||||
Data decoded = 4;
|
||||
bytes encrypted = 5;
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
@ -356,13 +327,42 @@ message MeshPacket {
|
|||
* are typically not sent over the mesh, but they will be added to any Packet
|
||||
* (chain of SubPacket) sent to the phone (so the phone can know exact time of reception)
|
||||
*/
|
||||
fixed32 rx_time = 9;
|
||||
fixed32 rx_time = 7;
|
||||
|
||||
/*
|
||||
* *Never* sent over the radio links. Set during reception to indicate the SNR
|
||||
* of this packet. Used to collect statistics on current link waulity.
|
||||
*/
|
||||
float rx_snr = 7;
|
||||
float rx_snr = 8;
|
||||
|
||||
/*
|
||||
* If unset treated as zero (no fowarding, send to adjacent nodes only)
|
||||
* if 1, allow hopping through one node, etc...
|
||||
* For our usecase real world topologies probably have a max of about 3.
|
||||
* This field is normally placed into a few of bits in the header.
|
||||
*/
|
||||
uint32 hop_limit = 9;
|
||||
|
||||
/*
|
||||
* This packet is being sent as a reliable message, we would prefer it to arrive
|
||||
* at the destination. We would like to receive a ack packet in response.
|
||||
* Broadcasts messages treat this flag specially: Since acks for broadcasts would
|
||||
* rapidly flood the channel, the normal ack behavior is suppressed. Instead,
|
||||
* the original sender listens to see if at least one node is rebroadcasting this
|
||||
* packet (because naive flooding algoritm). If it hears that the odds (given
|
||||
* typical LoRa topologies) the odds are very high that every node should
|
||||
* eventually receive the message. So FloodingRouter.cpp generates an implicit
|
||||
* ack which is delivered to the original sender. If after some time we don't
|
||||
* hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic.
|
||||
* Note: This flag is normally sent in a flag bit in the header when sent over the wire
|
||||
*/
|
||||
bool want_ack = 10;
|
||||
|
||||
/* The priority of this message for sending.
|
||||
See MeshPacket.Priority description for more details.
|
||||
This field is never sent over the radio links (to keep size small)
|
||||
*/
|
||||
Priority priority = 11;
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue