Soma-notes - User contributions [en]

DistOS 2015W Session 4

2015-04-28T05:38:23Z

Mohamedahmed: /* Capablities: */

= Andrew File System =
AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).

Since AFS copies files locally when they were opened and only sends the data back when they are closed, all operations between opening and closing the file are very fast and do not need to access the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.

There are several problems with this design, however:
* The local system must have enough space to temporarily store the file.
* Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).
* If the close operation fails, the system will not have the updated version of the file. Many programs are designed around local filesystems, and therefore don't even check the return value of the close operation (as this is unlikely to fail on a local FS), giving users the false impression that everything went well.

Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.

*Kerberos protocol
**authentication protocol using time based ticket
**single sign on system to authenticate and use other services
**AFS uses Kerberos for authentication, and implements access control lists on directories for users and groups.

= Amoeba Operating System =

The Ameoba research project with the goal at understanding how to connect multiple computers in a seamless way. The main goal of this was to build a distributed system that is transparent to the users. This was different from a network operating system where a user would be aware of the separate nodes it was accessing.

=== Capablities: ===
* Pointer to the object
* Capability assigning right to perform to some operation to the object ticket
* Communicate wide area network
* a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all)
* Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each
* After the server has performed the operation, it sends back a reply message that unblocks the client
* Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure
* Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed
* Generates 48-bit random number
* The third field is the right field which contains a bit map telling which operation the holder of the capability may performed
* X11 Window management

=== Thread Management: ===
* Same process have multiple thread and each process has its own registered counter and stack
* Behave like process
* It can synchronized using mutex semaphore
* File: Multiple thread,
* Blocked when there's multiple threads
* Buttlet thread the mutex
* The careful reader may have noticed that user process can pull 813kbytes/sec

= Unique features =

== Pool processors ==
Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.

== Supported architectures ==
Many different processor architectures are supported including:
* i80386 (Pentium)
* 68K
* SPARC

= The V Distributed System =

* First tent in V design: High Performance communication is the most critical facility for distributed systems.
* Second; The protocols, not the software, define the system.
* Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space & communication model.

=== Ideas that significantly affected the design ===
* Shared Memory.
* Dealing with group of entities same as they deal w/individual entities.
* Efficient file caching mechanism using the virtual memory caching mechanism.

=== Design Decisions ===
* Designed for a cluster of workstations with high speed network access ( only really supports LAN ).
* Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.

V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.

V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.

VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.

DistOS 2015W Session 3

2015-04-28T05:14:20Z

Mohamedahmed:

= Multics =

'''Team:''' Sameer, Shivjot, Ambalica, Veena

It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell, General Electric and MIT but Bell backed out of the project in 1969.
Multics is a time sharing OS which provides multitasking and multiprogramming. It is not a distributed OS but it a centralized system which was written in machine-specific assembly.

It provides the following features:
# Utility Computing
# Access Control Lists
# Single level storage
# Dynamic linking
#* Sharded libraries or files can be loaded and linked to Random Access Memory at run time
# Hot swapping
# Multiprocessing System
# Ring oriented Security
#* It provides number of levels of authorization within the computer system
#* Still present in some form today, inside both processors (like x86) and operating systems

= Unix =

* general purpose multi-user interactive operating system
* relatively inexpensive
* includes text editors, interpreters and compilers

Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially an OS that was optimized for the needs of programmers but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing. In fact, it didn't even have support for networking in the first version.

The C language was created specifically for Unix, as the creators wanted to create a machine-agnostic language for the operating system.

Most features from Unix are still available in present day Unix-based systems. For example, the shell, with its piping capabilities, is still used today in its original form.

= NFS =

NFS is a protocol for working with distributed file systems transparently using RPC. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas.

<blockquote>
Sun wanted to secure their NFS with encryption, but at the time encryption was regulated like munitions in the United States. Exporting any product that had encryption was impossible, but Sun needed those sales abroad. To avoid these regulations, Sun decided to sell the insecure NFS version of the system.
</blockquote>

'''Team''': Mert

*Sun used "open protocol" approach to develop NFS
** Simply specified the exact message formats that clients and servers would use to communicate.
** Different groups could develop their own NFS servers and thus compete in an NFS marketplace.
** ex. Sun, NetApp, EMC, IBM, etc.

