Wednesday, May 31, 2006
Monday, May 15, 2006
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.
Friday, May 12, 2006
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
Tuesday, May 09, 2006
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
- 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
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.