1 / 27

Naming

Naming. File System & Naming Scheme. Computer System Engineering, Spring 2013. Naming Scheme. Address. Name of physical/virtual location Maps to physical location Used as a locator Leonardo da Vinci vs. Leonardo di Pisa Often compact set of integers

Télécharger la présentation

Naming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Naming File System & Naming Scheme Computer System Engineering, Spring 2013

  2. Naming Scheme

  3. Address • Name of physical/virtual location • Maps to physical location • Used as a locator • Leonardo da Vinci vs. Leonardo di Pisa • Often compact set of integers • Mostly address adjacency corresponds to physical adjacency (target of side-channel attack) • Arithmetic operation can be applied (array & pointer) • Telephone switching system is different

  4. Question

  5. Question • 2.1a: what is the name space of each? • 2.1b: order matters in Follow me • 2.1c: why Delegation?

  6. Address • Problem: Name fragility • Object moves, name changes • Decouple modules with indirection • Binds from externally visible but stable name to an address • Hide the addresses, so that it never be exposed above the layer which manipulates the objects directly • E.g., Com1 instead of 0x4D7C • Addresses are used to locate objects efficiently • Usually appears in low layers

  7. Dangling Reference • Result-1: An irrelevant value • Often happens in the limited name space cases • Make serious mistakes • Cause damage to the unrelated object • May be dealt by verify the name • Result-2: Not-found • Can happen in unlimited name spaces • Less disruptive • target name be removed while soft link exists • May be dangerous • Target name is used maliciously

  8. Lost Object • Object outlives every binding of a name • Orphan • Storage leak • Reference count scheme • Keep track of the number of bindings to each object • Reclaim the storage when the number becomes zero by unbinding • Garbage collection • Disk check, lost & found

  9. Uniform Resource Locator (URL) • Name discovery • Interpretation of the URL • Protocol, DNS, pathname • Partial URL and base element • URL case sensitive • Resolve a partial URL • Overloading of Names in URLs

  10. Name discovery • Hyperlink • <a href="http://web.pedantic.edu/Alice/www/home.html"> Alice’s home page</a> • Retrieve a page in the WWW • Many URLs can be found in hyperlinks on other Web pages • Most Web browser come with one or more built-in Web pages • See URL mentioned in a newspaper advertisement

  11. Interpretation of the URL http://web.pedantic.edu/Alice/www/home.html • http: • Name of a network protocol • Resolved to a protocol handler using a table-lookup context stored in the browser • Host name • web.pedantic.edu • Solved by DNS, returns IP address

  12. Interpretation of the URL • Browser • opens a connection to the server at the above IP address • Using the protocol • Sends the /Alice/www/home.html to the server as the 1st step of the protocol • Server looks for a file that has the above pathname • Server sends the file back to the client if successful • Client transforms the file into a page suitable for display • Partial URL and base element

  13. Interpretation of the URL • Partial URL • <a href="contacts.html">How to contact Alice.</a> • Relative URL • Browser tries to resolve the partial URL • Find a context which is the page in which the URL is found • http://web.pedantic.edu/Alice/www/contacts.html • Can be based on the base element • <base href="some absolute URL">

  14. URL case sensitive • Protocol part • Depends on browser implementation at the client side • Macintosh implementation of Firefox uses case-preserving • Obsolete Macintosh IE is case-coercing • Host name part • Interpreted by DNS which is case-insensitive • The rest part is interpreted by the server • Protocol dependent. In Http • not a unix file name but silent on case-sensitive • Usually treated as a path name

  15. Wrong Context References for a Partial URL • Server provides a URL name space by using the local file system name space • If the local file system provides synonyms, URL is not unique • 1 http://web.pedantic.edu/alice/home.html • 2 http://web.pedantic.edu/alice/www/home.html • <a href = "contacts.html"> • 1 http://web.pedantic.edu/alice/contacts.html • 2 http://web.pedantic.edu/alice/www/contacts.html

  16. Wrong Context References for a Partial URL • <a href=”../phone.html”> • 1 http://web.pedantic.edu/alice/../phone.html • 2 http://web.pedantic.edu/alice/www/../phone.html • Results • 1 http://web.pedantic.edu/phone.html • 2 http://web.pedantic.edu/alice/phone.html • Solutions • Arrange things so that the default context reference always works • Do a better job of choosing a default context reference • Provide an explicit context reference

  17. Overloading of Names in URLs • http://www.amazon.com/exec/obidos/ASIN/0670672262/o/qid=921285151/sr=2-2/002-7663546-7016232 • The server has encoded the state of the shopping session, in the form of an identifier of a state maintaining file at the server • http://www.google.com/search?hl=en&q=books+about+systems&btnG=Google+Search&aq=f&oq= • the string up to the question mark is the name of a program • the string after the question mark is an argument to be given to that program

  18. War Stories • Name Collision Eliminates Smiling Faces • A smiley face with “No picture available” • Smiley.jpg

  19. Client / Server

  20. Why enforced modularity? • Modularity itself is not enough • Programmers make mistakes • Mistakes propagate easily • A way to strengthen the modularity is needed

  21. Modularity in the code • Modularity in the code • E.g. hide CLOCK’s physical address • E.g. hide time unit • No need to change MEASURE on another computer, only change GET_TIME • … but not enough

  22. Soft modularity • Error leaks from one module to another • Function call • Stack discipline • Procedure calling convention

  23. Potential problems in calling - 1 • Errors in callee may corrupt the caller’s stack • The caller may later compute incorrect results or fails • Callee may return somewhere else by mistake • The caller may lose control completely and fail • Callee may not store return value in R0 • The caller may read error value and compute incorrectly • Caller may not save temp registers before the call • The callee may change the registers and causes the caller compute incorrectly

  24. Potential problems in calling - 2 • Callee may have disasters (e.g. divided by 0) • Caller may terminate too, known as fate sharing • Callee may change some global variable that it shouldn’t change • Caller and callee may compute incorrectly or fail altogether • Even other procedures may be affected • Procedure call contract provides only soft modularity • Attained through specifications • No way to force the interactions among modules to their defined interfaces

  25. Type-safe language • Using type-safe language (e.g. Java) • Can beef up to a certain extent • Programs can only write to memory in accordance with their type • Cannot overwrite arbitrary memory or corrupt the stack • Still insufficient for complete system • Not all modules are in type-safe language • Fate sharing (e.g. infinite loop)

  26. Sidebar: Why still using C? • From Jonathan Shapiro • The systems programmer requires an intuitive model of what is happening on the machine at the source code level • Kernel programmers already operate at (or slightly beyond) the outer limit of systemic complexity that can be maintained in a programmer’s head • Transparency gave way to abstraction, and then to opacity

  27. Enforced modularity is needed • Using external mechanism • Limits the interaction among modules • Reduces the opportunities for propagation of errors • Allows verification that a user uses a module correctly • Prevent an attacker from penetrating the security of a module

More Related