Emstar Interfaces and Services

1
Emstar Interfaces and Services

• Nithya Ramanathan, UCLA

2
Emstar

• Keep asking yourselves these questions throughout
  the presentation
• Why should I learn Emstar? What can Em do for
  me?
• What are important features?

3
Outline

• Intro services
• Running Example
• Devices Servers Clients
• Packet Devices / Clients
• Link Devices / Clients
• Status Devices / Clients
• Command Devices / Clients
• Sensor Devices / Clients
• Timers
• Debugging
• Design Pitfalls

4
Interfaces/Services Make Life Easier

• Protocol Design (e.g. communication,
  time-synchronization, etc)
• Code Refactoring
• Certain needs and usage patterns have emerged
  over time, Em codifies these
• Debugging
• Enables modular design standardized code gt
  readable code
• Device files provide command-line visibility into
  running code

5
Running Example
Server

• Centralized server collects temperature
  information
• Various clients with different needs query the
  server

Client 1 Wants continuous readings
Client 3 Wants readings above 40C
Client 2 Wants average temp returned every 2
minutes
6
Services Required to Get Data

• What services are required to process the data
  and get it from the motes to the clients?

7
Services Required to Get Data

• What services are required to process the data
  and get it from the motes to the clients?
• Communication
• Routing
• ?
• ?
• Time Synchronization
• Data storage Query mechanisms

8
Services Required to Get Data

• What services are required to process the data
  and get it from the motes to the clients?
• Communication
• Routing
• Creating/maintaining neighbor lists
• Estimating link-qualities
• Time Synchronization
• Data storage Query mechanisms
• What is Blocking vs Polling vs Event Notification
  ?

9
Blocking
Client 1 Makes a request
Client 1 gets what they were requesting, and
leaves
Process calls a function in another
thread/process - Req process Client 1 -
Function call Clients request -
Thread containing func Person serving
req
Client 1 waits around while request is being
satisfied
Function-call returns to requesting process,
and that process continues execution
Requesting process is blocked while waiting for
function to return
10
Polling
Client 2 gets what they were requesting, and
leaves
Client 2 Makes a request
Client 2 periodically returns to see if request
is satisfied
During one status-check func call, the serving
process indicates it is done and the client
continues
Requesting process continues execution and
periodically calls a status-check function
to find out if request is satisfied
11
Events
Client 3 does something else, and leaves a phone
to be called when request is done.
Client 3 Makes a request
Client 3 returns upon receiving phone call
Requesting process continues execution and
specifies a Call-back function to be called by
serving process when the request is complete.
Clients call-back function is called, and the
client is given the data in this function.
12
Devices as Interfaces

• Work on event notification (though blocking
  functionality also provided by function calls
  ending in _s)
• Server-Client model
• Server exports a device(s)
• Client queries device for data and/or writes
  commands
• Services in Emstar provided through device-file
  interface
• Device implementation handles client and request
  queues
• Devices can be accessed by
• Command-line (either using cat or bin/echocat)
• Client libraries (all devices provide a client
  library for program access)

13
Status Device

• No message queueing
• Provides current status (binary / printable)
• Getting status
• Status-Device process exports a device file
• Status-Clients process opens this device file
• Status-Client reads from fd
• Status-Device process is informed of read and
  sends data (ascii / binary) to Status-Client
  through FUSD
• Status-Device notifies clients when new updates
  are available (i.e. fd is readable) gt goto
  Step 3
• Binary vs Printable call-backs
• Demo (command device, status device)
• obj.i686-linux/libdev/examples/simple_status

14
Status Devices

• Server
• Fill opts struct register device
• Open cb called if specified, used to track
  client-related state
• Write cb called if specified, command is
  processed
• Notify() client when data is ready
• Provide data in binary/printable

• Client
• Fill opts struct call open()
• (Optional) Write string to device
• Read device when notified

15
Packet Device

• Provides message queuing so clients do not lose
  information
• Useful for exchanging packets between modules
• Getting packets
• Packet-Device process exports a device file
• Packet-Clients process opens this device file
• Clients can add filters to specify packets they
  are interested in
• 3. Packet-Device process is informed of read
  and sends data (ascii / binary) to Packet-Client
  through FUSD
• .
• Printable gt un-parse
• Demo (Status gt Debug, Usage)
• obj.i686-linux/libdev/examples/simple_pd

16
Packet Devices

• Server
• Fill opts struct call New()
• Open cb called if specified, used to track
  client-related state
• Enqueue cb called if specified, command is
  processed
• Send cb called (MUST BE IMPLEMENTED) -gt calls
  pd_receive()
• Pd_receive sends data to clients
• Provide data in binary/printable (unparse cb if
  provided)

• Client
• Fill opts struct call open()
• Write packet to device
• Read device when notified

17
Link Devices

• Built on top of Packet-Device
• Link servers (or providers) fill out lp_opts_t
  struct and call lp_register()
• Link-Clients
• Use the link-server to send packets onto the link
  (setup by the link-server)
• Specify filter to only receive certain packet
  types
• Skeletons/samples/read_packets.c
• Devices automatically created by lp_register()
• /dev/nodeltidgt/link/ltlink-namegt/command
• /dev/nodeltidgt/link/ltlink-namegt/data
• /dev/nodeltidgt/link/ltlink-namegt/status