*NFSv2, simple and fast server crash recovery
**Any minute that the server is down (or unavailable) makes all the clients unproductive.
**The protocol is designed to deliver in each protocol request all the information that is needed in order to complete the request.
**stateless approach: the server does not track anything about what clients are doing
**no fancy crash recovery is needed, the server just starts running again, and a client, at worst, might have to retry a request.

= Locus =

# Not scalable
#* The synchronization algorithms were so slow, they only managed to run it on five computers
#* Every computer stores a copy of every file
#* Also used CAS to manage files
# Not efficient with abstractions
#* Trying to distribute files and processes
#Allowed for process migration
#Transparency
#* It provided network transparency to “disguise” its distributed context.
#Dynamic reconfiguration. (It adapts topology changes.)

Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.

'''Team''': Eric

*LOCUS was capable of distribute file and processes among the nodes but not the computing power.

* distributed operating system which supports transparent access to data through a network wide filesystem
* upward compatible with Unix
* automatic replication of storage (backups), distributed process execution (cloud computing?)

= Sprite =

Mohamed

* OS for networked uniprocessor and multiprocessor workstations with large physical memories
*shared memory and processes between work stations
*The motivation for building a new operating system came from three general trends in computer technology: networks, large memories, and multiprocessors.

''' Team''': Jamie, Hassan, Khaled

Sprite had the following Design Features:
# Network Transparency
# Process Migration, file transfer between computers
#* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used by another user, the system would take care of the process migration to another machine
# Handling Cache Consistency
#* Sequential file sharing ==> By using a version number for each file
#* Concurrent write sharing ==> Disable cache to clients, enable write-blocking and other methods
# Implemented a caching system that sped up performance
# Implemented a log structured file system
#* They realized that with increasing amounts of RAM in computers which can be used for caching, writes to the disk were the main bottleneck, not reads.
#* Log structured file-systems are optimized for writes, as changes to previous data are appended at the current position.
#* This allows for very fast, sequential writes.
#* Example: SSD (Solid-state disks)

The main features to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performance.

= Sprite =

Mohamed
* transparent remote access to filesystems
* portable to other operating systems and machine architectures
* can add new file systems dynamically the same way that device drivers are added
* most flexible method of remote file access available then.

DistOS 2015W Session 3

2015-04-28T05:12:36Z

Mohamedahmed: /* Sprite */

DistOS 2015W Session 3

2015-04-28T04:31:28Z

Mohamedahmed: /* Locus */

= Multics =

'''Team:''' Sameer, Shivjot, Ambalica, Veena

It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell, General Electric and MIT but Bell backed out of the project in 1969.
Multics is a time sharing OS which provides multitasking and multiprogramming. It is not a distributed OS but it a centralized system which was written in machine-specific assembly.

It provides the following features:
# Utility Computing
# Access Control Lists
# Single level storage
# Dynamic linking
#* Sharded libraries or files can be loaded and linked to Random Access Memory at run time
# Hot swapping
# Multiprocessing System
# Ring oriented Security
#* It provides number of levels of authorization within the computer system
#* Still present in some form today, inside both processors (like x86) and operating systems

= Unix =

* general purpose multi-user interactive operating system
* relatively inexpensive
* includes text editors, interpreters and compilers

Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially an OS that was optimized for the needs of programmers but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing. In fact, it didn't even have support for networking in the first version.

The C language was created specifically for Unix, as the creators wanted to create a machine-agnostic language for the operating system.

Most features from Unix are still available in present day Unix-based systems. For example, the shell, with its piping capabilities, is still used today in its original form.

= NFS =

NFS is a protocol for working with distributed file systems transparently using RPC. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas.

<blockquote>
Sun wanted to secure their NFS with encryption, but at the time encryption was regulated like munitions in the United States. Exporting any product that had encryption was impossible, but Sun needed those sales abroad. To avoid these regulations, Sun decided to sell the insecure NFS version of the system.
</blockquote>

'''Team''': Mert

*Sun used "open protocol" approach to develop NFS
** Simply specified the exact message formats that clients and servers would use to communicate.
** Different groups could develop their own NFS servers and thus compete in an NFS marketplace.
** ex. Sun, NetApp, EMC, IBM, etc.

*NFSv2, simple and fast server crash recovery
**Any minute that the server is down (or unavailable) makes all the clients unproductive.
**The protocol is designed to deliver in each protocol request all the information that is needed in order to complete the request.
**stateless approach: the server does not track anything about what clients are doing
**no fancy crash recovery is needed, the server just starts running again, and a client, at worst, might have to retry a request.

