-
Notifications
You must be signed in to change notification settings - Fork 0
minutes network stack task force april 2015
| Names | |
|---|---|
| Local participants | |
| Remote participants | |
| Minute taker | tbd |
- FIB and Reactive Routing Protocols
- Application Layer Protocols
- Socket API
- Header Passing
- Multicast/Broadcast Link-Layer Address Resolution
- Link-Layer Address Length
Though we had kind of a solution in the last NSTF meeting we came to the conclusion that this would not up-hold for nodes with multiple reactive routing protocols.
Pure POSIX vs. adaption layer: With the netapi as layer between transport layer protocols and the application (layer) it seems weird why we would need our own socket layer between the POSIX sockets and our own. Why not take the more effective way and use POSIX sockets by default if one wants to use sockets (as far as porting of libs and apps goes you need to use POSIX sockets anyways)?
- microcoap does not provide an API for generating CoAP requests, what's the best way to implement and integrate such an API?
Disclaimer: his is a detail discussion, the outcome might be integrated in later versions of the network stack
- Oleg raised the question in #2575 whether passing of lower layer headers down the stack is really a good idea?
- Oleg also had concerns about our approach to checksum calculation with pseudo headers, also due to blurring of layer borders.
- The solution Martine came to in #2600 seems somewhat elegant and effective, but maybe someone has an even better idea
(vs. sl2ao/tl2ao length): When parsing the Source/Target link-layer address option Martine ran into the problem that one does not necessarily know the length of the link-layer address here because it is derived from the option's length which is given in units of 8 byte, and not byte.
RIOT - The friendly Operating System for the Internet of Things
Homepage | [GitHub] (https://github.com/RIOT-OS/) | Developers Mailing List | Users Mailing List | Twitter @RIOT_OS
- Family: ARM
- Board: Airfy Beacon
- Board: Arduino Due
- Board: CC2538DK
- Board: HikoB Fox
- Board: IoT LAB M3
- Board: LimiFrog-v1
- Board: mbed_lpc1768
- Board: MSB-IoT
- Board: MSBA2
- Board: Nucleo-L1
- Board: Nucleo-F334
- Board: Nucleo-F303
- Board: Nucleo-F091
- Board: Mulle
- Board: OpenMote
- Board: PCA1000x (nRF51822 Development Kit)
- Board: Phytec phyWAVE-KW22
- Board: RFduino
- Board: Samr21 xpro
- Board: Spark Core
- Board: STM32F0discovery
- Board: STM32F3discovery
- Board: STM32F4discovery
- Board: UDOO
- Board: yunjia-nrf51822
- Family: ATmega
- Board: Arduino Mega2560
- Family: MSP430
- Board: MSB-430H
- Board: TelosB
- Board: WSN430
- Board: Zolertia Z1
- Board: eZ430-Chronos
- Family: native
- Board: native
- Family: x86
- Board: Intel Galileo