18
Link Devices

• Client
• Fill opts struct, set filter to specify types of
  packets to receive, call open()
• Call lu_send() to send a packet
• Receive cb (MUST BE SPECIFIED) is called with
  packets that match filter

• Server
• Fill opts struct call New()
• Open cb called if specified, used to track
  client-related state
• Filter cb (called by pd_enqueue) called if
  specified, packet is accepted/not accepted
• Send cb called (MUST BE IMPLEMENTED), sends data
  to clients
• Provide data in binary/printable (unparse cb if
  provided)

19
Running Example Continued

• Use neighbor service to build routing trees
• Emstar provides neighbors-app service
• Sends beacons to estimate link-quality
• Records neighbors and link-qualities
• Exports various status, packet, link-devices to
  export information
• Use sensor device to store/process data and
  record timestamps

20
Neighbors Demo

• Run in obj.i686-linux
• emrun/emsim ../link/examples/neighbors.sim 5
• Link Devices (command, status, data)
• gt /dev/sim/group2/node001/link/ls0 udp0
• Status Device
• Get current information
• e.g. cat /dev/sim/group2/node001/link/ls0/status
• Get neighbor lists
• e.g. cat /dev/sim/group2/node001/link/ls0/neighbor
  s
• Linkdump utility to get data
• bin/linkdump G ltSIM_GROUPgt N ltnode-idgt
  -r U udp0 OR ls0)
• Command Device
• Cat device to get commands gt
• e.g. cat /dev/sim/group2/node001/link/ls0/command
  
• Write commands to device using echo gt
• e.g. gt echo active0 gt /dev/sim/group2/node001/l
  ink/ls0/command
• What happens when we cat /dev/sim/group2/node001/
  link/ls0/data ?

21
Sensor Device

• Stores data in a ring-buffer
• Fixed Variable length samples
• Stores timestamps using timehist utility
• Integrated with timesync
• Isochronous Non-isochronous interface
• Provides easy access utilities using
  sensor-client interface
• E.g. aggregates, streams data

22
Sensor Device Demo

• Run in obj.i686-linux
• emrun/emrun ../libdev/examples/sdev_example_clien
  t.run
• Launches sensor-device server sample-client
• Automatically creates two devices
• /dev/sensors/ltsensor-device-namegt
• /dev/sensors/ltsensor-device-namegt_request_status
  Debugging
• Cat device to get usage
• e.g. cat /dev/sensors/ltsensor-device-namegt
• Samples accessed using start sample-number
  count
• E.g. get previous 10 samples
• bin/echocat w /dev/sensors/root_sdev
  relativestart-10count10
• E.g. stream samples starting from the first
  sample
• bin/echocat w /dev/sensors/root_sdev
  "start0"

23
Pitfalls Myths in Designing for WSN

• Myth 1 We want to minimize transmission at all
  costs
• Hard vs Soft state
• Soft-state is simple and recovers from
  errors/loss with additional overhead/latency
• Couple extra header bytes can contribute to
• better utilization of packets/data aggregation
• protocol more resilient to loss (i.e. providing
  application framing data w/ each packet)
• Myth 2 Sensing is free
• Sensors consume significant amounts of power and
  cannot be ignored when calculating energy budgets
• Pitfall 1 Ignoring topology changes
• Never assume a network will come up
  instantaneously!
• Always think about how node failures, partial
  failures, and new nodes joining a network will
  affect an algorithm or protocol. Not always
  something that we can tack on later
• Pitfall 2 Ignoring connectivity issues
• Dont send important information only once,
  always assume a packet will be dropped and design
  your algorithm accordingly
• Dont assume disc model
• Consider non-deterministic, spotty wireless
  connectivity
• Dont assume links are symmetric

24
Making Debugging Life Easier Using Emstar

• Debugging utilities (obj.i686-linux/bin)
• Echocat use to read/write status, packet or
  sensor-devices
• Linkdump use to get dump of link-devices
• Using device files for added visibility
• Status files like /dev/ls0/status or
  /dev/ls0/neighbors provides updated variable
  status
• Debugging simulations using gdb (DEMO)
• Run gdb
• Get PID for process
• cat /dev/fusd/status
• Attach to running process in gdb gt gdbgt attach
  ltPIDgt
• Set Breakpoints gt gdbgt b ltfunc_namegt
• TinyOS (see app.c for func-names)
• (gdb) b ltFileName-no-extensiongtltInterfacegtltFun
  c-Namegt
• Continue process gt gdbgt continue

25
Timers

gint g_timer_add (uint interval,
g_timer_handler_cb_t function, gpointer data,
g_event_opts_t opts, g_event_t
ref) libdev/include/glib_dev.h ---------------
--------------------------------------------------
------- int main() sde_ctx_t sde
g_timer_add(2000, sde_write, sde, NULL, NULL)
static int sde_write(void data, int intrv,
g_event_t event) sde_ctx_t sde
(sde_ctx_t ) data return EVENT_RENEW libde
v/include/sdev_example.c
26
Emstar

• Hopefully you can start to answer these
  questions
• Why should I learn Emstar? What can Em do for
  me?
• What are important features?

27
Conclusion

• THANK YOU
• Please do not hesitate to ask questions!!
• Nithya Ramanathan nithya at cs.ucla.edu