Naming

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