Soma-notes - User contributions [en]

DistOS 2015W Session 6

2015-02-09T21:45:21Z

Deepshree: /* Group 2 */

==Midterm==

The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].

==Group 1==

'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan

{| class="wikitable"
|-
!
! FARSITE
! OceanStore
|-
! Fault Tolerance
| Used Byzantine Fault Tolerance Algorithm - Did not manage well
| Used Byzantine Fault Tolerance Algorithm - Did not manage well
|-
! Cryptography
| Trusted Certificates
| A strong cryptographic algorithm on read-only operations
|-
! Implementation
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system
| Implemented in JAVA
|-
! Scalability
| Scalable to a University or large corporations, maximum 105
| Worldwide scalability, maximum 1010
|-
! File Usage
| Was designed for general purpose files
| Was designed for small file sizes
|-
! Scope
| All clients sharing the available resources
| Transient centralized service
|-
! Object Model
| Didn't use the object model
| Used the object model
|}

==Group 2==
Team Members: Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot

==Group 3== DANY, MOE, DEEP, SAMEER, TROY

'''FARSITE'''

'''Security'''
• Cascading certificates system through directory hierarchy
• Keys
• Three types of certificates
• CFS required to authorized certificate
• Because directory groups only modify their shared state via a Byzantine-fault-tolerant protocol, we trust the group not to make
an incorrect update to directory metadata. This metadata includes an access control list (ACL) of public keys of all users
who are authorized writers to that directory and to files in it
• Both file content and user-sensitive metadata (meaning file and directory names) are encrypted for privacy.

'''System Architecture'''
• Client Monitor, directory group, file host
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group.

'''OCEANSTORE'''

'''Security'''
• GUID and ACLs used for write, encryption used for reads.
• To prevent unauthorized reads, it encrypts
all data in the system that is not completely public and distributes the encryption key to those users with read permission

DistOS 2015W Session 6

2015-02-09T21:37:59Z

Deepshree: /* Group 3 */

==Midterm==

