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 => 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 = Client’s 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. Client’s 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) … => goto Step 3 • Binary vs Printable call-backs • Demo (command device, status device) – obj.i686-linux/libdev/examples/simple_status

14. 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 Status Devices

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 => un-parse • Demo (Status => Debug, Usage) – obj.i686-linux/libdev/examples/simple_pd

16. 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) -> 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 Packet Devices

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/node<id>/link/<link-name>/command • /dev/node<id>/link/<link-name>/data • /dev/node<id>/link/<link-name>/status

18. 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) 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 Link Devices

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): => /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/neighbors • Linkdump utility to get data bin/linkdump –G <$SIM_GROUP> –N <node-id> -r –U udp0 OR ls0) • Command Device • Cat device to get commands => e.g. cat /dev/sim/group2/node001/link/ls0/command • Write commands to device using echo => e.g. > echo “active=0” > /dev/sim/group2/node001/link/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_client.run Launches sensor-device server & sample-client • Automatically creates two devices: • /dev/sensors/<sensor-device-name> • /dev/sensors/<sensor-device-name>_request_status – Debugging • Cat device to get usage e.g. cat /dev/sensors/<sensor-device-name> • Samples accessed using start sample-number & count • E.g. get previous 10 samples bin/echocat –w /dev/sensors/root_sdev “relative:start=-10:count=10“ • E.g. stream samples starting from the first sample: bin/echocat –w /dev/sensors/root_sdev "start=0"

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 • Don’t send important information only once, always assume a packet will be dropped and design your algorithm accordingly • Don’t assume disc model • Consider non-deterministic, spotty wireless connectivity • Don’t assume links are symmetric • Don’t bother with bad links, rarely helps in the long run

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 => gdb> attach <PID> • Set Breakpoints => gdb> b <func_name> • TinyOS (see app.c for func-names): (gdb) b ‘<FileName-no-extension>$<Interface>$<Func-Name>’ • Continue process => gdb> 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; } libdev/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