Software Defined Radio's Chapter

Will soon put contents here... watch out for this space.

A Revisit to MRPs (Multicast Routing Protocols)

In general, there are three types of routing mechanism in MANET. Proactive (table driven) protocols use a traditional, distributed, shortest-path and maintain routes at all times. They impose a high overhead. Reactive (on-demand) protocols are initiated by the source. They have lower traffc compared with proactive protocols, but impose delay in route determination. Hybrid protocols are an adaptive way of combining proactive and reactive protocols.

DVMRP (Distance Vector Multicasting Routing Protocol) builds a source-based tree. AODV (Ad-hoc On-Demand Distance Vector Routing Protocol) builds a corebased tree. CAMP (Core Assisted Mesh Protocol) builds a mesh interconnection of hosts.

Message Broker - It's just to FIRE

Need for a Information flow graph that works over epidemic message brokership on MH entities, which would result in dynamic group creation, subscription of receipients along the path on graph.

I just found good number of reads, namely,

• In message broker space. Known to only two JMS and CNS, excited to discover CEA (Cambridge Event Architecture), HERMES, SIENA, JEDI, ELVIN


• In tuple spaces, LINDA, LIME (2 very well known), IBM Tspaces, Java Spaces, L2imbo


• In Pervasive spaces, CALAIS, Gaia, Nexus, Solar and One.World

I believe in Power of CORBA, do you? I will make you believe in this.

The Nature of Real Time CORBA - complete coverage

Real time CORBA developers require to give strict attention to the allocation and to the predictability of execution entities. Real Time CORBA has scrapped of a few things from normal CORBA in order to support real time systems.RT CORBA does not currently address dynamic scheduling. Real time CORBA does not define IDL for an activity. Instead of worrying about delimiting an activity, it deals with invocations of IDL defined operations.

A traditional CORBA program flow is like: An operation invocation consists of a Request and a Reply. It is initiated by some client computational context (e.g. a thread) and passes through a client-role ORB, a transport protocol (TCP in the case of GIOP), a server-role ORB (possibly involving queuing) to a server application. Thereafter the operation passes through the same entities in reverse order, back to the client.

RT CORBA uses four components namely,

• Scheduling support from OS
• Real Time ORB
• Transport medium
• Application

to respect three criteria of end to end predictability namely,

• Respective thread priorities between client and server for resolving resource contention
• Bounding the duration of thread priority inversions during end-to-end processings
• bouding the latencies of operation invocations

Thread Priorities: Real-Time CORBA defines a universal, platform independent priority scheme called Real-Time CORBA Priority. It is introduced to overcome the heterogeneity of different Operating System provided priority schemes, and allows Real-Time CORBA applications to make prioritized CORBA invocations in a consistent fashion between nodes with different priority schemes. Real-Time CORBA defines a NativePriority type to represent the priority scheme that is ‘native’ to a particular Operating System. Priority values specified in terms of the Real-Time CORBA Priority scheme must be mapped into the native priority scheme of a given scheduler before they can be applied to the underlying schedulable entities. Real-Time CORBA defines a Real-Time CORBA Current interface to provide access to the CORBA priority of a thread.
A Real-Time operating system (RTOS) sufficient to use for implementing a Real-Time ORB compliant with this specification, will have some discrete representation of a thread priority.

Priority Models: Real-time CORBA defines two models at which a server handles a clients request:

• A model in which server respects priorities of inivocations set by clients. Server ORB maps this Real-time CORBA priority to Native OS priority. Requests coming from a non Real-time ORB are handled according to server priorities
• Server handles the inovocations according to the Real-time priorities set by the server side

Thread Pools: Thread pools provides, preallocation of threads (helps in reducing priority inversion), partitioning of threads, bounding of thread usage, buffering of additional requests.

Other cool features:

• Real-time CORBA provides clients to obtain a non multiplexed connection, which will not be shared with other client-server communications.
• Allows applications to set a timeout on the invocation in order the bound the time the client is blocked and waiting for the response.
• Server side thread configuration.
• Configuration of priority models set by clients or server. A new Real-time CORBA POA policy would be created on aboves.

and finally, RTORB interface defines operations to create, destroy other constituents of Real-time ORB. There is a single instance of RTCORBA::RTORB per instance of CORBA::ORB. The object reference for the RTORB is obtained by calling ORB::resolve_initial_references with the ObjectId “RTORB”.