The midterm from last year [http://homeostasis.scs.carleton.ca/~soma/distos/2015w/comp4000-2014w-midterm.pdf is now available].

==Group 1==

'''Team:''' Kirill, Jamie, Alexis, Veena, Khaled, Hassan

{| class="wikitable"
|-
!
! FARSITE
! OceanStore
|-
! Fault Tolerance
| Used Byzantine Fault Tolerance Algorithm - Did not manage well
| Used Byzantine Fault Tolerance Algorithm - Did not manage well
|-
! Cryptography
| Trusted Certificates
| A strong cryptographic algorithm on read-only operations
|-
! Implementation
| Did not mention what programming they used, but it was based on Windows. They did not implement the file system
| Implemented in JAVA
|-
! Scalability
| Scalable to a University or large corporations, maximum 105
| Worldwide scalability, maximum 1010
|-
! File Usage
| Was designed for general purpose files
| Was designed for small file sizes
|-
! Scope
| All clients sharing the available resources
| Transient centralized service
|-
! Object Model
| Didn't use the object model
| Used the object model
|}

==Group 2==
Team Members: Apoorv, Ambalica, Ashley, Eric, Mert, Shivjot

==Group 3== DANY, MOE, DEEP, SAMEER, TROY

'''FARSITE'''

'''Security'''
• Cascading certificates system through directory hierarchy
• Keys
• Three types of certificates
• CFS required to authorized certificate

'''System Architecture'''
• Client Monitor, directory group, file host
• When space runs out in directory group, delegate’s ownership to sub tree to other delegate group.

'''OCEANSTORE'''

'''Security'''
• GUID and ACLs used for write, encryption used for reads.

DistOS 2015W Session 4

2015-01-27T18:26:07Z

Deepshree: Created page with "'''Amebo Operating System: Capablities''' • Pointer to the object • Capability assigning right to perform to some operation to the object ticket • Communicate wide ..."

'''Amebo Operating System: 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

'''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

Talk:DistOS 2015W Session 4

2015-01-27T18:25:28Z

DistOS 2015W Session 1

2015-01-06T17:45:49Z

Deepshree: Created page with "1st Lecture - January 5th 2015 COURSE OUTLINE Undergrad Grading Scheme: 15% Class Participation 15% Reading Responses 10% lecture Notes/Wiki Contributions 25% Midterm ..."

1st Lecture - January 5th 2015

COURSE OUTLINE

Undergrad Grading Scheme:
15% Class Participation
15% Reading Responses
10% lecture Notes/Wiki Contributions
25% Midterm
35% Final Exam

Grads Grading Scheme:
15% Class Participation
15% Reading Responses
10% Lectures Notes/Wiki contributions
10% Project Proposal
15% Project Presentation
35% Final Project

Project:
A literature review of Distributing operating
Research proposal on a problem related to DS

A large software system

Response: How you feel, What you Learned

LECTURES 1 : Discussion (What is Distributed System/OS)
Distributing System
- Sharing Resources
- Spreading Work Loads
- Scheduling
- Process migration
- Different nodes have different purpose
- Google
- Parallel running processes
- Nodes
- Resource Allocation across multiple nodes
- Scheduling multiple nodes
- Resources availability among nodes
- Problem: across multiple machine,
- Questions:

'''Group2:'''
- Request come from one or more computer and handles by many other computers
- Tasks are divided into small, which are dealt with then re-integrate
- Usually deal with large scale datasets
- Globalization
- Fault tolerant
- Usually emphasize distributed agents to not work on certain schedule

'''Group3''':
- Separated networked machine
- Coordinated with similar with similar identical software
○ Error recovery, redundancy
- No control storage
- Coordinated communication facilitating operation on coordinated task
- Leader/hierarchy for task delegation
○ Example: Map Reduce , cloud, cloud software(Google Drive)
'''Group4''':
- Distributed, multiple systems
- OS: The root level system that operates a computer system
- Dist. OS more complexity

'''Prof Discussion Notes:'''
'''Key words:'''
Network
Parallel
Full tolerant
Redundancy
Complexity

Distributing OS, is kind of OS

''' What is an OS?'''
○ Connection software and hardware
○ Recourses allocation
○ Abstraction
○ Transfer what you have and what you want to program on , Want to make it many computer you want to program on
○ Sharing: Recourse spilt up , OS turn the computer you want to program , some other computer may want other part of resources
○ Virtual memory, Process scheduling

'''What is Distributed System?'''
○ Run of one node but really on many nodes
○ Do the thing we take granted with regular computer
○ You want to program on computer - Cannot do many computer - lets you treat n computer as if its one numbers, expect you have 1000x resources
○ Opposite of OS
○ Resources can be divided as you want
○ Implement centralized control - problem solution
○ You cannot take many and make it one -> We fake it , in certain context, in certain environment
○ More specific task you try to do , the more it scale
○ Interact it, process update, callback,
○ Gmail so responsible - it perfected , downloads in your browser
○ Cache - they predict what the processor going to do

'''Systems''':
Mobile devices - Phones
IOS
Android

''' Embedded OS:'''
Linux, QNX, xBSD firewalls

'''Desktop''':
Windows
MacOS
Chrome OS

'''Server''':
Windows, Server
Linux
BSD

''' Main Frames:'''
OS/400

Cloud is n server? IMP Question

'''Cloud''':
MPI
AWS
Google App Engine

Is it OS?
No, it is a best porto OS , because of abstraction, you don’t know what in the background

'''Cloud''': quite OS, u do stuff in API

''' Group Discussion(2): BOINC - Pick a system == Similar to OS or function like OS'''

Similarity:
○ Lot of parallelization
○ Availability
○ Scheduling
○ Network
○ Connection leave and join whenever you want at idle time
○ Same problem at the same time
○ Redundancy
○ Allocation can be handle by system
○ Large problem managed by one system
○ Submit project
○ Fault tolerance
Different OS:
○ VERY VERY specific
○ Studying at home

Similarity BOINC:
○ Its networked
○ Takes arbitrary, parallelized problems and scale then
○ Allocates problem re
Differences:
○ Bad abstraction
○ Cant run centralized program

Group 2:
FaceBook
Pro:
○ Abstracts over human connection (makes it easier )
○ Has a programming API/platform
○ ? Able to separate resources such as wall posts, photos, etc
Cons:
○ Doesn't really take a single resources and spilt it up into smaller ones
○ APIs arents very stable
○ Not a lot of control

Group3:
Google Docs
Pro:
○ File System(resources management )
○ Hardware abstraction
○ API google script
Cons:
○ Is it really?

Group 4:
LinkedIn
Pro:
○ Supports multiple location/Users(Recourses)
○ Multiple servers around the worls
○ Recourses mgmt
○ Security Mgmt
○ Networked System
○ Consistency
○ Platform Free(Desktop/Mobile)
○ Specific Functionality(Not abstract)