Discover like never before

Two main components of service discovery are:

1. Discovery Architecture, and,
2. Service matching mechanism.

Service discovery in pervasive computing environments requires a decentralized design approach where a node should not depend on some other node(s) to advertise/register services. Each service should be autonomous and be able to advertise its presence. Moreover, the discovery should also adapt itself to reflect the changes in the vicinity.

A good idea is to multiplex service broadcasting and ior transmission from server to new clients.

service request broadcast has three disadvantages:

• Broadcast scales poorly with increasing network diameter and network size.
• It utilizes resources and computation power on all nodes of the network including nodes that do not even have the service or nodes that may not even fall in thr route of the desired services.
• It ulilizes significant network bandwidth, and creates a large load on the network.

Synchronous Communication and Concerns

Synchronous communication is a most straighforward way of communication. It is easiest to understand and incarnate. Most of the basic programs are based on it, from RPC to TP and Object Monitors.
But it has a few overheads which literally kills its advantages specially in certain distributed and enterprise communication models.

• It requires both parties to be online, it requires both parties to under go connection overhead.
• It requires both parties to maintain session of communication.
• To maintain session, both parties have to consume CPU resources for whole of 'live' time.
• Fault detection gets difficult as it is difficult to detect where the fault occured, is it at A, between A and B request communication, at B, or between B and A response communication.
• Fault Tolerance can be achieved by incarnating multiple service entities, but it requires to maintain their sessions also, it also requires have pools of them, and all this assuming it is stateless. If the service is statefull it gets more difficult.
• As seen from Fault Tolerance and session points, it is not a scalable approach.

Service Discovery and Broadcast

Two main components of service discovery are:Discovery Architecture and Service matching mechanism.

Service request broadcast has three disadvantages:

• Broadcast scales poorly with increasing network diameter and network size.
• It utilizes resources and computation power on all nodes of the network including nodes that do not even have the service or nodes that may not even fall in the route of the desired services.
• It ulilizes significant network bandwidth, and creates a large load on the network.

Clearly, service discovery in pervasive computing environments requires a decentralized design approach where a node should not depend on some other node(s) to advertise/register services. Each service should be autonomous and be able to advertise its presence. Moreover, the discovery should also adapt itself to reflect the changes in the vicinity.

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”.

Data dissemination completed

It's been like the worst times, digesting them all and not finalizing them, I should make this moment, a moment to compose all in one.

There should be a ThreshValue on mobile nodes, configurable to the signal strength(interested in backchannel bandwidth), for controlling the push or pull behavior.

Push mode is bandwidth preserving in any environment, whether it's wired/wireless, I only difference is that it matters the most in wireless. But, at the end of day it depends on what's at application layer.

Let's try to classify this,

• 1. Parameterised service mode, (prime communication mode i.e. unicast pull)


• 2. Subscription mode, (service data broadcasts i.e. multicast push, if any by service to subscribers, broadcast items with highest count on Longest Wait First.)


• 3. Regular housekeeping communications, (handoff communication)


• 4. Parameterised housekeeping data transfer (code mobility, execution state transfer)


