Skip to content

30002_udp.md

Latest commit

 

History

History
148 lines (94 loc) · 4.8 KB

30002_udp.md

File metadata and controls

148 lines (94 loc) · 4.8 KB
driver number 196610

UDP

Overview

The UDP driver allows a process to send and receive UDP packets using the Tock networking stack. Currently, this driver allows for tx and rx of UDP packets via 6LoWPAN, which sits on top of the 802.15.4 radio.

This driver can be found in capsules/src/net/udp/driver.rs driver.rs implements an interface for sending and receiving UDP messages. It also exposes a list of interace addresses to the application layer. The primary functionality embedded in the UDP driver is within the allow(), subscribe(), and command() calls which can be made to the driver.

Allow

  • Description allow() is used to setup buffers to read/write from. This function takes in an allow_num and a slice. These allow_nums determine which buffer is being setup as follows:

  • Allow Number: 0

    Description: Read Buffer.

    Argument 1: Slice into which the received payload should be stored

    Returns: SUCCESS

  • Allow Number: 1

    Description: Write Buffer.

    Argument 1: Slice containing the UDP payload to be transmitted

    Returns: SUCCESS

  • Allow Number: 2

    Description: Tx Config Buffer.

    Argument 1: Slice containing config information, namely source/destination addresses and ports. Specifically, the config buffer should be the size of two sock_addr_t structs. The first half of the buffer should contain the source address/port (represented as a sock_addr_t) from which the application expects to send. The second half of the buffer should contain the destination address/port which the application wishes to send the next packet to.

    Returns: SUCCESS

  • Allow Number: 3

    Description: RX Config Buffer.

    Argument 1: Slice containing the Rx config buffer. Used to contain source/destination addresses and ports for receives (separate from 2 because receives may be waiting for an incoming packet asynchronously). Specifically, the rx config buffer should be the size of two sock_addr_t structs. The first half of the buffer should contain the address/port (represented as a sock_addr_t) on which the application is listening. The second half of the buffer should contain the incoming source address/port which the application wishes to listen for.

    Returns: SUCCESS

Subscribe

  • Description: subscribe() is used to setup callbacks for when frames are transmitted or received. It takes in a callback and a subscribe number. The subscribe number indicates the callback type:

  • Subscribe Number: 0

    Description: Setup callback for when frame is received.

    Argument 1: The callback

    Argument 2: AppId

    Returns: SUCCESS

  • Subscribe Number: 1

    Description: Setup callback for when frame is transmitted.

    Argument 1: The callback

    Argument 2: AppId

    Returns: SUCCESS

Command

  • Description: command() is used to get the interface list or to transmit a payload. The action taken by the driver is determined by the passed command_num:

  • Command Number: 0

    Description: Driver check.

    Argument 1: Unused

    Argument 2: Unused

    Argument 3: Unused

    Returns: SUCCESS (TODO: return ENODEVICE if driver doesn't exist)

  • Command Number: 1

    Description: Get the interface list

    Argument 1: Number of requested interface addresses

    Argument 2: Unused

    Argument 3: AppId

    Returns: SuccessWithValue, where value is the total number of interfaces

  • Command Number: 2

    Description: Transmit Payload

    Argument 1: Unused

    Argument 2: Unused

    Argument 3: AppId

    Returns: EBUSY is this process already has a pending tx. Returns EINVAL if no valid buffer has been loaded into the write buffer, or if the config buffer is the wrong length, or if the destination and source oirt/address pairs cannot be parsed. Otherwise, returns the result of do_next_tx_sync(). Notably, a successful transmit can produce two different success values. If success is returned, this simply means that the packet was queued. However, if SuccessWithValue is returned with value 1, this means the the packet was successfully passed the radio without any errors, which tells the userland application that it can immediately queue another packet without having to wait for a callback.