Image Processing Reference
In-Depth Information
between sensor/actuator nodes. nORB therefore supports only basic data types, structures, and
sequences. his reduces the code base needed to support data types to those necessary for ping node
scheduling. We supported marshaling in nORB to allow application deployment over heterogeneous
networked embedded platforms, particularly for simulation environments. For other application
domains with homogeneous platforms, support for marshaling could be removed entirely. To sup-
port other data types, e.g., CORBA Any, the middleware simply has to incorporate the code to
marshal and demarshal those data types properly, trading of use of those types for an increase in
footprint.
2.4.2 Minimize Generality of the Messaging Protocol
Previous work [] has shown that optimizations can be achieved by the principle patterns of ()
relaxing system requirements and () avoiding unnecessary generality. Protocols in TAO like “GIOP-
Lite” [] are designed according to this principle. Similarly, as described in Section .., we support
a limited subset of the message types in the CORBA specification, so that we incur only the neces-
sary footprint, while still providing all features required by our target application. By reducing the
number of fields in the header, advanced features of a CORBA ORB such as Portable Interceptors are
not supported. Providing this support would trade off with an increase in both ORB footprint and
message sizes.
2.4.3 Simplify Object Life-Cycle Management
In a networked embedded system, the number of application objects hosted on each node is expected
to be very small, which reduces the need for full-fledged life-cycle management. Servant objects are
registered when the application starts, and live as long as the application, eliminating the need for
more complicated dynamic life-cycle management. he trade-off is that, for large numbers of objects
or where objects are dynamically created and destroyed, simplified object life-cycle management will
not suffice. For such end-systems, more complex adapters are necessary, albeit at a cost of larger
footprint.
2.4.4 Simplify Operation Lookup and Dispatch
When a remote operation request is received on a server, an ORB must search for the appropriate
object in its Object Adapter and then perform a lookup of the appropriate method in the operations
table. nORB uses linear search for that lookup because of the assumption that only a few methods on
only a few objects on each node will receive remote calls. he linear search strategy reduces memory
footprint while still maintaining real-time properties for small numbers of methods. he trade-off is
that for large numbers of methods, real-time performance will suffer. This is because linear search
will take O(
n
)timetodoalookup,where
n
isthenumberofoperations.Perfecthashingwilltake
O() time, but this alternative would again entail increased footprint due to the code generated to
support perfect hashing.
2.4.5 Pay Attention to Safety and Liveness Requirements
We described the different messaging and concurrency architecture choices in Section ... With
nested upcalls for remote method invocations, the “Wait on Connection” strategy could result in
deadlocks []. [].The “Wait on Reactor” strategy, on the other hand, avoids deadlocks but introduces
blocking factors which could hurt real-time performance [].