• 5. Parameterised service mode with multicast pull (aggregation of same request over a time span, hard to realize usability in practical cases, depends on usability, it's a intermediate stage between switching from 1 to 2)

I assume above all would be the communication modes, which all are required to be supported by the framework. Push characteristics of Message brokers can be used very effectively in 2 and 3. Ofcourse, In all cases, Message brokers would be used for data stroage for data availability.

An extremly good approach I feel is to broadcase hash-index of to-be multicast push items to subscribers to defer their unicast pull.

A important point to note here is, Heat adversely effects the reliability of the digital circuits and increases costs for cooling especially in servers. In order to access the desired data, a client has to be in active mode, waiting for the data to appear on the multicast. Enabling reliable communication on the message broker could be helpful in the sense of truly providing the intermittent devices asynchronous access to data. An broadcast indexing would make things even much better. The only low point is that in MANET, we don't have any super devices, all are peers, hence to save clients heat and effectively utilize Back Chaneel bandwidth, we require memory at the serving peer (so called server in Client Server environment).

About sensors workage

I came across a very interesting fact about working and robustness of currently deployed sensors, it is,

For a sensor network to maintain a lifetime of several years, for example, the radio’s duty cycle—the ratio of time the radio is on over time that the radio is actively sending or receiving a message—must typically be less than 1 percent.

Providing Push or Pull in MANET

Asymmetry happens in MANET not only due to communication behavior, but also due to

• Ratio of clients and servers


• Difference in downlink bandwidth and uplink ones


• Data Volume


• Hot data items

Push has a obvious advantage in MANET, as it

• takes same bandwidth for any subscribers


• Conserves energy by eliminating energy consuming uplink transmission, yields only if needy items are pushed


• Backchannel is missing or having poor bandwidth

Pull is also needed in MANET, as it

• is required for custom query or in on-demand mode


• much prefered mode when authorization is required.

A very interesting fact in regard to hot data items data dissemination is,
If p1,p2....,pn are the popularity ratios of data item, then their broadcast frequencies are f1,f2,...,fn, where fk = sqrt(pk)/sum of (sqrt(pks)) (By a paper of Imielinski et al)

Obviously, it is very favoring result for the push mode if we can sort hot data items at the cost of average access latencies of data items.

Flying car ready for takeoff?

This summer, graduate students at the Massachusetts Institute of Technology will try to get an idea aloft that has intrigued people for decades: the flying car.

Terrafugia, a start-up created by Lemelson-MIT Student Prize winner Carl Dietrich and colleagues at MIT's Department of Aeronautics and Astronautics, is aiming to show off what it calls the Transition "personal air vehicle," an SUV with retractable wings, to the EAA AirVenture Conference in Oshkosh, Wis., at the end of July.

The Transition is designed for 100- to 500-mile jumps. It will carry two people and luggage on a single tank of premium unleaded gas. It will also come with an electric calculator (to help fine-tune weight distribution), airbags, aerodynamic bumpers and of course a GPS (Global Positioning System) navigation unit.

Full report can be found at here

Message Oriented Middleware Communication Modes

The factors I depicted out for communication between peers are:
{Synchronous, Asynchronous, Transient, Persistent, Ack time)
in turn acknowledge enumeration can be made from ACK ENUM {Immediate, before response, response based, any}

We can make different combination of them,

• Persistent Asynchronous


• Persistent Synchronous


• Transient Asynchronous


• Transient Synchronous


• Recipient based Transient Synchronous


• Delivery based Transient Synchronous


• Response based Transient Synchronous

Persistent storage in pervasive environment can be defined as a storage on a mobile entity or set of mobile entities, such that demise of MH(s) should not result in loss of message.

Such that for any two entites, we need to define Sync/Async at A, Sync/Async at B, Persistence at A/Middleware/B, Message Acknowledgement ACK ENUM.

Phew! Mustang is out

Phew!
Mustang is out. To check out 10 hot things in mustang, go to Danny's weblog's entry
The 10 Things You Need to Know About Java SE 6 'Mustang'

Amazing/Amusing Stuff people do in Asynchrous Middlewares

Well, to avoid setup, search and registration confirmation latency while listening to a pub/sub in a new region. Virtual clients can queue up previous notifications and upon entities arrival they can dump the queued messages to newly arrived entity.

Good Points

• In case pub/sub JMS is not centralized then you can automatically discover other peers in the region. This would work in a centralized case also. But mobile framework I have supports peer MH (Mobile Host) discovery, hence first good point is not so good.
• A very good take can be in case queued notifications contains intermediate hop listings, then MH can update channel entires in routing tables with listed ones. It is a very good point I should say.

Bad Point

• Security is a concern, if entities are required to get only authenticated notifications only then things w'nt work it out as what newly arrived entity would be receiving are notification targeted to other entities.

Service Availability Estimation vs Service Discovery

I never got belief in this that computing time to be devoted in service
availability estimation rather than service discovery. A fact tells latency/overhead in 10 bytes of network communication is equal to 100000 CPU cycles. Huhh!!! Big figures, but look at the overhead involved in all this estimation if your prediction goes false, after all algorithms (Linear scaling or Bin) works on past records of service availability or service demise.

A good concept to take from service availability estimation is a fuzzy logic crieteria to compute device availability scale.

Mobile Service Buses

Mobile devices can work as service buses by consuming and transfering data collected from fixed/mobile sensors deployed in the region. Taking this as a PRD, the essential features required would be support for Asynchronous Communication, Support for Service Discovery, Need to differentiate between Service and Device discovery. The framework adds device discovery, but I am not very sure about whether the framework supports the Service Discovery. Let me think........

Well! after an intensive thought on the framework, service discovery is supported, but the service query APIs are not formulated, may be other service dimensions might also be in unstructured format, but yeah scalability is there and framework can have all the functionalities, I am very sure about this.

About asynchronous communication, a customize self organizing pub/sub service can help me to post up the functionality. But I need to investigate on that.

Facilitating Asynchronous Middleware

Facilitates:

• Servant Client Communication
• Route request and response message flows
• Mobility Layer handoff notifications (Device discovery)
• Surrogate Disconnection operation
• Service Discovery

Questions:

• Pub/Sub or Queue Hosting
• Discovery of Message Middleware

Answers:

• Vertical Message Queues
• Vertical Discovery Platform