= Locus =

# Not scalable
#* The synchronization algorithms were so slow, they only managed to run it on five computers
#* Every computer stores a copy of every file
#* Also used CAS to manage files
# Not efficient with abstractions
#* Trying to distribute files and processes
#Allowed for process migration
#Transparency
#* It provided network transparency to “disguise” its distributed context.
#Dynamic reconfiguration. (It adapts topology changes.)

Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.

'''Team''': Eric

*LOCUS was capable of distribute file and processes among the nodes but not the computing power.

* distributed operating system which supports transparent access to data through a network wide filesystem
* upward compatible with Unix
* automatic replication of storage (backups), distributed process execution (cloud computing?)

= Sprite =

''' Team''': Jamie, Hassan, Khaled

Sprite had the following Design Features:
# Network Transparency
# Process Migration, file transfer between computers
#* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used by another user, the system would take care of the process migration to another machine
# Handling Cache Consistency
#* Sequential file sharing ==> By using a version number for each file
#* Concurrent write sharing ==> Disable cache to clients, enable write-blocking and other methods
# Implemented a caching system that sped up performance
# Implemented a log structured file system
#* They realized that with increasing amounts of RAM in computers which can be used for caching, writes to the disk were the main bottleneck, not reads.
#* Log structured file-systems are optimized for writes, as changes to previous data are appended at the current position.
#* This allows for very fast, sequential writes.
#* Example: SSD (Solid-state disks)

The main features to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performance.

DistOS 2015W Session 3

2015-04-28T04:30:08Z

Mohamedahmed: /* Unix */

= Multics =

'''Team:''' Sameer, Shivjot, Ambalica, Veena

It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell, General Electric and MIT but Bell backed out of the project in 1969.
Multics is a time sharing OS which provides multitasking and multiprogramming. It is not a distributed OS but it a centralized system which was written in machine-specific assembly.

It provides the following features:
# Utility Computing
# Access Control Lists
# Single level storage
# Dynamic linking
#* Sharded libraries or files can be loaded and linked to Random Access Memory at run time
# Hot swapping
# Multiprocessing System
# Ring oriented Security
#* It provides number of levels of authorization within the computer system
#* Still present in some form today, inside both processors (like x86) and operating systems

= Unix =

* general purpose multi-user interactive operating system
* relatively inexpensive
* includes text editors, interpreters and compilers

Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially an OS that was optimized for the needs of programmers but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing. In fact, it didn't even have support for networking in the first version.

The C language was created specifically for Unix, as the creators wanted to create a machine-agnostic language for the operating system.

Most features from Unix are still available in present day Unix-based systems. For example, the shell, with its piping capabilities, is still used today in its original form.

= NFS =

NFS is a protocol for working with distributed file systems transparently using RPC. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas.

<blockquote>
Sun wanted to secure their NFS with encryption, but at the time encryption was regulated like munitions in the United States. Exporting any product that had encryption was impossible, but Sun needed those sales abroad. To avoid these regulations, Sun decided to sell the insecure NFS version of the system.
</blockquote>

'''Team''': Mert

*Sun used "open protocol" approach to develop NFS
** Simply specified the exact message formats that clients and servers would use to communicate.
** Different groups could develop their own NFS servers and thus compete in an NFS marketplace.
** ex. Sun, NetApp, EMC, IBM, etc.

*NFSv2, simple and fast server crash recovery
**Any minute that the server is down (or unavailable) makes all the clients unproductive.
**The protocol is designed to deliver in each protocol request all the information that is needed in order to complete the request.
**stateless approach: the server does not track anything about what clients are doing
**no fancy crash recovery is needed, the server just starts running again, and a client, at worst, might have to retry a request.

= Locus =

# Not scalable
#* The synchronization algorithms were so slow, they only managed to run it on five computers
#* Every computer stores a copy of every file
#* Also used CAS to manage files
# Not efficient with abstractions
#* Trying to distribute files and processes
#Allowed for process migration
#Transparency
#* It provided network transparency to “disguise” its distributed context.
#Dynamic reconfiguration. (It adapts topology changes.)

Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.

'''Team''': Eric

*LOCUS was capable of distribute file and processes among the nodes but not the computing power.

= Sprite =

''' Team''': Jamie, Hassan, Khaled

