In case of an error, the tx sync packet snip could previously have been
released twice. This moves re-attaching the tx sync snip down after the
last `goto error` to avoid this.
The new `gnrc_tx_sync` module allows users of the GNRC network stack to
synchronize with the actual transmission of outgoing packets. This is directly
integrated into gnrc_sock. Hence, if `gnrc_tx_sync` is used, calls to e.g.
sock_udp_send() will block until the network stack has processed the message.
Use cases:
1. Prevent packet drop when sending at high rate
- If the application is sending faster than the stack can handle, the
message queues will overflow and outgoing packets are lost
2. Passing auxiliary data about the transmission back the stack
- When e.g. the number of required retransmissions, the transmission time
stamp, etc. should be made available to a user of an UDP sock, a
synchronization mechanism is needed
3. Simpler error reporting without footguns
- The current approach of using `core/msg` for passing up error messages is
difficult to use if other message come in. Currently, gnrc_sock is
busy-waiting and fetching messages from the message queue until the number
of expected status reports is received. It will enqueue all
non-status-report messages again at the end of the queue. This has
multiple issues:
- Busy waiting is especially in lower power scenarios with time slotted
MAC protocols harmful, as the CPU will remain active and consume
power even though the it could sleep until the TX slot is reached
- The status reports from the network stack are send to the user thread
blocking. If the message queue of the user thread is full, the network
stack would block until the user stack can fetch the messages. If
another higher priority thread would start sending a message, it
would busy wait for its status reports to completely come in. Hence,
the first thread doesn't get CPU time to fetch messages and unblock
the network stack. As a result, the system would lock up completely.
- Just adding the error/status code to the gnrc_tx_sync_t would preallocate
and reserve memory for the error reporting. That way gnrc_sock does not
need to search through the message queue for status reports and the
network stack does not need to block for the user thread fetching it.
When a VRB entry exists use minfwd to forward.
When a route exist for the first fragment received in reassembly create
a virtual reassembly buffer entry.
This changes the prefixes of the symbols generated from USEMODULE and
USEPKG variables. The changes are as follow:
KCONFIG_MODULE_ => KCONFIG_USEMODULE_
KCONFIG_PKG_ => KCONFIG_USEPKG_
MODULE_ => USEMODULE_
PKG_ => USEPKG_
Replace direct accesses to sched_active_thread and sched_active_pid with
the helper functions thread_getpid() and thread_get_active(). This serves
two purposes:
1. It makes accidental writes to those variable from outside core less likely.
2. Casting off the volatile qualifier is now well contained to those two
functions
Having the definitions sit in the `net/gnrc/sixlowpan/frag.h` header
does not make much sense, when using Selective Fragment Forwarding
(and the fragmentation buffer already includes a
`net/gnrc/sixlowpan/frag/stats.h` header), so they are moved to their
own header. Since with this change it makes more sense to have the
statistics stored in their own sub-module, the pseudo-module is also
actualized.
This fits with the semantics of this function which doesn't provide or
uses any state of the reassembly buffer provided by the user, but finds
the entry itself and then removes it. This gives the user no chance to
remove the packet in the reassembly buffer entry, so
`gnrc_sixlowpan_frag_rb_rm_by_datagram()` has to release the packet
(other than `gnrc_sixlowpan_frag_rb_remove()` where not releasing the
packet is desired as it might be handed up to an upper layer).
This allows to set a timer between the completion of a datagram in the
reassembly buffer and the deletion of the corresponding reassembly
buffer entry. This allows to ignore potentially late incoming link-layer
duplicates of fragments of the datagram that then will have the
reassembly buffer entry be blocked.
This was noted in this [discussion] for classic 6LoWPAN reassembly (and
minimal fragment forwarding) and is recommended in the current
[selective fragment recovery draft][SFR draft].
[discussion]: https://mailarchive.ietf.org/arch/msg/6lo/Ez0tzZDqawVn6AFhYzAFWUOtJns
[SFR draft]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-07#section-6
The name `fragment_msg` or `frag_msg`/`msg_frag` always to me was a bit
misplaced, as it basically implements an asynchronous fragmentation
buffer and doesn't necessarily have anything to do with messages.
This change
1. changes the name to `fb` (for fragmentation buffer)
2. factors its code out to its own sub-module so it can be re-used by
other 6LoWPAN fragmentation schemes like [Selective Fragment
Recovery]
[Selective Fragment Recovery]: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05
