Round Trip Time from source 1-6 to destinations Using this notation, we define the nearest Peer as: NP = { Bk | max (Bi) , 0<i<N } In this way, the Peer with maximum available bandwidth from source is our NP. 

Context in source publication

Context 1

... either the memory needs to be virtualized or the entire address space needs to be moved along with the thread. There are still many unresolved research issues related to implementing Grid wide shared memory, as has been explored by [22], thus our system will be a non-shared memory system. When we talk about Grid-enabling interactive applications, we must also consider the Grid-enabling of the interaction between the threads of execution in a process. In the existing Grid infrastructure, inter- process communication across the Grid is non-existent, since applications are tailored to be batch-oriented, and execute independently. Communication between threads of the same process usually entails a procedure call, along with some means of identifying the particular thread with which to communicate. To Grid- enable such applications, the operating system should be able to intercept the communication, to determine the destination and to pass on the procedure call to the appropriate node for it to be executed there. We plan to do this by having a service in the operating system that monitors all procedure calls by a thread scheduled to it. It would be able to determine whether the procedure called is a member of a remote thread. The information of which thread is scheduled to which node would be available to the operating system. Once the destination of a particular call is determined, the call could be forwarded to the concerned node to be executed there. Any data associated with the call must also be transferred to the other system. One issue in this approach is that of network latency in Grid environments. This approach requires significant amounts of data transfer. Although current network speed is much less then processor-memory speed, advances in networking technologies will eventually reduce the communication latencies involved. Another issue is that the Thread IDs must be unique across space and time i.e. they must be unique within the context of the whole Grid. The challenge for Grid-enabling desktop file systems in our project will be to unify all shared storage devices, into a single logical namespace and to provide a universal view to each participating Peer. Security is one essential concern for us. There are many Grid-specific file system technologies [23] and [24] and others, most of which have been designed to be used in hierarchical environments. However projects such as [25] are P2P, serverless file systems, designed to be used in environments where there is incomplete trust, and to implement advanced security features. These projects are very relevant to our work, and could be re-used in our Grid Operating System. In a Grid Operating System, each peer will most probably be either a Desktop PC or a Laptop PC. It is accepted that they will be physically distant from each other. There should be some mechanism in which each peer shall prioritize the other peers with the highest throughput of information dissemination. Another problem is that single peers cannot handle or store the information regarding each peer in a system. In order to provide scalability and to make the information dissemination more efficient, we propose a P2P topology-aware discovery service, in which the peers will be aware of all the other peers based on the available bandwidth from each peer. Resource discovery is one of the cornerstones of any Grid system. We advocate a network topology-aware resource discovery, which aims at making the Grid OS itself network aware. There are many Grid Resource discovery mechanisms [26, 27, 28, and 29] but none of them is network topology-aware. Topology-aware discovery services will enable the Grid OS to peruse the network infrastructure more optimally. In a Grid OS, some Peers will have variable network connectivity. The Peers that are closest to each other in our case are those which have a low round trip time (RTT) between them. Low RTT brings high bandwidth and hence faster communication. The proposed topology for our Grid OS should lead to fast and reliable communication between Peers. The goal of the proposed service is that Peers should self-organize themselves into sub-Grids, in which all peers are nearest neighbours to each other. All sub Grids and their peers will be members of the RootGrid. To demonstrate our approach, consider that we have six Peers and we need to find the nearest Peer among these six Peers with respect to our site. These Peers are named from 1-6. In order to find the nearest Peer, we have two options: either to calculate only the RTT from these Peers or to calculate available bandwidth to these Peers. In our case, we need more than just the RTT as the factor to find the nearest node. The other performance parameters that we propose to use include Packet Loss and Available bandwidth. As described in [30], we can estimate the upper bound of available bandwidth as a function of RTT, Packet Loss and MSS : BW < (MSS/RTT)*(1/sqrt (Packet Loss)) As we see in Figure 3, R6<R4<R2<R5<R3<R1; this shows that Peer 6 is the nearest node and then Peer 4 and so on. But in Figure 4, we see that B4>B6>BI>B5>B2>B3. It means that Peer 4 has a better network performance as compared to other Peers from our site. The reason behind these different results is that bandwidth doesn’t depend only on RTT, rather it also depend upon Packet Loss. In order to define nearest Peer, let us say we have N destination Peers, and we have to find the nearest Peer among them. B1, B2, B3,..., BN is the estimated available bandwidth from source to N destinations. Masters. After getting new information the Master propagates new information to all slaves. We believe the single most important determinant in the success of the Grid OS project will be security. In a Grid OS, resource providers need to be assured that no malicious programs will execute on their system and resource consumers must be assured that their data is safe in a Grid environment. Grid middleware provides no security in terms of preventing execution of malicious programs. However if the Grid is to be used in everyday user environments, a more comprehensive security framework must be designed. For a Grid OS we envisage an end-to-end security framework, which not only ensures users privacy and confidentiality of their data but also allows the user to set limits on resource usage, and to audit the same. A security framework for the Grid OS will encompass three components: Resource Provider security, Resource Consumer security and Transport security. Computer resources, such as processor cycles, memory and storage resources are provider by resource providers to foreign users. Without a credible security framework for resource providers to do so, no Grid system can function. Resource providers not only need surety that their resources will not be misused or worse perform a malicious act on their own computer system; they also need mechanisms to control their level of commitment to the Grid. The providers would be given tools with which they can configure resource usage levels and monitor them, and be notified of any violations. Some of the techniques developed in the past decade such as mandatory access controls within the kernel operating system are important features to control potential abuse. The users whose jobs are executing in the Grid need to be assured that their data is safe, and that their execution’s result cannot be tampered with by any external entity. Any Grid OS must explore the issue of keeping Grid scheduled data safe, in keeping the address space of the exported job in an area of the resource provider’s memory which the user himself cannot read or write, however the resource providers will have facilities to control the size of this area. Another possible solution is to run the exported program in a sandbox, and completely separate it from the resource provider’s own jobs. The Grid OS must ensure that data being transmitted between the nodes must be secure and it must also ensure its integrity when it reaches its destination. In a Grid OS there will be no central certification authority to handle authorization certificates. Rather each Peer must negotiate resource usage individually. However individual access negotiations are not scalable, and thus the user of proxy delegation is popular in Grids which leads to big performance boosts. A major issue in our project is how to handle privilege delegations in a Peer to Peer manner. As discussed in this paper Grid computing has been targeted to some segments of computer users, because of which various limitations have been built into existing Grid middleware. No conscious effort has been made to remove the barriers to adoption of Grid computing in user centric computing environments. In this paper we analyzed the most profound problems which are limiting the adoption of Grid computing in those fields. We believe an operating systems approach overcomes the problems highlighted in the paper, and takes the first step towards the creation of a pervasive framework for a Grid OS which would enable not only home and business users but also scientists, to do away with dedicated computing facilities for compute/data intensive application processing and to process their applications ron their own (or neighbouring) desktops. As a consequence hitherto unprecedented levels of collaboration can be achieved between users on the same computer resources. The Grid OS would also make fundamental contributions to existing Grid infrastructures e.g. the creation of enhanced P2P network topologies for Grids and enabling the execution of a multitude of Grid-enabled applications in addition to facilitating existing Grids to peruse millions of PCs located worldwide. The ultimate aim of our project is to bring Grid Computing to the Desktop, and the Desktop to the Grid. This paper discussed some components which would bring Grid Computing to the Desktop, mainly focusing on the lowest level in the ...