Sprite had the following Design Features:
# Network Transparency
# Process Migration, file transfer between computers
#* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used by another user, the system would take care of the process migration to another machine
# Handling Cache Consistency
#* Sequential file sharing ==> By using a version number for each file
#* Concurrent write sharing ==> Disable cache to clients, enable write-blocking and other methods
# Implemented a caching system that sped up performance
# Implemented a log structured file system
#* They realized that with increasing amounts of RAM in computers which can be used for caching, writes to the disk were the main bottleneck, not reads.
#* Log structured file-systems are optimized for writes, as changes to previous data are appended at the current position.
#* This allows for very fast, sequential writes.
#* Example: SSD (Solid-state disks)

The main features to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performance.

DistOS 2015W Session 10

2015-03-16T19:28:01Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* '''Why are DHTs relevant to distributed OSs?'''
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* '''How is content divided?'''
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* '''How is the network traversed?'''
** Highest prefix and increase the number of digit it used to get close to the target nodes

* '''What trust assumptions does the system make?'''
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets
*** Binary tree with each node having k-buckets as leaf
*** Any given k-node is very unlikely to fail within an hour of each other
*** New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* '''Performance constraints?'''
** Binary tree traversing, therefore traversing is maximum O(log n)

* '''What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?'''
** DNS
** Any kind of meta-data service

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?
One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?
Assumes clients re untrusted autonomous nodes.

A client node running Comet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Comet for this purpose?

==Tapestry==
Members: Ashley, Dany, Alexis

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:27:16Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* '''Why are DHTs relevant to distributed OSs?'''
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* '''How is content divided?'''
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* '''How is the network traversed?'''
** Highest prefix and increase the number of digit it used to get close to the target nodes

* '''What trust assumptions does the system make?'''
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets
*** Binary tree with each node having k-buckets as leaf
*** Any given k-node is very unlikely to fail within an hour of each other
*** New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* '''Performance constraints?'''
** Binary tree traversing, therefore traversing is maximum O(log n)

* '''What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?'''
** DNS
** Any kind of meta-data service

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?
One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?
Assumes clients re untrusted autonomous nodes.

A client node running Comet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Comet for this purpose?
Video streaming like Netflix, possible

==Tapestry==
Members: Ashley, Dany, Alexis

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:18:18Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* '''Why are DHTs relevant to distributed OSs?'''
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* '''How is content divided?'''
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* '''How is the network traversed?'''
** Highest prefix and increase the number of digit it used to get close to the target nodes

* '''What trust assumptions does the system make?'''
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets
*** Binary tree with each node having k-buckets as leaf
*** Any given k-node is very unlikely to fail within an hour of each other
*** New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* '''Performance constraints?'''
** Binary tree traversing, therefore traversing is maximum O(log n)

* '''What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?'''
** DNS
** Any kind of meta-data service

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?
One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?
A client node running Comet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Comet for this purpose?
Video streaming like Netflix, possible

==Tapestry==
Members: Ashley, Dany, Alexis

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:15:24Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* '''Why are DHTs relevant to distributed OSs?'''
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* '''How is content divided?'''
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* '''How is the network traversed?'''
** Highest prefix and increase the number of digit it used to get close to the target nodes

* '''What trust assumptions does the system make?'''
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets
*** Binary tree with each node having k-buckets as leaf
*** Any given k-node is very unlikely to fail within an hour of each other
*** New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* '''Performance constraints?'''
** Binary tree traversing, therefore traversing is maximum O(log n)

* '''What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?'''
** DNS
** Any kind of meta-data service

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?
One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?
A client node running Comet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Tapestry==
Members:

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:14:59Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* '''Why are DHTs relevant to distributed OSs?'''
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* '''How is content divided?'''
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* '''How is the network traversed?'''
** Highest prefix and increase the number of digit it used to get close to the target nodes

* '''What trust assumptions does the system make?'''
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets
*** Binary tree with each node having k-buckets as leaf
*** Any given k-node is very unlikely to fail within an hour of each other
*** New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* '''Performance constraints?'''
** Binary tree traversing, therefore traversing is maximum O(log n)

* '''What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?'''
** DNS
** Any kind of meta-data service

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?
One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?
A client node running C0met should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Tapestry==
Members:

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:14:12Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* '''Why are DHTs relevant to distributed OSs?'''
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* '''How is content divided?'''
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* '''How is the network traversed?'''
** Highest prefix and increase the number of digit it used to get close to the target nodes

