Remote Procedure Calls Within SOS

1
Remote Procedure Calls Within SOS

• Simon Han and Roy Shea
• March 16, 2004

2
Sensor-network Operating System SOS

• Targets the dynamic needs of sensor networks
• Allows insertion of new modules onto deployed
  sensor nodes
• Modules on a node communicate through SOS core
  using messages
• Customization of applications can reduce sensor
  node load

3
Motivation for an RPC Mechanism

• Motes have limited memory and processing
  capabilities
• Expensive to transfer modules through sensor
  network

• Hardware and software heterogeneity should be
  exploited

4
Driving ApplicationVoronoi Polygonization

• Useful abstraction in sensor networks
• Requires heavyweight computation on floating
  point numbers
• Stresses limited mote processing power
• Easy to compute on more powerful nodes
• Good candidate for RPC

5
Message Passing in SOS

• Procedures post messages to the SOS core
• SOS core routes message to correct module
• Message carries state needed by module
• Message format facilitates a transition to RPC

6
Split Remote Procedure Call (S-RPC)

• Wireless sensor networks are event driven
• Computations are typically modeled as two
  function calls instead of one
• SOS uses FIFO non-preemptive scheduling
• Blocking procedure call is impossible
• Masking out failures in RPC itself is hard
• E.g. network failure, server mobility
• Transparent procedure call and return becomes
  unnecessary

7
Changing SOS to Support S-RPC

• Make message passing network capable
• Enhance SOS core to notify unserviceable messages
  over network
• Implement basic cache for RPC handlers
• Evaluate cache aging policies
• Write simple protocol to find RPC handlers in
  network
• Modified SOS message format

SOS Msg
TOS Msg
8
Life of S-RPC in SOS

• SOS core notes if message is addressed to an
  unknown module
• Core checks local cache for remote handler
• Enters resource location protocol if cache misses
• Core redirect message to remote destination for
  handling
• Remote destination handles RPC as normal message
  then reply result to source module

9
Sample S-RPC Session
Node N
Node M
Module Y
Module X
SOS Core
SOS Core

• Module X generate message for Module Y
• Core sees unregistered destination in message and
  checks RPC cache for Module Y
• Cache hit says Node N has Module Y
• Message redirected to Module Y on Node N
  
  
  
• Module Y handles message and returns it to Module
  X on Node M

RPC Cache
RPC Cache
10
Fault Handling in S-RPC
Node N
Node M
Module Y
Module X
e
d
SOS Core
SOS Core
f
d) Module Y not found, MSG_ERROR is sent back to
Module X. e) Cached RPC destination no long
valid. Resulted as another RPC. f) SOS Core
notifies source to invalidate the cache.
MSG_ERROR is then sent back to Module X.
RPC Cache
RPC Cache
11
Energy Trade Offs

• Blink is a small application run often (1 / sec)
• Blink RPC packets quickly outweigh cost of
  transferring module

• VISA is a very large module run rarely (1 / day)
• May take a long time for RPC packets to outweigh
  cost of transferring module

12
Future Work

• Improved cache maintenance
• Aging of cache entries
• Entry evocation policy
• Examine mechanisms to find RPC handlers within
  the sensor network
• Examine policies between code migration and S-RPC
• Fault tolerant mechanisms
• RPC timeouts
• Forcing module transfer if no handlers found

13
Conclusions

• RPC allows SOS to exploit network heterogeneity
• Offload difficult computations to more powerful
  nodes in tiered network
• Use diverse sensors on neighboring nodes
• Core design of SOS facilitated transition to RPC
• Individual applications need to evaluate energy
  trade offs of module transfers and RPC messages