https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&feedformat=atom&user=ShivjotSoma-notes - User contributions [en]2026-05-12T18:07:38ZUser contributionsMediaWiki 1.42.1https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&diff=20072DistOS 2015W Session 122015-03-31T02:53:20Z<p>Shivjot: /* Haystack */</p>
<hr />
<div>=Haystack=<br />
* Facebook's Photo Application Storage System. <br />
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.<br />
*Main goals of Haystack:<br />
** High throughput with low latency<br />
**Fault tolerance<br />
**Cost effective<br />
**SImple<br />
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. <br />
*Haystack reduces the memory used for ''filesystem metadata'' <br />
*It has 2 types of metadata:<br />
**''Application metadata''<br />
**''File System metadata''<br />
* The architecture consists of 3 components:<br />
**Haystack Store<br />
**Haystack Directory<br />
**Haystack Cache<br />
<br />
=Comet=<br />
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.<br />
*Comet model works by offloading the computation intensive process from the mobile to only one server.<br />
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. <br />
=F4= <br />
=Sapphire=<br />
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.<br />
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.<br />
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&diff=20071DistOS 2015W Session 122015-03-31T02:52:40Z<p>Shivjot: /* Haystack */</p>
<hr />
<div>=Haystack=<br />
* Facebook's Photo Application Storage System. <br />
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.<br />
*Main goals of Haystack:<br />
** High throughput with low latency<br />
**Fault tolerance<br />
**Cost effective<br />
**SImple<br />
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. <br />
*Haystack reduces the memory used for ''filesystem metadata'' <br />
*It has 2 types of metadata:<br />
**''Application metadata''<br />
**''File System metadata''<br />
* The architecture consists of 3 components:<br />
**Haystack Store<br />
**Haystack Directory<br />
**Haystack Cache<br />
*<br />
<br />
=Comet=<br />
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.<br />
*Comet model works by offloading the computation intensive process from the mobile to only one server.<br />
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. <br />
=F4= <br />
=Sapphire=<br />
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.<br />
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.<br />
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&diff=20070DistOS 2015W Session 122015-03-31T02:45:48Z<p>Shivjot: /* Haystack */</p>
<hr />
<div>=Haystack=<br />
* Facebook's Photo Application Storage System. <br />
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.<br />
*Main goals of Haystack:<br />
** High throughput<br />
<br />
=Comet=<br />
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.<br />
*Comet model works by offloading the computation intensive process from the mobile to only one server.<br />
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. <br />
=F4= <br />
=Sapphire=<br />
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.<br />
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.<br />
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20069DistOS 2015W Session 112015-03-31T02:42:27Z<p>Shivjot: /* Spanner */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* Service Level Agreements(SLA): They are a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
* System Architecture: It consists of ''System Interface'', ''Partitioning Algorithm'', ''Replication'',''Data Versioning''.<br />
* Successfully handles<br />
** Server Failure<br />
** Data Centre Failure<br />
** Network Partitions<br />
* Allows service owners to customize their own storage systems according to their storage systems to meet the desired performance, durability and consistency SLAs.<br />
* Building block for highly available applications.<br />
<br />
==Cassandra==<br />
* Facebook's storage system to fulfil needs of the Inbox Search Problem<br />
*Partitions data across the cluster using consistent hashing.<br />
*Distributed multi dimensional map indexed by a key<br />
* In it's data model:<br />
** Columns grouped together into sets called column families. Column Families further of 2 types:<br />
***Simple column families<br />
***Super column families<br />
* API consists of :<br />
** Insert<br />
**Get<br />
** Delete<br />
* System Architecture consists of :<br />
** Partitioning: Takes place using consistent hashing<br />
**Replication: Each item replicated at n hosts where "n" is the replication factor configured per system. <br />
** Membership: Cluster membership is based on Scuttle butt which is a highly efficient anti-entropy Gossip based mechanism.The Membership further has sub part such as:<br />
***Failure Detection<br />
**Bootstrapping<br />
** Scaling the cluster<br />
<br />
=Spanner=<br />
* Google's scalable, multi version, globally distributed database.<br />
* Has been built on top of the Google's Big table.<br />
*Provided data consistency and Supports SQL like Interface.<br />
*Main focus is managing cross-datacentre replicated data.<br />
* Uses True time to guarantee the correctness properties around concurrency control.<br />
** The timestamps are utilized.</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20068DistOS 2015W Session 112015-03-31T02:34:47Z<p>Shivjot: /* Spanner */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* Service Level Agreements(SLA): They are a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
* System Architecture: It consists of ''System Interface'', ''Partitioning Algorithm'', ''Replication'',''Data Versioning''.<br />
* Successfully handles<br />
** Server Failure<br />
** Data Centre Failure<br />
** Network Partitions<br />
* Allows service owners to customize their own storage systems according to their storage systems to meet the desired performance, durability and consistency SLAs.<br />
* Building block for highly available applications.<br />
<br />
==Cassandra==<br />
* Facebook's storage system to fulfil needs of the Inbox Search Problem<br />
*Partitions data across the cluster using consistent hashing.<br />
*Distributed multi dimensional map indexed by a key<br />
* In it's data model:<br />
** Columns grouped together into sets called column families. Column Families further of 2 types:<br />
***Simple column families<br />
***Super column families<br />
* API consists of :<br />
** Insert<br />
**Get<br />
** Delete<br />
* System Architecture consists of :<br />
** Partitioning: Takes place using consistent hashing<br />
**Replication: Each item replicated at n hosts where "n" is the replication factor configured per system. <br />
** Membership: Cluster membership is based on Scuttle butt which is a highly efficient anti-entropy Gossip based mechanism.The Membership further has sub part such as:<br />
***Failure Detection<br />
**Bootstrapping<br />
** Scaling the cluster<br />
<br />
=Spanner=<br />
* Google's scalable, multi version, globally distributed database.<br />
*Provided data consistency and Supports SQL like Interface.<br />
*Main focus is managing cross-datacentre replicated data</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20067DistOS 2015W Session 112015-03-31T02:31:24Z<p>Shivjot: /* Cassandra */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* Service Level Agreements(SLA): They are a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
* System Architecture: It consists of ''System Interface'', ''Partitioning Algorithm'', ''Replication'',''Data Versioning''.<br />
* Successfully handles<br />
** Server Failure<br />
** Data Centre Failure<br />
** Network Partitions<br />
* Allows service owners to customize their own storage systems according to their storage systems to meet the desired performance, durability and consistency SLAs.<br />
* Building block for highly available applications.<br />
<br />
==Cassandra==<br />
* Facebook's storage system to fulfil needs of the Inbox Search Problem<br />
*Partitions data across the cluster using consistent hashing.<br />
*Distributed multi dimensional map indexed by a key<br />
* In it's data model:<br />
** Columns grouped together into sets called column families. Column Families further of 2 types:<br />
***Simple column families<br />
***Super column families<br />
* API consists of :<br />
** Insert<br />
**Get<br />
** Delete<br />
* System Architecture consists of :<br />
** Partitioning: Takes place using consistent hashing<br />
**Replication: Each item replicated at n hosts where "n" is the replication factor configured per system. <br />
** Membership: Cluster membership is based on Scuttle butt which is a highly efficient anti-entropy Gossip based mechanism.The Membership further has sub part such as:<br />
***Failure Detection<br />
**Bootstrapping<br />
** Scaling the cluster<br />
<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20066DistOS 2015W Session 112015-03-31T02:29:15Z<p>Shivjot: /* Cassandra */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* Service Level Agreements(SLA): They are a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
* System Architecture: It consists of ''System Interface'', ''Partitioning Algorithm'', ''Replication'',''Data Versioning''.<br />
* Successfully handles<br />
** Server Failure<br />
** Data Centre Failure<br />
** Network Partitions<br />
* Allows service owners to customize their own storage systems according to their storage systems to meet the desired performance, durability and consistency SLAs.<br />
* Building block for highly available applications.<br />
<br />
==Cassandra==<br />
* Facebook's storage system to fulfil needs of the Inbox Search Problem<br />
*Partitions data across the cluster using consistent hashing.<br />
*Distributed multi dimensional map indexed by a key<br />
* In it's data model:<br />
** Columns grouped together into sets called column families. Column Families further of 2 types:<br />
***Simple column families<br />
***Super column families<br />
* API consists of :<br />
** Insert<br />
**Get<br />
** Delete<br />
* System Architecture consists of :<br />
** Partitioning: Takes place using consistent hashing<br />
**Replication: Each item replicated at n hosts where "n" is the replication factor configured per system. <br />
** Membership<br />
**Bootstrapping<br />
** Scaling the cluster<br />
<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20065DistOS 2015W Session 112015-03-31T02:26:07Z<p>Shivjot: /* Cassandra */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* Service Level Agreements(SLA): They are a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
* System Architecture: It consists of ''System Interface'', ''Partitioning Algorithm'', ''Replication'',''Data Versioning''.<br />
* Successfully handles<br />
** Server Failure<br />
** Data Centre Failure<br />
** Network Partitions<br />
* Allows service owners to customize their own storage systems according to their storage systems to meet the desired performance, durability and consistency SLAs.<br />
* Building block for highly available applications.<br />
<br />
==Cassandra==<br />
* Facebook's storage system to fulfil needs of the Inbox Search Problem<br />
*Partitions data across the cluster using consistent hashing.<br />
*Distributed multi dimensional map indexed by a key<br />
* In it's data model:<br />
** Columns grouped together into sets called column families. Column Families further of 2 types:<br />
***Simple column families<br />
***Super column families<br />
* API consists of :<br />
** Insert<br />
**Get<br />
** Delete<br />
*<br />
<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20064DistOS 2015W Session 112015-03-31T02:15:20Z<p>Shivjot: /* Dynamo */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* Service Level Agreements(SLA): They are a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
* System Architecture: It consists of ''System Interface'', ''Partitioning Algorithm'', ''Replication'',''Data Versioning''.<br />
* Successfully handles<br />
** Server Failure<br />
** Data Centre Failure<br />
** Network Partitions<br />
* Allows service owners to customize their own storage systems according to their storage systems to meet the desired performance, durability and consistency SLAs.<br />
* Building block for highly available applications.<br />
<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20062DistOS 2015W Session 112015-03-30T23:18:32Z<p>Shivjot: /* Dynamo */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
* Amazon's Key Value Store<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
* This system has certain requirements such as: <br />
** Query Model: Simple read and write operations to data item that are uniquely identified by a key.<br />
**ACID properties: Atomicity, Consistency, Isolation, Durability.<br />
**Efficiency: System needs to function on a commodity hardware infrastructure.<br />
* The system consists of Service Level Agreements(SLA), which is a negotiated contract between a client and a service regarding characteristics related to systems. They are used in order to guarantee that in a bounded time period, an application can deliver it's functionality.<br />
<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20061DistOS 2015W Session 112015-03-30T23:07:54Z<p>Shivjot: /* Dynamo */</p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
*Sacrifices consistency under certain failure scenarios.<br />
*Treats failure handling as normal case without impact on availability and performance.<br />
*Data is partitioned and replicated using consistent hashing and consistency is facilitated by use of object versioning.<br />
<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20060DistOS 2015W Session 112015-03-30T23:03:59Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
** Set of wrappers which allow Big Data to be used both as<br />
*** Input source<br />
***Output Target<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20049DistOS 2015W Session 112015-03-28T18:49:47Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**Changing Cluster<br />
**Changing Table<br />
**Column Family metadata like Access Control Rights.<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20048DistOS 2015W Session 112015-03-28T18:48:41Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
* Big Table '''API''': Provides functions for<br />
** Creating and Deleting<br />
*** Tables<br />
*** Column Families<br />
**<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20047DistOS 2015W Session 112015-03-28T18:46:18Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: Every read or write of data under single row key is atomic. Each row range is called Tablet. Select Row key to get good locality for data access.<br />
** Column Key: Grouped into sets called Column Families. Forms basic unit of Access Control.All data stored is of same type.Syntax used: ''family:qualifier''<br />
** Time Stamp:Each cell consists of multiple versions of same data which are indexed by Timestamps.In order to avoid collisions, Timestamps need to be generated by applications.<br />
<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20046DistOS 2015W Session 112015-03-28T18:41:51Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance Google Analytics, Google Finance, Orkut, Personalized Search, Writely, Google Earth and many more<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: <br />
Every read or write of data under single row key is atomic. <br />
Each row range is called Tablet. <br />
Select Row key to get good locality for data access.<br />
** Column Key: <br />
** Time Stamp<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20045DistOS 2015W Session 112015-03-28T18:40:55Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance<br />
** Google Analytics<br />
** Google Finance<br />
** Orkut<br />
** Personalized Search<br />
** Writely<br />
**Google Earth<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key: <br />
Every read or write of data under single row key is atomic. <br />
Each row range is called Tablet. <br />
Select Row key to get good locality for data access.<br />
** Column Key: <br />
** Time Stamp<br />
<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20044DistOS 2015W Session 112015-03-28T18:36:32Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance<br />
** Google Analytics<br />
** Google Finance<br />
** Orkut<br />
** Personalized Search<br />
** Writely<br />
**Google Earth<br />
<br />
* Big table is <br />
** Sparse<br />
** Persistant<br />
** Muti dimensional Sorted Map<br />
*It is indexed by<br />
** Row Key<br />
** Column Key<br />
** Time Stamp<br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20043DistOS 2015W Session 112015-03-28T18:34:47Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance<br />
** Google Analytics<br />
** Google Finance<br />
** Orkut<br />
** Personalized Search<br />
** Writely<br />
**Google Earth<br />
<br />
* <br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20042DistOS 2015W Session 112015-03-28T18:34:08Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google System used for storing data of various Google Products, for instance<br />
** Google Analytics<br />
** Google Finance<br />
** Orkut<br />
** Personalized Search<br />
** Writely<br />
**Google Earth<br />
<br />
* Distributed Storage System for managing structured data, designed to scale <br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_11&diff=20041DistOS 2015W Session 112015-03-28T18:32:37Z<p>Shivjot: </p>
<hr />
<div>==BigTable==<br />
* Google Product used for storing data of<br />
** Google Analytics<br />
** Google Finance<br />
** Orkut<br />
<br />
* Distributed Storage System for managing structured data, designed to scale <br />
== Dynamo==<br />
*Availability is the buzz word for Dynamo. Dynamo=Availability<br />
*Shifted Computer Science paradigm from caring about the consistency to availability.<br />
==Cassandra==<br />
*Partitions data across the cluster using consistent hashing.<br />
=Spanner=<br />
*Provided data consistency and Supports SQL like Interface</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&diff=19969DistOS 2015W Session 92015-03-10T00:42:08Z<p>Shivjot: </p>
<hr />
<div><br />
== BONIC ==<br />
<br />
*Public Resource Computing Platform<br />
*Gives scientists the ability to use large amounts of computation resources.<br />
*The clients do not connect directly with each other but instead they talk to a central server located at Berkley<br />
*The goals of Bonic are: <br />
:*1) reduce the barriers of entry<br />
:*2) Share resources among autonomous projects<br />
:*3) Support diverse applications<br />
:*4) Reward participants.<br />
A BONIC application can be identified by a single master URL, <br/>which serves as the homepage as well as the directory of the servers.<br />
<br />
== SETI@Home ==<br />
<br />
*Uses public resource computing to analyze radio signals to find extraterrestrial intelligence<br />
*Need good quality telescope to search for radio signals, and lots of computational power, which was unavailable locally<br />
*It has not yet found extraterrestrial intelligence, but its has established credibility of public resource computing projects which are given by the public<br />
*Uses BONIC as a backbone for the project<br />
*Uses relational database to store information on a large scale, further it uses a multi-threaded server to distribute work to clients<br />
<br />
== MapReduce ==<br />
<br />
*A programming model presented by Google to do large scale parallel computations<br />
*Uses the <code>Map()</code> and <code>Reduce()</code> functions from functional style programming languages<br />
:*Map (Filtering)<br />
::*Takes a function and applies it to all elements of the given data set<br />
:*Reduce (Summary)<br />
::*Accumulates results from the data set using a given function<br />
<br />
== Naiad ==<br />
<br />
*A programming model similar to <code>MapReduce</code> but with streaming capabilities so that data results are almost instantaneous<br />
*A distributed system for executing data parallel cyclic dataflow programs offering high throughput and low latency<br />
*Aims to provide a general purpose system which will fulfill the requirements and the will also support wide variety of high level programming models.<br />
*Real Time Applications:<br />
:*Batch iterative Machine Learning: <br />
VW, an open source distributed machine learning performs iteration in 3 phases: each process updates local state; processes independently training on local data; and process jointly performed global average which is All Reduce.</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&diff=19962DistOS 2015W Session 92015-03-10T00:16:35Z<p>Shivjot: Created page with "'''BONIC''' *Public Resource Computing Platform *Gives scientists the ability to use large amounts of computation resources. *The goals of Bonic are: :*1) reduce the barriers..."</p>
<hr />
<div>'''BONIC'''<br />
*Public Resource Computing Platform<br />
*Gives scientists the ability to use large amounts of computation resources.<br />
*The goals of Bonic are: <br />
:*1) reduce the barriers of entry<br />
:*2) Share resources among autonomous projects<br />
:*3)Support diverse applications<br />
:*4)Reward participants.<br />
A BONIC application can be identified by a single master URL, which serves as the homepage as well as the directory of the servers.</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_6&diff=19858DistOS 2015W Session 62015-02-10T03:22:15Z<p>Shivjot: </p>
<hr />
<div><br />
<br />
==Midterm==<br />
<br />
The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].<br />
<br />
==Group 1==<br />
<br />
'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan<br />
<br />
{| class="wikitable"<br />
|-<br />
!<br />
! FARSITE<br />
! OceanStore<br />
|-<br />
! Fault Tolerance<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
|-<br />
! Cryptography<br />
| Trusted Certificates<br />
| A strong cryptographic algorithm on read-only operations<br />
|-<br />
! Implementation<br />
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system<br />
| Implemented in JAVA<br />
|-<br />
! Scalability<br />
| Scalable to a University or large corporations, maximum 10<sup>5</sup><br />
| Worldwide scalability, maximum 10<sup>10</sup><br />
|-<br />
! File Usage<br />
| Was designed for general purpose files<br />
| Was designed for small file sizes<br />
|-<br />
! Scope<br />
| All clients sharing the available resources<br />
| Transient centralized service<br />
|-<br />
! Object Model<br />
| Didn't use the object model<br />
| Used the object model<br />
|}<br />
<br />
==Group 2==<br />
'''Team''': Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot<br />
<br />
<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0" class="wikitable"><br />
<tr><br />
<td><p>'''Farsite'''</p></td><br />
<td><p>'''OceanStore'''</p></td><br />
</tr><br />
<tr><br />
<td><p>Implemented Content Leases</p></td><br />
<td><p>Update Model handled data consistency, no Leases</p></td><br />
</tr><br />
<tr><br />
<td><p>Single tier, peer to peer model</p></td><br />
<td><p>Two tier, server client model</p></td><br />
</tr><br />
<tr><br />
<td><p>Scope of ten to the five</p></td><br />
<td><p>Global Scope (ten to the ten)</p></td><br />
</tr><br />
<tr><br />
<td><p>Cryptographic public, private key security</p></td><br />
<td><p>Read and write privileges</p></td><br />
</tr><br />
<tr><br />
<td><p>Randomized data replication</p></td><br />
<td><p>Nomadic Data concept</p></td><br />
</tr><br />
</table><br />
<br />
==Group 3== <br />
'''Team''': DANY, MOE, DEEP, SAMEER, TROY<br />
<br />
<br />
----<br />
'''<br />
== FARSITE ==<br />
'''<br />
<br />
'''Security''' <br />
• Cascading certificates system through directory hierarchy <br />
• Keys <br />
• Three types of certificates <br />
• CFS required to authorized certificate<br />
• Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make <br />
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users<br />
who are authorized writers to that directory and to files in it<br />
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy.<br />
<br />
'''System Architecture''' <br />
• Client Monitor, directory group, file host<br />
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group. <br />
<br />
<br />
<br />
----<br />
'''<br />
== OCEANSTORE ==<br />
'''<br />
<br />
'''Security''' <br />
• GUID and ACLs used for write, encryption used for reads.<br />
• To prevent unauthorized reads, it encrypts<br />
all data in the system that is not completely public and distributes the encryption key to those users with read permission</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_6&diff=19857DistOS 2015W Session 62015-02-10T03:21:25Z<p>Shivjot: /* Group 3 */</p>
<hr />
<div><br />
==Midterm==<br />
<br />
The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].<br />
<br />
==Group 1==<br />
<br />
'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan<br />
<br />
{| class="wikitable"<br />
|-<br />
!<br />
! FARSITE<br />
! OceanStore<br />
|-<br />
! Fault Tolerance<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
|-<br />
! Cryptography<br />
| Trusted Certificates<br />
| A strong cryptographic algorithm on read-only operations<br />
|-<br />
! Implementation<br />
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system<br />
| Implemented in JAVA<br />
|-<br />
! Scalability<br />
| Scalable to a University or large corporations, maximum 10<sup>5</sup><br />
| Worldwide scalability, maximum 10<sup>10</sup><br />
|-<br />
! File Usage<br />
| Was designed for general purpose files<br />
| Was designed for small file sizes<br />
|-<br />
! Scope<br />
| All clients sharing the available resources<br />
| Transient centralized service<br />
|-<br />
! Object Model<br />
| Didn't use the object model<br />
| Used the object model<br />
|}<br />
<br />
==Group 2==<br />
'''Team''': Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot<br />
<br />
<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0" class="wikitable"><br />
<tr><br />
<td><p>'''Farsite'''</p></td><br />
<td><p>'''OceanStore'''</p></td><br />
</tr><br />
<tr><br />
<td><p>Implemented Content Leases</p></td><br />
<td><p>Update Model handled data consistency, no Leases</p></td><br />
</tr><br />
<tr><br />
<td><p>Single tier, peer to peer model</p></td><br />
<td><p>Two tier, server client model</p></td><br />
</tr><br />
<tr><br />
<td><p>Scope of ten to the five</p></td><br />
<td><p>Global Scope (ten to the ten)</p></td><br />
</tr><br />
<tr><br />
<td><p>Cryptographic public, private key security</p></td><br />
<td><p>Read and write privileges</p></td><br />
</tr><br />
<tr><br />
<td><p>Randomized data replication</p></td><br />
<td><p>Nomadic Data concept</p></td><br />
</tr><br />
</table><br />
<br />
==Group 3== <br />
'''Team''': DANY, MOE, DEEP, SAMEER, TROY<br />
<br />
<br />
----<br />
'''FARSITE'''<br />
<br />
'''Security''' <br />
• Cascading certificates system through directory hierarchy <br />
• Keys <br />
• Three types of certificates <br />
• CFS required to authorized certificate<br />
• Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make <br />
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users<br />
who are authorized writers to that directory and to files in it<br />
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy.<br />
<br />
'''System Architecture''' <br />
• Client Monitor, directory group, file host<br />
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group. <br />
<br />
<br />
<br />
----<br />
'''OCEANSTORE'''<br />
<br />
'''Security''' <br />
• GUID and ACLs used for write, encryption used for reads.<br />
• To prevent unauthorized reads, it encrypts<br />
all data in the system that is not completely public and distributes the encryption key to those users with read permission</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_6&diff=19856DistOS 2015W Session 62015-02-10T03:17:59Z<p>Shivjot: </p>
<hr />
<div><br />
==Midterm==<br />
<br />
The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].<br />
<br />
==Group 1==<br />
<br />
'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan<br />
<br />
{| class="wikitable"<br />
|-<br />
!<br />
! FARSITE<br />
! OceanStore<br />
|-<br />
! Fault Tolerance<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
|-<br />
! Cryptography<br />
| Trusted Certificates<br />
| A strong cryptographic algorithm on read-only operations<br />
|-<br />
! Implementation<br />
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system<br />
| Implemented in JAVA<br />
|-<br />
! Scalability<br />
| Scalable to a University or large corporations, maximum 10<sup>5</sup><br />
| Worldwide scalability, maximum 10<sup>10</sup><br />
|-<br />
! File Usage<br />
| Was designed for general purpose files<br />
| Was designed for small file sizes<br />
|-<br />
! Scope<br />
| All clients sharing the available resources<br />
| Transient centralized service<br />
|-<br />
! Object Model<br />
| Didn't use the object model<br />
| Used the object model<br />
|}<br />
<br />
==Group 2==<br />
'''Team''': Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot<br />
<br />
<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0" class="wikitable"><br />
<tr><br />
<td><p>'''Farsite'''</p></td><br />
<td><p>'''OceanStore'''</p></td><br />
</tr><br />
<tr><br />
<td><p>Implemented Content Leases</p></td><br />
<td><p>Update Model handled data consistency, no Leases</p></td><br />
</tr><br />
<tr><br />
<td><p>Single tier, peer to peer model</p></td><br />
<td><p>Two tier, server client model</p></td><br />
</tr><br />
<tr><br />
<td><p>Scope of ten to the five</p></td><br />
<td><p>Global Scope (ten to the ten)</p></td><br />
</tr><br />
<tr><br />
<td><p>Cryptographic public, private key security</p></td><br />
<td><p>Read and write privileges</p></td><br />
</tr><br />
<tr><br />
<td><p>Randomized data replication</p></td><br />
<td><p>Nomadic Data concept</p></td><br />
</tr><br />
</table><br />
<br />
==Group 3== <br />
'''Team''': DANY, MOE, DEEP, SAMEER, TROY<br />
<br />
'''FARSITE'''<br />
<br />
'''Security''' <br />
• Cascading certificates system through directory hierarchy <br />
• Keys <br />
• Three types of certificates <br />
• CFS required to authorized certificate<br />
• Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make <br />
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users<br />
who are authorized writers to that directory and to files in it<br />
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy.<br />
<br />
'''System Architecture''' <br />
• Client Monitor, directory group, file host<br />
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group. <br />
<br />
<br />
'''OCEANSTORE'''<br />
<br />
'''Security''' <br />
• GUID and ACLs used for write, encryption used for reads.<br />
• To prevent unauthorized reads, it encrypts<br />
all data in the system that is not completely public and distributes the encryption key to those users with read permission</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_6&diff=19855DistOS 2015W Session 62015-02-10T03:17:18Z<p>Shivjot: </p>
<hr />
<div><br />
==Midterm==<br />
<br />
The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].<br />
<br />
==Group 1==<br />
<br />
'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan<br />
<br />
{| class="wikitable"<br />
|-<br />
!<br />
! FARSITE<br />
! OceanStore<br />
|-<br />
! Fault Tolerance<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
| Used Byzantine Fault Tolerance Algorithm - Did not manage well<br />
|-<br />
! Cryptography<br />
| Trusted Certificates<br />
| A strong cryptographic algorithm on read-only operations<br />
|-<br />
! Implementation<br />
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system<br />
| Implemented in JAVA<br />
|-<br />
! Scalability<br />
| Scalable to a University or large corporations, maximum 10<sup>5</sup><br />
| Worldwide scalability, maximum 10<sup>10</sup><br />
|-<br />
! File Usage<br />
| Was designed for general purpose files<br />
| Was designed for small file sizes<br />
|-<br />
! Scope<br />
| All clients sharing the available resources<br />
| Transient centralized service<br />
|-<br />
! Object Model<br />
| Didn't use the object model<br />
| Used the object model<br />
|}<br />
<br />
==Group 2==<br />
Team Members: Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot<br />
<br />
<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0" class="wikitable"><br />
<tr><br />
<td><p>'''Farsite'''</p></td><br />
<td><p>'''OceanStore'''</p></td><br />
</tr><br />
<tr><br />
<td><p>Implemented Content Leases</p></td><br />
<td><p>Update Model handled data consistency, no Leases</p></td><br />
</tr><br />
<tr><br />
<td><p>Single tier, peer to peer model</p></td><br />
<td><p>Two tier, server client model</p></td><br />
</tr><br />
<tr><br />
<td><p>Scope of ten to the five</p></td><br />
<td><p>Global Scope (ten to the ten)</p></td><br />
</tr><br />
<tr><br />
<td><p>Cryptographic public, private key security</p></td><br />
<td><p>Read and write privileges</p></td><br />
</tr><br />
<tr><br />
<td><p>Randomized data replication</p></td><br />
<td><p>Nomadic Data concept</p></td><br />
</tr><br />
</table><br />
<br />
==Group 3== <br />
DANY, MOE, DEEP, SAMEER, TROY<br />
<br />
'''FARSITE'''<br />
<br />
'''Security''' <br />
• Cascading certificates system through directory hierarchy <br />
• Keys <br />
• Three types of certificates <br />
• CFS required to authorized certificate<br />
• Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make <br />
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users<br />
who are authorized writers to that directory and to files in it<br />
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy.<br />
<br />
'''System Architecture''' <br />
• Client Monitor, directory group, file host<br />
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group. <br />
<br />
<br />
'''OCEANSTORE'''<br />
<br />
'''Security''' <br />
• GUID and ACLs used for write, encryption used for reads.<br />
• To prevent unauthorized reads, it encrypts<br />
all data in the system that is not completely public and distributes the encryption key to those users with read permission</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_6&diff=19845DistOS 2015W Session 62015-02-09T20:52:44Z<p>Shivjot: </p>
<hr />
<div><br />
==Midterm==<br />
<br />
The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].<br />
<br />
==Group 1==<br />
<br />
==Group 2==<br />
Team Members: Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot<br />
<br />
<br />
==Group 3==</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19765DistOS 2015W Session 52015-02-03T04:55:08Z<p>Shivjot: </p>
<hr />
<div><br />
== '''Cloud Distributed Operating System'''==<br />
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.<br />
The OS is based on 2 patterns:<br />
1. Message Based OS<br />
2. Object Based OS<br />
<br />
The structure of this is based on '''Object Thread Model.''' <br />
It has set of objects which are defined by the class. Objects respond to messages. <br />
Sending message to object causes object to execute the method and then reply back. <br />
<br />
It has Active Objects and Passive objects<br />
<br />
1.'''Active Objects''' are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br />
2.'''Passive Objects''' are the object which have no processes in them.<br />
<br />
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.<br />
<br />
Another important part of Cloud DOS are '''threads'''<br />
<br />
The threads are the logical path of execution that traverse objects and executes code in them. <br />
<br />
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.<br />
<br />
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.<br />
<br />
<br />
Interaction between '''Objects''' and '''Threads'''<br />
1)Inter object interfaces are procedural<br />
2)Invocations work across machine boundaries<br />
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br />
4)Control flow achieved by threads invoking objects.<br />
<br />
'''Cloud Environment'''<br />
1) Integrates set of homogeneous machines into one seamless environment<br />
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.<br />
<br />
<br />
----<br />
<br />
== '''Plan 9''' ==<br />
<br />
Plan 9 is a general purpose, multiuser and mobile computing environment physically distributed across machines. <br />
The Plan 9 began in late 1980s. The aims of this system are:<br />
1) To built a system that should be centrally administered <br />
2) Cost effective using cheap modern microcomputers. <br />
The distribution itself is transparent to most programs.<br />
This property is made possible by 2 properties:<br />
1) A per process group name space<br />
2) A uniform access to all the resources by representing them as a file.<br />
<br />
It is quite similar to the Unix yet so different. The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. The problems in UNIX were too deep to fix but still the various ideas were brought along. The problems addressed badly by UNIX were improved. Old tools were dropped and others were polished and reused.<br />
<br />
What actually distinguishes Plan 9 is its '''organization'''.<br />
<br />
Plan 9 is divided along the lines of service function. <br />
* CPU services and terminals use same kernel<br />
* Users may choose to run programs locally or remotely on CPU servers<br />
*Gives the user a choice to choose whether they want distributed or centralized.<br />
<br />
The design of Plan 9 is based on 3 principles:<br />
1) Resources are named and accessed like files in hierarchical file system.<br />
2) Standard protocol 9P<br />
3) Disjoint hierarchical provided by different services are joined together into single private hierarchal file name space.<br />
<br />
Another concept in Plan 9 is the '''Virtual Name Space'''<br />
In a '''Virtual Name Space''', a user boots a terminal or connects to a CPU server and then a new process group is created. <br />
Processes in group can either add to or rearrange their name space using two system calls- [[Mount]] and [[Bind]]<br />
* '''Mount''' is used to attach new file system to a point in name space.<br />
*'''Bind''' is used to attach a kernel resident file system to name space and also arrange pieces of name space.<br />
<br />
The plan 9 provides mechanism to customize one's view of the system with the help of the software rather than the hardware.<br />
It is built for the traditional system but it can be extended to the other resources. <br />
<br />
'''Parallel Programming'''<br />
The parallel programming has two aspects:<br />
* Kernel provides simple process model and carefully designed system calls for synchronization.<br />
*Programming language supports concurrent programming.<br />
<br />
'''Implementation of Name Spaces'''<br />
User processes construct name specs using three system calls- mount, bind, unmount.<br />
Mount- System call attaches a tree served by a file server to the current name specs<br />
Bind-Duplicates pieces of existing name specs at another point<br />
Unmount- Allows components to be removed.<br />
----<br />
<br />
== '''Google File System''' ==<br />
<br />
It is scalable file system for large distributed data intensive applications. The design is driven by providing previous applications workloads and technical environments, both current and anticipated. <br />
<br />
The architecture of the google file system consists of a single master and multiple clients. Files are divided into fixed size chunks. Each chunk is identified by globally unique 64 bit chunk handle assigned by master at the end of the time of chunk creation. The master maintains all the file system meta data which include the name space and also the access control information.</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19764DistOS 2015W Session 52015-02-03T04:43:08Z<p>Shivjot: </p>
<hr />
<div><br />
== '''Cloud Distributed Operating System'''==<br />
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.<br />
The OS is based on 2 patterns:<br />
1. Message Based OS<br />
2. Object Based OS<br />
<br />
The structure of this is based on '''Object Thread Model.''' <br />
It has set of objects which are defined by the class. Objects respond to messages. <br />
Sending message to object causes object to execute the method and then reply back. <br />
<br />
It has Active Objects and Passive objects<br />
<br />
1.'''Active Objects''' are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br />
2.'''Passive Objects''' are the object which have no processes in them.<br />
<br />
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.<br />
<br />
Another important part of Cloud DOS are '''threads'''<br />
<br />
The threads are the logical path of execution that traverse objects and executes code in them. <br />
<br />
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.<br />
<br />
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.<br />
<br />
<br />
Interaction between '''Objects''' and '''Threads'''<br />
1)Inter object interfaces are procedural<br />
2)Invocations work across machine boundaries<br />
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br />
4)Control flow achieved by threads invoking objects.<br />
<br />
'''Cloud Environment'''<br />
1) Integrates set of homogeneous machines into one seamless environment<br />
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.<br />
<br />
<br />
----<br />
'''Plan 9'''<br />
<br />
Plan 9 is a general purpose, multiuser and mobile computing environment physically distributed across machines. <br />
The Plan 9 began in late 1980s. The aims of this system are:<br />
1) To built a system that should be centrally administered <br />
2) Cost effective using cheap modern microcomputers. <br />
The distribution itself is transparent to most programs.<br />
This property is made possible by 2 properties:<br />
1) A per process group name space<br />
2) A uniform access to all the resources by representing them as a file.<br />
<br />
It is quite similar to the Unix yet so different. The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. The problems in UNIX were too deep to fix but still the various ideas were brought along. The problems addressed badly by UNIX were improved. Old tools were dropped and others were polished and reused.<br />
<br />
What actually distinguishes Plan 9 is its '''organization'''.<br />
<br />
Plan 9 is divided along the lines of service function. <br />
* CPU services and terminals use same kernel<br />
* Users may choose to run programs locally or remotely on CPU servers<br />
*Gives the user a choice to choose whether they want distributed or centralized.<br />
<br />
The design of Plan 9 is based on 3 principles:<br />
1) Resources are named and accessed like files in hierarchical file system.<br />
2) Standard protocol 9P<br />
3) Disjoint hierarchical provided by different services are joined together into single private hierarchal file name space.<br />
<br />
Another concept in Plan 9 is the '''Virtual Name Space'''<br />
In a '''Virtual Name Space''', a user boots a terminal or connects to a CPU server and then a new process group is created. <br />
Processes in group can either add to or rearrange their name space using two system calls- [[Mount]] and [[Bind]]<br />
* '''Mount''' is used to attach new file system to a point in name space.<br />
*'''Bind''' is used to attach a kernel resident file system to name space and also arrange pieces of name space.<br />
<br />
The plan 9 provides mechanism to customize one's view of the system with the help of the software rather than the hardware.<br />
It is built for the traditional system but it can be extended to the other resources. <br />
<br />
'''Parallel Programming'''<br />
The parallel programming has two aspects:<br />
* Kernel provides simple process model and carefully designed system calls for synchronization.<br />
*Programming language supports concurrent programming.<br />
<br />
'''Implementation of Name Spaces'''<br />
User processes construct name specs using three system calls- mount, bind, unmount.<br />
<br />
----</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19763DistOS 2015W Session 52015-02-03T03:34:26Z<p>Shivjot: </p>
<hr />
<div>'''Cloud Distributed Operating System'''<br />
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.<br />
The OS is based on 2 patterns:<br />
1. Message Based OS<br />
2. Object Based OS<br />
<br />
The structure of this is based on '''Object Thread Model.''' <br />
It has set of objects which are defined by the class. Objects respond to messages. <br />
Sending message to object causes object to execute the method and then reply back. <br />
<br />
It has Active Objects and Passive objects<br />
<br />
1.'''Active Objects''' are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br />
2.'''Passive Objects''' are the object which have no processes in them.<br />
<br />
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.<br />
<br />
Another important part of Cloud DOS are '''threads'''<br />
<br />
The threads are the logical path of execution that traverse objects and executes code in them. <br />
<br />
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.<br />
<br />
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.<br />
<br />
<br />
Interaction between '''Objects''' and '''Threads'''<br />
1)Inter object interfaces are procedural<br />
2)Invocations work across machine boundaries<br />
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br />
4)Control flow achieved by threads invoking objects.<br />
<br />
'''Cloud Environment'''<br />
1) Integrates set of homogeneous machines into one seamless environment<br />
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.<br />
<br />
<br />
----<br />
'''Plan 9'''<br />
<br />
Plan 9 is a general purpose, multiuser and mobile computing environment physically distributed across machines. <br />
The Plan 9 began in late 1980s. The aims of this system are:<br />
1) To built a system that should be centrally administered <br />
2) Cost effective using cheap modern microcomputers. <br />
The distribution itself is transparent to most programs.<br />
This property is made possible by 2 properties:<br />
1) A per process group name space<br />
2) A uniform access to all the resources by representing them as a file.<br />
<br />
It is quite similar to the Unix yet so different. The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. The problems in UNIX were too deep to fix but still the various ideas were brought along.<br />
<br />
What actually distinguishes Plan 9 is its '''organization'''.<br />
<br />
Plan 9 is divided along the lines of service function. <br />
* CPU services and terminals use same kernel<br />
* Users may choose to run programs locally or remotely on CPU servers<br />
*Gives the user a choice to choose whether they want distributed or centralized.<br />
<br />
The design of Plan 9 is based on 3 principles:<br />
1) Resources are named and accessed like files in hierarchical file system.<br />
2) Standard protocol 9P<br />
3) Disjoint hierarchical provided by different services are joined together into single private hierarchal file name space.<br />
<br />
Another concept in Plan 9 is the '''Virtual Name Space'''<br />
In a '''Virtual Name Space''', a user boots a terminal or connects to a CPU server and then a new process group is created. <br />
Processes in group can either add to or rearrange their name space using two system calls- [[Mount]] and [[Bind]]<br />
* '''Mount''' is used to attach new file system to a point in name space.<br />
*'''Bind''' is used to attach a kernel resident file system to name space and also arrange pieces of name space.<br />
----</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19762DistOS 2015W Session 52015-02-03T03:24:28Z<p>Shivjot: </p>
<hr />
<div>'''[[Cloud Distributed Operating System]]'''<br />
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.<br />
The OS is based on 2 patterns:<br />
1. Message Based OS<br />
2. Object Based OS<br />
<br />
The structure of this is based on '''Object Thread Model.''' <br />
It has set of objects which are defined by the class. Objects respond to messages. <br />
Sending message to object causes object to execute the method and then reply back. <br />
<br />
It has [[Active]] Objects and [[Passive]] objects<br />
<br />
1.'''Active Objects''' are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br />
2.'''Passive Objects''' are the object which have no processes in them.<br />
<br />
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.<br />
<br />
Another important part of Cloud DOS are '''threads'''<br />
<br />
The [[threads]] are the logical path of execution that traverse objects and executes code in them. <br />
<br />
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.<br />
<br />
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.<br />
<br />
<br />
[[Interaction between '''Objects''' and '''Threads''']]<br />
1)Interobject interfaces are procedural<br />
2)Invocations work across machine boundaries<br />
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br />
4)Control flow achieved by threads invoking objects.<br />
<br />
[['''Cloud Environment''']]<br />
1) Integrates set of homogeneous machines into one seamless environment<br />
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.<br />
<br />
<br />
----<br />
[['''Plan 9''']]<br />
<br />
Plan 9 is a general purpose, multiuser and mobile computing environment physically distributed across machines. <br />
The Plan 9 began in late 1980s. The aims of this system are:<br />
1) To built a system that should be centrally administered <br />
2) Cost effective using cheap modern microcomputers. <br />
The distribution itself is transparent to most programs.<br />
This property is made possible by 2 properties:<br />
1) A per process group name space<br />
2) A uniform access to all the resources by representing them as a file.<br />
<br />
It is quite similar to the Unix yet so different. The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. The problems in UNIX were too deep to fix but still the various ideas were brought along.<br />
<br />
What actually distinguishes Plan 9 is its '''organization'''.<br />
<br />
Plan 9 is divided along the lines of service function. <br />
* CPU services and terminals use same kernel<br />
* Users may choose to run programs locally or remotely on CPU servers<br />
*Gives the user a choice to choose whether they want distributed or centralized.<br />
<br />
The design of Plan 9 is based on 3 principles:<br />
1) Resources are named and accessed like files in hierarchical file system.<br />
2) Standard protocol 9P<br />
3) Disjoint hierarchical provided by different services are joined together into single private hierarchal file name space.<br />
<br />
Another concept in Plan 9 is the '''Virtual Name Space'''<br />
In a [[Virtual Name Space]], a user boots a terminal or connects to a CPU server and then a new process group is created. <br />
Processes in group can either add to or rearrange their name space using two system calls- [[Mount]] and [[Bind]]<br />
* [[Mount]] is used to attach new file system to a point in name space.<br />
*[[Bind]] is used to attach a kernel resident file system to name space and also arrange pieces of name space.<br />
----</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19761DistOS 2015W Session 52015-02-03T03:18:03Z<p>Shivjot: </p>
<hr />
<div>'''[[Cloud Distributed Operating System]]'''<br />
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.<br />
The OS is based on 2 patterns:<br />
1. Message Based OS<br />
2. Object Based OS<br />
<br />
The structure of this is based on '''Object Thread Model.''' <br />
It has set of objects which are defined by the class. Objects respond to messages. <br />
Sending message to object causes object to execute the method and then reply back. <br />
<br />
It has [[Active]] Objects and [[Passive]] objects<br />
<br />
1.'''Active Objects''' are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br />
2.'''Passive Objects''' are the object which have no processes in them.<br />
<br />
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.<br />
<br />
Another important part of Cloud DOS are '''threads'''<br />
<br />
The [[threads]] are the logical path of execution that traverse objects and executes code in them. <br />
<br />
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.<br />
<br />
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.<br />
<br />
<br />
[[Interaction between '''Objects''' and '''Threads''']]<br />
1)Interobject interfaces are procedural<br />
2)Invocations work across machine boundaries<br />
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br />
4)Control flow achieved by threads invoking objects.<br />
<br />
[['''Cloud Environment''']]<br />
1) Integrates set of homogeneous machines into one seamless environment<br />
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.<br />
<br />
<br />
----<br />
[['''Plan 9''']]<br />
<br />
Plan 9 is a general purpose, multiuser and mobile computing environment physically distributed across machines. <br />
The Plan 9 began in late 1980s. <br />
The distribution itself is transparent to most programs.<br />
This property is made possible by 2 properties:<br />
1) A per process group name space<br />
2) A uniform access to all the resources by representing them as a file.<br />
<br />
It is quite similar to the Unix yet so different. The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. <br />
<br />
What actually distinguishes Plan 9 is its '''organization'''.<br />
<br />
Plan 9 is divided along the lines of service function. <br />
* CPU services and terminals use same kernel<br />
* Users may choose to run programs locally or remotely on CPU servers<br />
*Gives the user a choice to choose whether they want distributed or centralized.<br />
<br />
Another concept in Plan 9 is the '''Virtual Name Space'''<br />
In a [[Virtual Name Space]], a user boots a terminal or connects to a CPU server and then a new process group is created. <br />
Processes in group can either add to or rearrange their name space using two system calls- [[Mount]] and [[Bind]]<br />
* [[Mount]] is used to attach new file system to a point in name space.<br />
*[[Bind]] is used to attach a kernel resident file system to name space and also arrange pieces of name space.<br />
----</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19760DistOS 2015W Session 52015-02-03T02:45:06Z<p>Shivjot: Created page with "'''Cloud Distributed Operating System''' It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies differen..."</p>
<hr />
<div>'''[[Cloud Distributed Operating System]]'''<br />
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.<br />
The OS is based on 2 patterns:<br />
1. Message Based OS<br />
2. Object Based OS<br />
<br />
The structure of this is based on '''Object Thread Model.''' <br />
It has set of objects which are defined by the class. Objects respond to messages. <br />
Sending message to object causes object to execute the method and then reply back. <br />
<br />
It has [[Active]] Objects and [[Passive]] objects<br />
<br />
1.'''Active Objects''' are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br />
2.'''Passive Objects''' are the object which have no processes in them.<br />
<br />
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.<br />
<br />
Another important part of Cloud DOS are '''threads'''<br />
<br />
The [[threads]] are the logical path of execution that traverse objects and executes code in them. <br />
<br />
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.<br />
<br />
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.<br />
<br />
<br />
[[Interaction between '''Objects''' and '''Threads''']]<br />
1)Interobject interfaces are procedural<br />
2)Invocations work across machine boundaries<br />
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br />
4)Control flow achieved by threads invoking objects.<br />
<br />
[['''Cloud Environment''']]<br />
1) Integrates set of homogeneous machines into one seamless environment<br />
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19684DistOS 2015W Session 32015-01-20T03:48:58Z<p>Shivjot: </p>
<hr />
<div>'''Reading Response Discussion'''<br />
<br />
----<br />
'''Multics'''<br />
<br />
----<br />
<br />
Team: Sameer, Shivjot, Ambalica, Veena<br />
<br />
It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell and MIT but Bell backed out of the project in 1969.<br />
Multics is a time sharing OS which provides Multitasking and Multiprogramming. <br />
<br />
It provides following features:<br />
1. Utility Computing<br />
2. Access Control Lists<br />
3. Single level storage<br />
4. Dynamic linking<br />
5. Hot swapping<br />
<br />
It is not a Distributed OS but it a Centralized system which was written in the assembly language.</div>Shivjothttps://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19683DistOS 2015W Session 32015-01-20T03:48:27Z<p>Shivjot: Created page with "Reading Response Discussion ---- '''Multics''' ---- Team: Sameer, Shivjot, Ambalica, Veena It came into being in the 1960s and it completely vanished in 2000s. It was star..."</p>
<hr />
<div>Reading Response Discussion<br />
<br />
----<br />
'''Multics'''<br />
<br />
----<br />
<br />
Team: Sameer, Shivjot, Ambalica, Veena<br />
<br />
It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell and MIT but Bell backed out of the project in 1969.<br />
Multics is a time sharing OS which provides Multitasking and Multiprogramming. <br />
<br />
It provides following features:<br />
1. Utility Computing<br />
2. Access Control Lists<br />
3. Single level storage<br />
4. Dynamic linking<br />
5. Hot swapping<br />
<br />
It is not a Distributed OS but it a Centralized system which was written in the assembly language.</div>Shivjot