* '''What trust assumptions does the system make?'''
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets
*** Binary tree with each node having k-buckets as leaf
*** Any given k-node is very unlikely to fail within an hour of each other
*** New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* '''Performance constraints?'''
** Binary tree traversing, therefore traversing is maximum O(log n)

* '''What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?'''
** DNS
** Any kind of meta-data service

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?
One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?
A client node running COmet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Tapestry==
Members:

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:13:19Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* Why are DHTs relevant to distributed OSs?
** Using many system, having repetition
** DHT to distributed content over multiple nodes
** Decentralized therefore peer-to-peer

* How is content divided?
** File hashes
** Node ID to locate the value
** 160 bit key space, binary tree for partition and searching down the tree

* How is the network traversed?
** Highest prefix and increase the number of digit it used to get close to the target nodes

* What trust assumptions does the system make?
** DHT by itself is insecure
** The academic and practitioner communities have realized that all current DHT designs suffer from a security weakness, known as the Sybil attack
** K-buckets: binary tree with each node having k-buckets as leaf. Any given k-node is very unlikely to fail within an hour of each other. New nodes are only inserted when there is room in the bucket or the oldest node doesn't respond
** Uses UDP therefore packets are often lost

* Performance constraints?
** Binary tree traversing, therefore traversing is maximum O(log n)

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?

One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?

A client node running COmet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes.

Users downloading Comet must trust it and have guarantees about its behavior. For this reason, Comet enforces four important restrictions:
1. Limited knowledge: an ASO is not aware of other objects
or resources stored on the same node and has no
direct way to learn about them.
2. Limited access: an object handler can manipulate only its own value and cannot modify the values of other objects on its storage node.
3. Limited communication: an active storage object cannot
send arbitrary messages over the network.
4. Limited resource consumption: an ASO’s resource usage is strictly bounded, e.g., the system limits the amount of computation and memory it can consume.

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Tapestry==
Members:

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

Uses consistent hashing (SHA-1), upon node creation (join) creates optimal routing table.

* How is the network traversed?

You look at your neighbours, you see which neighbour is closest to your destination, and recurse.

* What trust assumptions does the system make?

It assumes the system is entirely trustworthy from adversaries. While network failures may happen and nodes may go down, no node will explicitly try to mess with the network.

* Performance constraints?

O(log n) access times to any given node. Best effort publishing/unpublishing via decentralized object location routing.

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:10:35Z

Mohamedahmed: /* Comet */

Feel free to tweak the questions!

==Kademlia==
Members: Kirill, Deep, Jason, Hassan

* Why are DHTs relevant to distributed OSs?

* How is content divided?

* How is the network traversed?

* What trust assumptions does the system make?

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Comet==
Members: Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

* Why are DHTs relevant to distributed OSs?
DHT is an infrastructure than enables many clients to share information, and scale to handle node arrival, departure and failure. DHT's serve many of the design goals of disbtributed operating systems. The paper states that "DHTs are increasingly used to support a variety of distributed applications, such as file-sharing, distributed resource tracking, end-system multicast, publish-subscribe systems, distributed search engines"

* How is content divided?

One of the three main components of the comet system is a routing substrate which
implements the value/node mapping. This allows a client to find the node htat stores
a specific data item. Since Comet uses a DHT implementation, routing occurs by applying
a hash function to the key to compute node ID's that store the associated value.

* How is the network traversed?

* What trust assumptions does the system make?

A client node running COmet should be protected from the execution of handlers
e.g. an executing handler cannot corrupt the node or use unlimited resources.
Handlers should not be able to mount messaging attacks on other nodes

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Kademlia for this purpose?

==Tapestry==
Members:

* Why are DHTs relevant to distributed OSs?

Because they provide a way to distribute information over large networks (distributed key/value store).

* How is content divided?

* How is the network traversed?

* What trust assumptions does the system make?

* Performance constraints?

* What non-DHT internet infrastructure would you replace with a DHT? How suitable is Tapestry for this purpose?

DistOS 2015W Session 10

2015-03-16T19:09:48Z

Mohamedahmed:

DistOS 2015W Session 10

2015-03-16T18:45:43Z

Mohamedahmed: Created page with "Group 2 - Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma == Comet =="

Group 2 - Mohamed Ahmed, Apoorv Sangal, Ambalica Sharma

== Comet ==