Transcript INF_123_Lecture_10x

INF 123
SW ARCH, DIST SYS & INTEROP
LECTURE 10
Prof. Crista Lopes
Objectives

Understanding of external data representations
 why
 well-known
ones
Distributed System


No shared memory
Different processors may represent data differently
 “endianness”:
little endian, big endian
Component
Component
n
1
Component
Component
n
1
Component
Component
n
1
Network OS
Network
OS
Hardware
Network
OS
Hardware
Hardware
Host 3
Host 2
Host 1
…
Network
Endianness

Big endian

Little endian
Coping


IP defines a standard byte order (big endian)
Standard socket implementations provide converters
 htonl,
htons (host to network – 32 and 16 bits)
 ntohl, htohs (network to host – 32 and 16 bits)

Problem solved by standardization at this level
Binary vs. text data

Choice in protocol design:
 number
132: 1000 0100
 text “132”: 0011 0001 0011 0011 0011 0010

Tradeoff: compactness vs. readability
 What

would HTTP look like in binary???
Many above-transport protocols choose latter
Next: payload data
struct Folder {
UUID parentID;
UUID owner;
short type;
short version;
string name;
UUID id;
}
?
too many options!
obj
host 1
host 2
Well-known data representations


eXternal Data Representation – XDR (IETF 1995)
eXtensible Markup Language – XML (W3C 2008)
 long

history, back to 60’s
JavaScript Object Notation – JSON (IETF 2006)
XDR



Binary data (i.e. hard to parse for humans)
Defines several basic data types
Does not include type information with data
 receiver
is assumed to know what types are being sent
XDR example
const MAXUSERNAME = 32; /* max length of a user name */
const MAXFILELEN = 65535; /* max length of a file
*/
const MAXNAMELEN = 255; /* max length of a file name */
/*
* Types of files:
*/
enum filekind {
TEXT = 0,
/* ascii data */
DATA = 1,
/* raw data */
EXEC = 2
/* executable */
};
/*
* File information, per kind of file:
*/
union filetype switch (filekind kind) {
case TEXT:
void;
/* no extra information */
case DATA:
string creator<MAXNAMELEN>; /* data creator /
case EXEC:
string interpretor<MAXNAMELEN>; /* interpreter */
};
Data to be transmitted
/*
* A complete file:
*/
struct file {
/* name of file */
string filename<MAXNAMELEN>;
/* info about file */
filetype type;
/* owner of file */
string owner<MAXUSERNAME>;
/* file data
*/
opaque data<MAXFILELEN>;
};
XDR example
OFFSET
-----0
4
8
12
16
20
24
28
32
36
40
44
HEX BYTES
--------00 00 00 09
73 69 6c 6c
79 70 72 6f
67 00 00 00
00 00 00 02
00 00 00 04
6c 69 73 70
00 00 00 04
6a 6f 68 6e
00 00 00 06
28 71 75 69
74 29 00 00
ASCII
----....
sill
ypro
g...
....
....
lisp
....
john
....
(qui
t)..
COMMENTS
--------- length of filename = 9
-- filename characters
-- ... and more characters
-- ... and 3 zero-bytes of
-- filekind is EXEC = 2
-- length of interpretor =
-- interpretor characters
-- length of owner = 4
-- owner characters
-- length of file data = 6
-- file data bytes ...
-- ... and 2 zero-bytes of
...
fill
4
fill
XML




Textual data (i.e. humans can easily parse it)
User-defined data
No predefined types, just syntax
Includes type information with data
 Receiver
is assumed to know what types mean
XML example
<?xml version="1.0" encoding='UTF-8'?>
Markup
<bookstore>
…
Tag (start)
XML Declaration
Attribute
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
…
<price>30.00</price>
</book>
Tag (end)
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
</bookstore>
Content
Element
XML Namespaces (XMLNS)


Used to disambiguate tags
Not used by parser – info for humans
<root>
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Apples</h:td>
<h:td>Bananas</h:td>
</h:tr>
</h:table>
go here and
see what’s there
<f:table xmlns:f="http://www.w3schools.com/furniture">
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
</root>
XSL and XSLT

eXtensible Stylesheet Language
eXtensible Stylesheet Language Transformations

Markups for browsers – how to display XML data

 most
browsers support this
 usually irrelevant for non-browser clients

Example
JSON






Same spirit as XML, more concise and much simpler
Textual data (i.e. humans can easily parse it)
Syntactically-valid JavaScript – object literals
User-defined data
Some predefined types
Includes type information with data
JSON simple syntax







object: {} | {members}
members: pair | pair, members
pair: name : value
name: string
array: [] | [elements]
elements: value | value , elements
value: string | number | object | array |
true | false | null
JSON example
{
object
array
object
object
"Success":true,
"Items":
[
{
"Version":12,
"ChildCount":12,
"ID":"cbee00bb-1f26-414a-a0aa-9c5a7156fe64",
"ParentID":"00000000-0000-0000-0000-000000000000",
"OwnerID":"9ffd5a95-b8bd-4d91-bbed-ded4c80ba151",
"Name":"Library",
"ContentType":"application/vnd.ll.folder”,
"CreationDate":1261042614,
"Type":"Folder"
},{
"Version":0,
"ChildCount":0,
"ID":"a2bd28c4-9243-418f-887d-4aa219b0046e",
"ParentID":"cbee00bb-1f26-414a-a0aa-9c5a7156fe64",
"OwnerID":"9ffd5a95-b8bd-4d91-bbed-ded4c80ba151",
"Name":"Animations",
"ContentType":"application/vnd.ll.animation”,
"CreationDate":1261042614,
"Type":"Folder"
}
]
}
JSON in JavaScript
object literal, i.e. textual representation
var myJSONObject = {"bindings": [
{"ircEvent": "PRIVMSG", "method": "newURI", "regex": "^http://.*"},
{"ircEvent": "PRIVMSG", "method": "deleteURI", "regex": "^delete.*"},
{"ircEvent": "PRIVMSG", "method": "randomURI", "regex": "^random.*"}
]
};
myJSONObject.bindings[0].method // "newURI”
var myObject = eval('(' + myJSONtext + ')');
actual object
var myJSONText = JSON.stringify(myObject);
back to literal
Summary

Understanding of external data representations
 why
– because heterogeneity happens and we want to
interoperate
 well-known ones – XDR, XML and JSON
bits  ASCII  syntax  semantics

btw, all of this applies to files too!