Lez. 91 Reti di Calcolatori XDR - eXternal Data Representation Vedi: SunSoft, Network Interfaces...

Lez. 9 1

Reti di Calcolatori

XDR - eXternal Data Representation

Vedi:

• SunSoft, Network Interfaces Programmer's Guide, app. A e B, pagg. 291-352.

• RFC 1014, External Data Representation Standard, 1987.• RFC 1057, RPC: Remote Procedure Call Protocol Specification –

Version 2, 1988.

Copyright © 2006-2012 by Claudio Salati.

Alma Mater Studiorum - Universita' di BolognaSede di Cesena

II Facolta' di Ingegneria

2

• XDR is a standard for the description and encoding of information.

• Description Abstract Syntax, equivalente di ASN.1 OSI

• Encoding Transfer Syntax, equivalente di BER OSI

• Quindi XDR definisce

Sia una notazione per la definizione di sintassi astratte (ASN)

• cioe’ una notazione per la definizione delle strutture informative scambiate tra i moduli di una applicazioni distribuita

• cioe’ una notazione per la definizione di protocolli applicativi

Sia un sintassi di trasferimento capace di codificare in una sequenza di byte le strutture informative definite utilizzando la notazione astratta XDR

• la rappresentazione concreta di rete puo’ quindi essere trasmessa al pari e da questo decodificata

Che cosa e'?

3

• Definito da Sun, vedi

• RFC 1014, External Data Representation Standard, 1987.

• Utilizzato da Sun

• per la definizione dell’ASE Sun RPC: vedi

RFC 1057, RPC: Remote Procedure Call Protocol Specification – Version 2, 1988.

• per la definizione dell’ASE Sun NFS (Network File System): vedi

RFC 1094, NFS: Network File System Protocol Specification, 1989.

(poi aggiornato fino a RFC 3530, Network File System (NFS) version 4 Protocol, 2003)

Riferimenti

4

• In quanto ASN, XDR definisce un linguaggio per descrivere delle strutture informative.

• N.B.

• Il linguaggio serve solo per descrivere strutture dati (informazioni), non per definire operazioni (istruzioni): non e' un linguaggio di programmazione.

• L'alternativa di utilizzare mappe di byte, se si devono definire protocolli complessi, diventa velocemente impraticabile.

• Anche l’alternativa di definire protocolli tramite stringhe di caratteri non e’ felice (vedi SMTP e HTTP).

• XDR, in quanto sintassi di trasferimento, si basa sulle seguenti ipotesi:

• I byte (gli ottetti) sono portabili e costituiti di una sequenza di 8 bit

(hp.: ordine dei bit nel byte uniforme su tutte le macchine).

• I byte sono scambiati in modo comprensibile tra nodi della rete.

Che cosa e'?

5

• La sintassi di trasferimento definita da XDR non e' di tipo TLV.

• L'informazione di tipo non e' mai trasportata esplicitamente.

Cio' implica che il ricevente deve conoscere a priori il tipo della struttura informativa che sta ricevendo

(come accade ad esempio anche per i protocolli IP, TCP e UDP!).

• L'informazione di lunghezza e' trasportata esplicitamente solo quando cio’ e‘ necessario.

• Per rendere possibile tutto cio' si evitano campi opzionali o default e strutture dati disordinate (presenti in ASN.1).

• Campi opzionali sono comunque possibili utilizzando il costruttore union e il tipo void.

• E’ evidente che e’ sempre possibile fare finta che una struttura dati ordinata (e.g. un array) rappresenti un valore di tipo non-ordinato (e.g. un insieme) .

XDR TRANSFER SYNTAX .1

6

• La sintassi di trasferimento e' descritta attraverso mappe di byte.

• Ogni encodifica ha lunghezza multipla di 4 byte.

• Se una encodifica non e' fisiologicamente di lunghezza multipla di 4, XDR prescrive che essa venga paddata a destra con dei byte nulli.

• Il padding con un valore ben definito consente il confronto corretto di informazioni tramite confronto tra i byte corrispondenti delle loro rappresentazioni.

+--------+--------+...+--------+--------+...+--------+ | byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | BLOCK +--------+--------+...+--------+--------+...+--------+ |<-----------n bytes---------->|<------r bytes------>| |<-----------n+r (where (n+r) mod 4 = 0)>----------->|


7

• L'approccio XDR si basa sulla definizione di una rappresentazione canonica (di rete) per ogni tipo di dato da trasmettere.

• Ad esempio:

• Viene definito un ordinamento canonico dei byte (big-endian).

• Viene definita una rappresentazione canonica per i numeri interi (quella binaria, complemento a due).

• Viene definita una rappresentazione canonica dei numeri reali (quella IEEE).

• . . .

• In questa maniera qualunque trasmettitore che utilizza XDR puo' inviare una stessa informazione a qualunque ricevitore XDR trasmettendo la stessa stringa di byte.

• Esiste un caso in cui questo modo di procedere e' inefficiente:

• quando sia il trasmettitore che il ricevitore sono little-endian.


8

• Non e’ specificata da XDR

CORBA specifica invece la rappresentazione locale dell’informazione in C++ per il suo IDL

• Specificata dal singolo sistema di programmazione XDR, e.g. rpcgen di Sun per C:

• Specifico sistema di programmazione XDR-C

• Specifico sistema di programmazione XDR-Java

• Specifico sistema di programmazione XDR-. . .

• Definisce le strutture dati locali (specifiche dell’ambiente di programmazione) tramite le quali i tipi di dato XDR sono (devono essere) rappresentati concretamente in un modulo del programma distribuito

Rappresentazione concreta locale dell’informazione

9

• Tipi semplici:

• [unsigned] int e hyper int

• float, double e quadruple

• enum (enumerazioni, e in particolare bool)

• opaque

• string

• void

• Tipi composti:

• array

• struct

• union

Tipi di dato XDR

10

• Il tipo int implementa (sintassi astratta) la nozione di intero con segno nel range -2.147.483.648 .. 2.147.483.647.

• La rappresentazione canonica (sintassi di trasferimento) di un int e' • In notazione complemento a due.• Su 4 byte.• Big-endian.

• Una variabile di tipo int e' dichiarata come in C:

int identifier;

• Il tipo unsigned int implementa (sintassi astratta) la nozione di intero senza segno nel range 0 .. 4.294.967.295.

• La rappresentazione canonica (sintassi di trasferimento) di un valore di tipo unsigned int e' • In notazione binaria.• Su 4 byte.• Big-endian.

• Una variabile di tipo unsigned int e' dichiarata come in C:

unsigned int identifier;

Tipi XDR semplici: int e unsigned int

11

• XDR definisce anche tipi interi (con e senza segno) con range di valori piu’ esteso e che sono rappresentabili su 8 byte, chiamandoli [unsigned] hyper int.

• La rappresentazione canonica di un [unsigned] hyper int e' l'ovvia estensione di quella del corrispondente tipo intero

• In notazione complemento a due o binaria a seconda che l'intero sia con o senza segno.

• Su 8 byte.

• Big-endian.

• Una variabile di tipo [unsigned] hyper int e' dichiarata come in C:

hyper int identifier;

unsigned hyper int identifier;

N.B.: XDR non definisce interi con sizeof di 1 o 2 byte!

Tipi XDR semplici: hyper int e unsigned hyper int

13

• Sono definiti due tipi che rappresentano sottoinsiemi di numeri reali, basati sulle seguenti sintassi di trasferimento:

• float, basato sulla rappresentazione IEEE a 32 bit.

• double, basato sulla rappresentazione IEEE a 64 bit.

• quadruple, basato sulla rappresentazione IEEE double extended precision.

• Una variabile di tipo reale e' dichiarata come in C, e.g.:

float identifier;

double identifier;

• Notare che le notazioni IEEE per i numeri floating-point consentono anche di esprimere i seguenti "valori":• infinito con segno (overflow)• numero denormalizzato (underflow)• NaN (not a number), che pero' e' definito come system dependent

e non puo' quindi essere utilizzato tra sistemi diversi.

Tipi XDR semplici: float e double

14

• E' possibile definire enumerazioni di valori simbolici.

• Sintassi astratta:

• Le enumerazioni rappresentano effettivamente sottoinsiemi di numeri interi con segno (int), e ogni valore simbolico dell'enumerazione e' associato ad un valore intero univoco.

• Una variabile di tipo enumerato (enum) e' definita nel modo seguente (come in C):

enum { symbolName = constant, . . . } identifier;

• Esempio:

enum { RED = 2, BLUE = 3, GREEN = 5 } colours;

La variabile colours puo' assumere solo uno dei valori interi listati nell'enumerazione.

• Sintassi di trasferimento: la rappresentazione canonica (o encodifica) di un valore enumerato e' identica a quella di un intero con segno.

Tipi XDR semplici: enumerati

15

• Un particolare tipo di enumerazione e' rappresentato dal tipo booleano (bool).


• Il tipo booleano ammette due soli valori: FALSE e TRUE.

• Una variabile di tipo bool e' definita nel modo seguente:

bool identifier;

• Questa definizione e' equivalente alla seguente

enum { FALSE = 0, TRUE = 1 } identifier;

• Sintassi di trasferimento:

• La rappresentazione canonica di un valore booleano e' identica a quella di un enumerato (un booleano e’ uno specifico enumerato) e quindi a quella di un intero con segno.

• N.B.: la rappresentazione canonica di rete XDR di un bool e’ diversa dalla rappresentazione concreta locale C di un booleano.

Tipi XDR semplici: booleani

16

• A volte due programmi devono scambiarsi dei dati (byte) non-interpretati.

• Si e' gia' visto come questo sia tipico delle architetture di comunicazione layerizzate (l’n+1PDU, cioe’ l’nSDU, e’ un dato non interpretato per il layer n, e quindi compare come tale nell’nPDU) .

• In ASN.1 questo tipo di dati e' rappresentato attraverso il metatipo ANY o attraverso il tipo EXTERNAL.


• Questo tipo di dati in XDR e' chiamato opaco (opaque), ed e' costituito da una sequenza ordinata di byte.

• XDR consente di definire sia dati opachi di lunghezza fissa che dati opachi di lunghezza variabile.

• Una variabile che rappresenta un dato opaco di lunghezza fissa n (byte) e' definita nel modo seguente:

opaque identifier [ n ]; // lunghezza fissa

Tipi XDR semplici: dati opachi .1

17

• Sintassi astratta (continua):

• Una variabile che rappresenta un dato opaco di lunghezza indefinita e' definito nel modo seguente:

opaque identifier < n >; // di lunghezza // indefinita ma // limitata a n

o

opaque identifier < >; // di lunghezza // indefinita // (limitata a 232-1)

• Nel primo caso n rappresenta la dimensione massima (upper bound della lunghezza) del dato opaco.

• Anche nel secondo caso il dato opaco ha comunque una dimensione massima, pari a 232-1.

• Ogni istanza (valore) di questo tipo ha comunque lunghezza definita.


18


• L'encodifica di un dato opaco di lunghezza fissa n e' costituita dalla sequenza degli n ottetti (byte).

• Se n non e' multiplo di 4 la sequenza di ottetti e' paddata con un epilogo di allineamento di byte nulli di lunghezza 0..3.

• L'encodifica di un dato opaco di lunghezza variabile e' costituita di due parti:

• dall'encodifica dell'intero senza segno (4 byte) che ne indica la lunghezza (non paddata),

secondo le regole di encodifica XDR del tipo unsigned int,

• seguita dalla sequenza di ottetti non interpretati, eventualmente paddata con byte nulli.


19


0 1 ... +--------+--------+...+--------+--------+...+--------+ | byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | +--------+--------+...+--------+--------+...+--------+ |<-----------n bytes---------->|<------r bytes------>| |<-----------n+r (where (n+r) mod 4 = 0)------------>| FIXED-LENGTH OPAQUE

0 1 2 3 4 5 ... +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ | length n |byte0|byte1|...| n-1 | 0 |...| 0 | +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+ |<-------4 bytes------->|<------n bytes------>|<---r bytes--->| |<----n+r (where (n+r) mod 4 = 0)---->| VARIABLE-LENGTH OPAQUE

20

• E' possibile definire stringhe di caratteri ASCII di lunghezza indefinita (tipo string).

• Queste stringhe non sono null-terminated come in C

(ma, naturalmente, se le stringhe utilizzate nel programma sono quelle normali del C, non conterranno alcun carattere '\0'):

la loro lunghezza dovra’ quindi essere indicata esplicitamente.

• Una variabile che rappresenta una stringa di caratteri ASCII e' definita in uno dei modi seguenti (sintassi astratta):

string identifier < n >; // di lunghezza indefinita

// ma limitata a n

string identifier < >; // di lunghezza indefinita

// (limitata a 232-1)

Tipi XDR semplici: stringhe di caratteri ASCII

22

• E' possibile definire vettori omogenei di qualunque tipo di elementi, sia di lunghezza definita che di lunghezza indefinita. Il tipo degli elementi del vettore puo' essere sia semplice che composto.

• Anche se tutti gli elementi del vettore sono dello stesso tipo, non necessariamente devono avere la medesima dimensione (e.g., vettori di stringhe ASCII di lunghezza indefinita)

• Una variabile che rappresenta un vettore e' definita in uno dei modi seguenti (sintassi astratta):

base-type identifier [n]; // lunghezza fissa

base-type identifier <n>; // lunghezza indefinita

// ma limitata a n

base-type identifier < >; // lunghezza indefinita

// (limitata a 232-1)

Tipi XDR composti: array

24

• Una variabile che rappresenta una struttura (struct, sequenza ordinata eterogenea di componenti, semplici o composti) e' dichiarata nel modo seguente (sintassi astratta):

struct {

component-declaration-1;

component-declaration-2;

. . .

} identifier;

dove ogni component-declaration assume la forma di una dichiarazione di variabile.


• L'encodifica di una struttura e' formata dalla sequenza delle encodifiche dei suoi componenti, nello stesso ordine in cui essi compaiono nella dichiarazione.

• L'encodifica di ogni componente e' di lunghezza multipla di 4 byte, ma diversi componenti possono ovviamente avere diversa lunghezza.

Tipi XDR composti: strutture (record)

25

• La variabile punto1 rappresenta un punto del piano attraverso le sue coordinate cartesiane:

struct {

double x; double y;

} punto1;

• La variabile punto2 rappresenta un punto del piano attraverso le sue coordinate polari:

struct {

double ro; double teta;

} punto2;

• La variabile complex1 rappresenta un numero complesso attraverso il valore delle sue parti reale e immaginaria:

struct {

double re; double im;

} complex1;

Tipi XDR composti: esempi di struttura (record)

26

• Esercizio 1: Quale e’ la sintassi di trasferimento di valori di questi tipi/variabili?

• Esercizio 2: E’ possibile distinguere tra loro sintassi di trasferimento di questi diversi tipi?

• Esercizio 3: E’ possibile distinguere la sintassi di trasferimento di questi tipi da quella di un array di double di lunghezza fissa di 2 elementi?

Tipi XDR composti: esercizi

27

• Una unione discriminata (union) e' un tipo composto da • un campo discriminante • seguito da un secondo campo di un tipo scelto tra un insieme

predefinito di possibilita'• in base al valore del campo discriminante.

• Il tipo del campo discriminante deve essere int, unsigned int o un enumerato (compreso bool).

• Ogni opzione relativa al secondo campo, detta arm, e' preceduta dal valore del discriminante che la seleziona.

• Una variabile che rappresenta una unione discriminata e' dichiarata nel modo seguente:

union switch (discriminant-decl) { case discriminant-value-1 : arm-declaration-1; case discriminant-value-2 : arm-declaration-2; . . . default : default-arm-decl;} identifier;

Tipi XDR composti: unioni discriminate .1

28

• La keyword case e' seguita da un valore legale del discriminante.

• La dichiarazione del discriminante e degli arm ha la forma di una dichiarazione di variabile.

• L'arm default e' opzionale: esso e’ significativo quando il valore del discriminante e’ diverso da quello che identifica gli altri arm.

• Se l'arm default non e' presente, il campo discriminante di un valore legale deve avere uno dei valori listati come selettori degli arm.


• L'encodifica di una unione discriminata e' formata dalla sequenza della encodifica del discriminante e di quella dell'arm selezionato dal valore del discriminante.

• L'encodifica di ogni arm e quella del discriminante sono di lunghezza multipla di 4 byte, ma diversi arm possono ovviamente avere diversa lunghezza.

Tipi XDR composti: unioni discriminate .2

29

• La variabile saldoContabile fornisce il valore del saldo del conto corrente in diverse valute:

union switch (int valuta) { case 0 : double euro; case 1 : double dollar; case 2 : double yen; default : struct { string valuta<>; double ammontare; } altraValuta; } saldoContabile;

• Esercizio: definire saldoContabile utilizzando un enumerato come campo discriminante.

• Esercizio: quale e’ la rappresentazione canonica (sintassi di trasferimento) del valore della variabile saldoContabile?

• Se saldoContabile vale 5 euro?

• Se saldoContabile vale 5 dollari?

• Se saldoContabile vale 5 lire sterline?

Tipi XDR composti: esempio di unione discriminata

31

• XDR supporta una notazione per indicare assenza di un valore.

• L'assenza di un valore e' indicata dal tipo void, che ha un range di valori ammessi vuoto.

• Il tipo void e' utile per specificare funzioni che non hanno alcun parametro in ingresso o che non ritornano alcun risultato (nelle RPC, come in C standard).

• void puo' essere anche usato in una unione discriminata per indicare la non disponibilita' di un valore significativo come secondo campo, o per estendere il range di un altro tipo con il valore "non-definito".

• La dichiarazione di un void ha la seguente forma:

void;

• L'encodifica (sintassi di trasferimento) di un void e' nulla (0 byte).

Tipi XDR semplici: void

32

• La variabile saldoContabile fornisce il valore in euro del saldo del conto corrente se il dato e' disponibile:

union switch (bool disponibile) { case TRUE : double euro; case FALSE : void;} saldoContabile;

• Esercizio: quale e’ la rappresentazione canonica (sintassi di trasferimento) della variabile se il saldo non e’ disponibile?

• Esercizio: ci sono altri tipi XDR oltre a void la cui sintassi di trasferimento e’ nulla (ha cioe’ lunghezza 0 byte)?

Tipi XDR semplici: esempio d'uso di void

33

• ASN.1 definisce una notazione per specificare non solo tipi di dati ma anche i relativi valori.

• XDR non fornisce strumenti per esprimere valori a livello di sintassi astratta!

• In XDR e’ possibile esprimere dei valori solo in termini di sintassi di trasferimento.

Notare che una volta noto a priori il tipo del valore ricevuto, la lunghezza della sua codifica e’ anch’essa

• o nota a priori

• o indicata esplicitamente nella sintassi di trasferimento.

• Meglio: a livello di sintassi astratta XDR offre possibilita’ molto limitate per esprimere valori.

XDR value notation e costanti simboliche

34

• A livello di sintassi astratta l’unica sintassi dei valori prevista consente di esprimere solo numeri interi.

• E’ anche possibile assegnare un nome simbolico ad un valore intero attraverso la seguente dichiarazione

const constant-identifier = n;

// n e’ la sintassi dei valori XDR per gli interi,

// e.g. 5

Dove n deve essere un numero (literal) intero (eventualmente con segno) espresso in notazione decimale.

• Una costante simbolica puo’ essere utilizzata in un testo XDR ovunque potrebbe essere utilizzato il corrispondente valore numerico (e.g. dimensione di vettore o valore discriminante in un arm)

const dozzina = 12;

uomo quella_sporca[dozzina];

XDR value notation e costanti simboliche

35

• Si e’ parlato di come dichiarare variabili in XDR, ma in effetti la dichiarazione di variabili in XDR non ha alcun significato!

XDR serve per definire una interfaccia (il protocollo tra due pari) e, come negli header file C, in un file di interfaccia non ha senso definire delle variabili, ma solo dei tipi!

(btw, attenzione alla distinzione in C tra dichiarazione e definizione!)

E tanto piu’ in quanto due processi remoti non possono condividere variabili!

(in realta’ nei sistemi distribuiti per l’automazione industriale …)

Caso mai interesserebbe avere a disposizione una adeguata sintassi dei valori.

• Lo statement typedef, del tutto analogo a quello del C, anche dal punto di vista della sintassi, consente di associare un identificatore ad una definizione di tipo.

Definizione di tipi utente: typedef

36

• Considerando la definizione

typedef declaration;

(dove declaration ha la sintassi di una dichiarazione di variabile)

essa associa al tipo descritto nella declaration l’identificatore dichiarato nella declaration stessa.

• typedef egg eggbox[6]; // esempio 1

definisce eggbox come sinonimo di un vettore di 6 egg.

• eggbox non e’ in alcun modo distinguibile da qualunque altro vettore di 6 egg.

• typedef struct { // esempio 2 double x; double y;} punto;

N.B.: dal punto di vista della sintassi di trasferimento un eggbox non e’ nemmeno distinguibile da una struct composta da 6 egg.


37

• Nella definizione di tipi

• struct

• union

• enum

esiste una sintassi alternativa all’uso di typedef, analoga a quella utilizzata per la definizione dei nomi-tag del C.

• In questo caso pero’, non c’e’ alcuna differenza semantica tra un nome-tag e un nome-typedef.

• Le due seguenti definizioni di tipo sono quindi completamente analoghe:

typedef enum { FALSE = 0, TRUE = 1 } bool;

enum bool { FALSE = 0, TRUE = 1 };

• La seconda sintassi e’ pero’ considerata preferibile (tradizione).


38

• Optional-data is one kind of union that occurs so frequently that we give it a special syntax of its own for declaring it. It is declared as follows:

type-name *identifier;

• This is equivalent to the following union:

union switch (bool opted) {

case TRUE: type-name element;

case FALSE: void;

} identifier;

• It is also equivalent to the following variable-length array declaration, since the boolean opted can be interpreted as the length of the array (le due encodifiche sono indistinguibili!):

type-name identifier<1>;

Dati opzionali .1

39

• Optional-data is not so interesting in itself, but it is very useful for describing recursive data-structures such as linked-lists and trees.

• For example, the following defines a type stringlist that encodes lists of arbitrary length strings:

struct *stringlist {

string item<>;

stringlist next;

};

• The optional-data type also has a close correlation to how recursive data structures are represented in languages such as C by use of pointers.

• In fact, the syntax is the same as that of the C language for pointers.

Dati opzionali .2

40

• stringlist could have been equivalently declared as the following union:

union stringlist switch (bool opted) { case TRUE: struct { string item<>; stringlist next; } element; case FALSE: void;};

or as a variable-length array:

struct stringlist<1> {

string item<>;

stringlist next;

};

Dati opzionali .3

41

• Anche se dal punto di vista della sintassi di trasferimento puo’ non esserci differenza tra l’uso di strutture dati ricorsive e quello di dati opzionali, dal punto di vista della rappresentazione concreta una grossa differenza c’e’.

• L’uso di dati opzionali, come indicato anche dalla notazione sintattica, si traduce in strutture dati locali linkate.

• Utilizzando dati opzionali e’ possibile rappresentare in XDR e trasferire sulla rete strutture dati come liste linkate, alberi, grafi.

Dati opzionali .4

42

7.2

Applicazioni distribuite RPC-based

RPC-basedspecific

application protocol

RPC protocol entity

Transport Service

User application

RPC-basedspecific

application protocol

RPC protocol entity

Transport Service

User applicationRPC

Layer 7

7.1 RPC protocol

43

• Esempi di protocolli specifici RPC-based:

• RFC 1094: NFS (Network File System)

• NIS / YP

• RFC 1057: Port Mapper

• RPC protocol:

• Binding (collegamento) dell’interfaccia remota

• Implementazione delle istruzioni di “call” e “return”

• RPC-based specific application protocol:

• Binding dell’interfaccia remota (tramite RPC protocol entity)

• Binding della singola procedura remota

• Un/marshaling dei parametri di input/output della singola procedura remota

• Invocazione della procedura remota

• XDR e’ utilizzato per definire sia il protocollo RPC che i singoli protocolli applicativi specifici RPC-based.

Applicazioni distribuite RPC-based

44

struct rpc_msg { unsigned int xid; // transaction identifier union switch (msg_type mtype) { case CALL: call_body cbody; case REPLY: reply_body rbody; } body;};

• The xid of a REPLY message always matches that of the initiating CALL message.

• NB: The xid field is only used for clients matching reply messages with call messages or for servers detecting retransmissions;

• the service side (il chiamato) cannot treat this id as any type of sequence number.

enum msg_type { CALL = 0, REPLY = 1};

Protocollo Sun RPC versione 2 (RFC 1057) .1

45

struct call_body { unsigned int rpcvers; // must be ==2 unsigned int prog; // binding info unsigned int vers; // binding info unsigned int proc; // binding info opaque_auth cred; // authen. info opaque_auth verf; // authen. info // procedure specific parameters start here};

• Cosa significa “start here”?

• “Qui” l’rpc_msg e’ finito! “Qui” e’ “alla fine dell’rpc_msg”!

• A questo punto e’ chiaro che un “messaggio di chiamata di RPC” e’ in realta’ composto di 2 parti:

• Un rpc_msg

• Il parametro di ingresso in forma encodificata

• Discorso analogo varra’ ovviamente anche per il “messaggio di ritorno da RPC”.


46

• Il call_body sarebbe stato definito meglio come

struct call_body { unsigned int rpcvers; // must be ==2 unsigned int prog; // binding info unsigned int vers; // binding info unsigned int proc; // binding info opaque_auth cred; // authen. info opaque_auth verf; // authen. info opaque arg<>; // input parameter

};

• I parametri di ingresso della procedura sarebbero cioe’ descritti meglio come

opaque arg<>;

• In questo modo il “messaggio di chiamata di RPC” coinciderebbe con l’rpc_msg.

• Esercizio: Si’, ma cosa significa implementativamente “start here” dal punto di vista dell’interazione chiamante-chiamato?

Protocollo Sun RPC versione 2 (RFC 1057) .2’

47

• Perche’ questa strana definizione del “messaggio di chiamata di RPC” e dell’rpc_msg? Per ragioni di efficienza (siamo negli anni ‘80 dello scorso secolo

e i byte e il tempo di calcolo sono sono ancora preziosi). La definizione “opaque arg<>;” implica che vengano

trasmessi in rete (e processati) comunque almeno 4 byte (perche’?) anche se il parametro di ingresso dell’RPC e’ assente.

Non solo: la definizione “opaque arg<>;” avrebbe implicato in ricezione una doppia decodifica del campo parametro, con una ricopiatura e conseguente necessita’ di allocazione di memoria (Esercizio: spiegare cosa succederebbe).

Tutto cio’ e’ evitato dalla definizione del parametro di ingresso come semplice place holder.

• Almeno, si sarebbe potuto scrivere, come in reply_body,

opaque arg[0];

(questa notazione evita i problemi di cui sopra, ma rimane comunque solo un place holder)

Protocollo Sun RPC versione 2 (RFC 1057) .2’’

48

enum auth_flavor { AUTH_NULL = 0, AUTH_UNIX = 1, AUTH_SHORT = 2, AUTH_DES = 3 /* and more to be defined */};

struct opaque_auth { auth_flavor flavor; opaque body<400>;};

Protocollo Sun RPC versione 2 (RFC 1057) .2’’’

49

union reply_body switch (reply_stat stat) {

case MSG_ACCEPTED: accepted_reply areply;

case MSG_DENIED: rejected_reply rreply;

} reply;

enum reply_stat {

MSG_ACCEPTED = 0,

MSG_DENIED = 1

};

union rejected_reply switch (reject_stat stat) {

case RPC_MISMATCH:

struct { unsigned int low; unsigned int high; } mismatch_info;

case AUTH_ERROR: auth_stat stat;

};


50

enum reject_stat {

RPC_MISMATCH = 0, // RPC version number != 2

AUTH_ERROR = 1 // can't authenticate caller

};

enum auth_stat {

AUTH_BADCRED = 1, // bad credentials (seal broken)

AUTH_REJECTEDCRED = 2, // client must begin new session

AUTH_BADVERF = 3, // bad verifier (seal broken)

AUTH_REJECTEDVERF = 4, // verifier expired or replayed

AUTH_TOOWEAK = 5 // rejected for security reasons

};


51

struct accepted_reply {

opaque_auth verf;

union switch (accept_stat stat) {

case SUCCESS: opaque results[0];

// proc-specific results start here

// (N.B. “qui” e’ la fine dell’rpc_msg)

case PROG_MISMATCH:

struct { unsigned int low; unsigned int high; } mismatch_info;

default: void;

// Void. Cases include PROG_UNAVAIL, // PROC_UNAVAIL, and GARBAGE_ARGS.

} reply_data;

};


52

enum accept_stat { SUCCESS = 0, /* RPC executed successfully */ PROG_UNAVAIL = 1, /* remote hasn't exported program */ PROG_MISMATCH = 2, /* remote can't support version # */ PROC_UNAVAIL = 3, /* program can't support procedure */ GARBAGE_ARGS = 4 /* procedure can't decode params */ };

Protocollo Sun RPC versione 2 (RFC 1057) .5'

53

• XDR definisce:

• Un linguaggio per specificare sintassi astratte.

• Una sintassi di trasferimento.

• XDR non definisce:

• Una sintassi dei valori.

• Una regola per la rappresentazione concreta locale (e.g. in linguaggio C) di una sintassi astratta.

• Piu’ in generale, XDR non definisce alcuna API standard che consenta di accedere alla funzionalita’ di syntax matching.

• N.B.:• Corba IDL definisce una API standard (cioe’ anche la rappresentazione

concreta locale dell’informazione e’ standardizzata) ma non una sintassi dei valori

• ASN.1 non definisce una API standard ma definisce una sintassi dei valori

• In XML Schema sintassi dei valori e sintassi di trasferimento coincidono

Rappresentazione concreta locale e supporti XDR

54

• Esistono diversi sistemi di programmazione XDR:• XDR-C• XDR-Java

• Sistema di programmazione “standard” XDR-C:

• Una libreria di base: XDR library • per la de/codifica dei tipi base e dei costruttori di tipo e • per l’accesso a strutture dati di de/serializzazione.

• Un compilatore (rpcgen, orientato al linguaggio C) per generare automaticamente le procedure di de/codifica per una qualunque sintassi astratta user defined specificata in XDR. basato sull’uso della libreria di base.

• Un sistemi di programmazione XDR-C definisce le rappresentazioni concrete C dei tipi base e dei costruttori di tipo definiti da XDR.

• Perche’ sarebbe importante la standardizzazione della rappresentazione concreta locale?Perche’ consentirebbe la portabilita’ dell’applicazione tra diversi sistemi di programmazione XDR per uno stesso linguaggio target.

Rappresentazione concreta locale e supporti XDR

55

• The XDR library enables you to write and read arbitrary C constructs consistently.

• The XDR library can do this because it has filter routines for strings (null-terminated arrays of bytes), structures, unions, and arrays.

• Using more primitive routines, you can write your own specific XDR routines to describe arbitrary data structures, including elements of arrays, arms of unions, or objects pointed at from other structures. The structures themselves may contain arrays of arbitrary elements, or pointers to other structures.

Ma in realta’ le procedure di de/codifica per i tipi user defined di una sintassi astratta sono generate dal compilatore rpcgen.

Il supporto XDR di base: la XDR library

56

La XDR library si compone di due parti:

• Un insieme di funzioni filtro per eseguire la

• codifica fra un valore tipizzato in rappresentazione concreta locale C e lo stesso valore in rappresentazione canonica di rete XDR

• decodifica fra un valore tipizzato in rappresentazione canonica di rete XDR e lo stesso valore in rappresentazione concreta locale C

N.B.: le funzioni filtro si occupano anche della deallocazione di memoria dinamica utilizzata nelle rappresentazioni locali

per tutti i tipi primitivi e i costruttori di tipo definiti dal linguaggio XDR.

• Un insieme di funzioni per manipolare degli XDR stream, cioe' delle strutture dati di interfaccia verso strutture di memoria o di I/O a stream di byte da cui leggere o su cui scrivere i dati serializzati in formato canonico di rete XDR.

Il supporto XDR di base: la XDR library

57

XDRstream, funzioni filtro, de/codifica

encodifica

Rappresentazione concreta locale

dell’informazione

decodifica

XDR streamFunzioni

filtro

58

XDRstream in memoria centrale

XDR stream

buffer

len

len

pos

Partedel

buffer gia’

utilizzata

pos

x_op

59

• La maggior parte delle funzioni filtro della libreria, e tutte le funzioni di filtro eventualmente aggiunte, offrono uno stesso tipo di interfaccia.

• Se il tipo XDR ha nome xxx, la relativa funzione filtro ha il seguente prototipo:

#define bool_t int#define TRUE 1#define FALSE 0

bool_t xdr_xxx(XDR *xdrs, xxx *xp);

Dove• xdrs e' un puntatore ad uno XDR stream, e• xp e' un puntatore ad una variabile che contiene o e' destinata a

contenere la rappresentazione locale di un valore di tipo xxx.• La funzione ritorna FALSE in caso di fallimento, TRUE in caso di

successo.

• Le funzioni filtro sono direction-independent, la stessa funzione e' cioe' utilizzata sia per serializzare che per deserializzare un dato ( il secondo parametro deve essere un puntatore ad una variabile!)

La XDR library: funzioni di filtro

60

• XDR definisce il seguente tipo puntatore a funzione filtro standard:

typedef bool_t (*xdrproc_t)(XDR *xdrs,

void *localRep);

• Questo tipo e' utilizzato ad esempio per definire una funzione generica di liberazione di memoria, basata sulle regole di utilizzo della memoria dinamica da parte delle rappresentazioni locali dei tipi XDR:

void xdr_free(xdrproc_t proc, char *objp);

• The first argument is the XDR filter routine for the object being freed.

• The second argument is a pointer to the object itself.

• Note: if a pointer is passed to this routine the pointer is not freed, but what it points to is freed (recursively, depending on the XDR routine).

• Non e’ la variabile *objp che viene liberata dalla chiamata a xdr_free(), ma tutte le variabili (assunte dinamiche) riferite direttamente o indirettamente da *objp.

La XDR library: funzioni di filtro

61

• Il funzionamento della funzione xdr_free() e’ basato sui seguenti fatti/ipotesi:

• Una funzione filtro si occupa, oltre che di encodifica e decodifica, anche della liberazione di memoria della rappresentazione concreta locale di un valore XDR.

• La politica di dis/allocazione della memoria da parte del programma utente deve essere ben disciplinata, e le regole per farlo sono specificate dal sistema di programmazione XDR (vedi seguito).

• La funzione xdr_free() assume che tutti gli oggetti riferiti direttamente o indirettamente da *objp siano stati allocati dinamicamente (tramite funzione malloc()).

• E’ il programmatore che quando utilizza la funzione xdr_free() deve garantire che questo sia vero.

Allocazione e liberazione della memoria

62

• The first parameter, xdrs, is an XDR stream handle.

• The second parameter is the address of the number that provides data to the stream or receives data from it.

• All routines return TRUE if they complete successfully, and FALSE otherwise (N.B.: alcune funzioni non sono “in eccesso”?).

bool_t xdr_hyper(XDR *xdrs, longlong_t *hp);bool_t xdr_u_hyper(XDR *xdrs, u_longlong_t *uhp);bool_t xdr_int(XDR *xdrs, int *ip);bool_t xdr_u_int(XDR *xdrs, unsigned *up);bool_t xdr_long(XDR *xdrs, long *lip);bool_t xdr_u_long(XDR *xdrs, u_long *lup);bool_t xdr_longlong_t(XDR *xdrs, longlong_t *hp);bool_t xdr_u_longlong_t(XDR *xdrs, u_long *uhp);bool_t xdr_short(XDR *xdrs, short *sip);bool_t xdr_u_short(XDR *xdrs, u_short *sup); bool_t xdr_char(XDR *xdrs, char *cp);bool_t xdr_u_char(XDR *xdrs, unsigned char *ucp);

La XDR library: funzioni di filtro sugli interi C

63

• Basandosi sulle funzioni filtro della libreria di base e' possibile scrivere le funzioni filtro per le proprie strutture dati.

• Supponiamo che nel nostro programma C sia definita la struttura dati

struct gnumbers { // tipedef C int g_assets; int g_liabilities; };

• Questa corrisponderebbe al tipo XDR gnumbers, ma questo e’ irrilevante se non per il fatto che abbiamo deciso di encodificare la struttura dati C nello stesso modo in cui sarebbe encodificato il tipo XDR.

struct gnumbers { // definizione XDR int g_assets; int g_liabilities; };

• La funzione filtro del tipo gnumbers dovrebbe quindi essere definita cosi':

bool_t xdr_gnumbers(XDR *xdrs, struct gnumbers *gp) { return(xdr_int(xdrs, &gp->g_assets) &&

xdr_int(xdrs, &gp->g_liabilities)? TRUE : FALSE);}

La XDR library: funzioni filtro user defined

64

In realta’ e’ il sistema di programmazione XDR-C rpcgen che, a partire dalla definizione del tipo XDR

struct gnumbers { int g_assets; int g_liabilities; };

genera automaticamente:

• La rappresentazione concreta locale da utilizzare per rappresentare valori di questo tipo XDR

typedef struct gnumbers { int g_assets; int g_liabilities; } gnumbers;

• La funzione filtro del tipo gnumbers:

bool_t xdr_gnumbers(XDR *xdrs,

gnumbers *gp);

La XDR library: funzioni di filtro generate dal sistema

65

• Il significato dei parametri di input/output e' analogo a quello delle funzioni filtro per i numeri interi.

bool_t xdr_float(XDR *xdrs, float *cp);

bool_t xdr_double(XDR *xdrs, double *ucp);

La XDR library: funzioni di filtro sui reali C

66

• Il tipo C float viene mappato sul tipo XDR float.

• Il tipo C double viene mappato sul tipo XDR double.

• Per i tipi interi il mappaggio tipo C tipo (sintassi astratta di trasferimento) XDR e' il seguente:

La XDR library: rappresentazione concreta

Tipo C Tipo XDR

char, short, int int

u_char, u_short, u_int unsigned int

long int

u_long unsigned int

longlong hyper int

u_longlong unsigned hyper int

N.B.: char, short, long, longlong (e i corrispondenti tipi unsigned) non sono propriamente tipi XDR, ma sono comunque supportati dal sitema di programmazione XDR-C della Sun.

67

• La XDR library mette a disposizione una funzione filtro generica per tutti i tipi enumerati.

• Il tipo booleano e' un caso particolarmente rilevante di enumerato. Per esso e’ definita una funzione filtro ad hoc.

• Sia la funzione filtro generica che quella specifica per i booleani assumono che la rappresentazione concreta C di un enum XDR sia identica alla rappresentazione concreta C di un int XDR, cioe' un int C.

#define bool_t int // concrete local syntax#define FALSE 0#define TRUE 1

#define enum_t int // concrete local syntax

bool_t xdr_enum(XDR *xdrs, enum_t *ep);

bool_t xdr_bool(XDR *xdrs, bool_t *bp);

La XDR library: funzioni di filtro su enumerati (e bool)

68

• Implementare la funzione filtro xdr_bool().

bool_t xdr_bool(XDR *xdrs, bool_t *bp) { return xdr_enum(xdrs, (enum_t *) bp);}

• Ma in realta’ si puo’ fare di meglio perche’ noi sappiamo quali sono tutti e soli i valori ammissibili per l’enumerato bool (o per qualunque altro enumerato usere defined).

bool_t xdr_bool(XDR *xdrs, bool_t *bp) { bool_t b; b = xdr_enum(xdrs, (enum_t *) bp); if(!b) return FALSE; switch (*bp) {

case TRUE: case FALSE: return TRUE; default: return FALSE;}

La XDR library: esercizio (enumerati e bool)

69

• Occasionally, an XDR routine must be supplied to the RPC system, even when no data is passed or required.

• The following routine does this:

bool_t xdr_void(void); /* always returns TRUE */

• Esercizio: implementare la funzione xdr_void().

La XDR library: Possibility of No Data

70

• In C, una stringa di caratteri e' rappresentata tramite una sequenza di caratteri ASCII terminata da un carattere '\0', che non e' considerato parte della stringa ma solo la sua marca di terminazione.

Quando si vuole elaborare una stringa o passarla come parametro, quello che si considera e' in realta' un puntatore alla (all'indirizzo della) stringa (NULL-terminata), e non la stringa stessa.

• Di conseguenza la XDR library considera che la rappresentazione concreta locale C di una string<> XDR sia un puntatore alla stringa, e non la sequenza dei caratteri contenuti nella stringa.

• Si assume anche che la stringa non contenga alcun carattere '\0'.

• La rappresentazione locale C del tipo XDR string<> e' inadeguata a rappresentare tutti i possibili valori del tipo XDR.

• Un caso analogo (duale) si era gia' presentato anche per gli interi: la XDR library fornisce funzioni filtro anche per char, short, long e longlong C (e per i corrispondenti tipi unsigned), anche se questi tipi non corrispondono ad alcun tipo XDR.

La XDR library: stringhe ASCII .1

71

La XDR library: stringhe ASCII .1’

stringVar

. . .

‘\0’

Rappresentazione concreta locale di una stringa di caratteri secondo rpcgen:

72

• Le rappresentazioni interna ed esterna di una stringa sono diverse.

• Esternamente (sintassi di trasferimento XDR) le stringhe sono rappresentate come sequenze di caratteri ASCII.

• Internamente esse sono rappresentate tramite puntatori.

• La funzione filtro xdr_string() converte tra queste due rappresentazioni.

bool_t xdr_string(XDR *xdrs,

char **sp, u_int maxlength);

• Il parametro sp e' un puntatore ad una stringa, e quindi e' di tipo char ** (un puntatore a un puntatore ad array di caratteri).

• Il parametro maxlength specifica il numero massimo di caratteri che possono essere contenuti nella stringa (e’ ovviamente ignorato nell’operazione di serializzazione).

• La funzione ritorna FALSE se il numero di caratteri eccede maxlength, altrimenti ritorna TRUE.


73

• L'operazione di deserializzazione ha il seguente comportamento:

• Per prima cosa si verifica che la lunghezza della stringa ricevuta non ecceda maxlength.

• Quindi si dereferenzia sp: • Se *sp==NULL, allora viene allocata una stringa della

lunghezza appropriata e *sp e' fatto puntare a questa stringa. • Se *sp!=NULL, allora XDR assume che l'area di memoria

destinata a contenere la rappresentazione locale della stringa sia gia' stata allocata (quest'area deve poter contenere una stringa di lunghezza massima maxlength).

• In ogni caso, la stringa XDR e' decodificata nell'area target (l'area in cui e’ registrato il contenuto della stringa nella rappresentazione locale) e le viene suffissato il carattere '\0'.

• Nel caso dell’operazione XDR_FREE, si dereferenzia sp. • Se *sp!=NULL, allora XDR disalloca l'area di memoria di indirizzo

*sp e setta *sp a NULL (il valore maxlength e' ignorato). • Se *sp==NULL, non si fa nulla.


74

La XDR library: deserializzazione di una stringa ASCII

xdr_string(xdrs, stringVar, maxlength);

Il filtro in decodifica alloca una variaile dinamica di dimensione tale da contenere esattamente la stringa ricevuta piu’ il carattere di terminazione ‘\0’.

stringVar NULLprima

stringVar

. . .

‘\0’

dopo

allocato dinamicamente

75

La XDR library: deserializzazione di una stringa ASCII

xdr_string(xdrs, stringVar, maxlength);

Il filtro in decodifica utilizza (per quello che gli serve) il buffer ricevuto dal chiamante, che assume essere di dimensione >= maxlength+1.

prima

dopo stringVar

. . .

‘\0’ maxlength+1

stringVar

. . .maxlength+1

76

• La funzione filtro xdr_string() e' generica e applicabile a stringhe di qualunque lunghezza.

• Essa pero' non e' conforme al prototipo standard delle funzioni filtro: Ha un parametro in piu', maxlength, lunghezza massima della

stringa.

• Nel momento in cui definisco un tipo XDR stringa specifico, ne definisco comunque una dimensione massima (alla peggio, quella di default).

• Posso quindi associare al tipo stringa XDR specifico una funzione filtro con prototipo standard, implementata tramite l'invocazione della funzione filtro generica.

typedef string filename<255>;

bool_t xdr_filename(XDR *xdrs, char **sp,) {

return(xdr_string(xdrs, sp, 255));

}

• Lo stesso ragionamento si applica anche a stringhe definite direttamente in C.


77

La XDR library: disallocazione di una stringa ASCII

stringVar

. . .

‘\0’

xdr_free(xdr_filename, &stringVar)

•Si assume che il buffer riferito da stringVar sia stato allocato dinamicamente.

•La variabile stringVar non viene liberata, e’ solo il buffer riferito da lei che viene liberato.

•Se si volesse disallocare la variabile stringVar (se fosse dinamica) bisognerebbe chiamare direttamente la funzione free() del C (cosi’ come, in questo caso, era stata chiamata la funzione malloc() del C per allocarla).

Si presuppone allocato dinamicamente.E’ la parte disallocata della rappresentazione concreta locale.

78

• La XDR library fornisce un funzione filtro (xdr_array()) per trattare in modo generico array

• di qualunque tipo di elementi, e• di dimensione (numero di elementi) indefinita

(ovvio che ogni singolo array ha tipo e numero di elementi ben definiti).

• Questa funzione richiede i seguenti parametri:• Il puntatore ad un array (ap), che si assume rappresentato

concretamente come un puntatore alla sequenza dei suoi elementi.• Il puntatore alla variabile che indica la lunghezza (numero di elementi)

effettiva dell'array (lp) .• Il numero massimo di elementi che possono essere contenuti

nell'array.• La dimensione in byte della rappresentazione concreta locale di un

elemento dell'array, che e' (deve essere) uguale per tutti gli elementi!

(Ad esempio, una stringa di lunghezza variabile e' rappresentata tramite un puntatore, cosi’ che le rappresentazioni locali di tutte le stringhe hanno uguali dimensioni!)

• Il puntatore alla funzione filtro relativa al tipo degli elementi dell'array.

La XDR library: array di lunghezza variabile .1

79

typedef bool_t (*xdrproc_t)(XDR *xdrs,

void *localRep);

bool_t xdr_array(XDR *xdrs,

char **ap, // rif. ad array

u_int *lp, // lung. effett.

u_int maxlength, // lung. max

u_int elementsize,

xdrproc_t xdr_element // il prototipo di xdr_element() // deve essere quello standard

);

• Durante la deserializzazione, se *ap e' NULL XDR alloca un array della dimesione appropriata e setta *ap a riferire l'array. In ogni caso, setta *lp al numero degli elementi effettivamente contenuti nell'array.

• Durante la serializzazione il numero degli elementi dell'array e' ottenuto dal valore di *lp.


80

• xdr_array() invoca la funzione xdr_element() per processare ciascuno dei suoi elementi.

• Anche la funzione xdr_array() non e' conforme al prototipo standard.

• Anche in questo caso, dalla definizione di uno specifico tipo array XDR puo' essere derivata la definizione di una funzione filtro con prototipo standard.

Che si limita a invocare la funzione filtro generica xdr_array() passandole tutti i parametri aggiuntivi necessari.

Vedi esempio nelle pagine seguenti, dove si vede anche come le informazioni sui parametri aggiuntivi sono deducibili dalla definizone dello specifico tipo di array.


81

• Vedi il riferimento

SunSoft, Network Interfaces Programmer's Guide, app. B

per la definizione delle altre funzioni filtro della libreria XDR di base.

• Ma e' veramente necessario conoscere la libreria XDR di base e scriversi a mano le funzioni per la codifica e decodifica delle proprie strutture dati (della propria sintassi astratta)?

• Non esiste un sistema di programmazione XDR completo analogo ai sistemi di programmazione ASN.1?

• Certo che esiste!

• Basta descrivere in XDR la propria sintassi astratta e

farla processare (compilare) al compilatore rpcgen

• rpcgen generera' automaticamente le relative funzioni filtro

• oltre a fornirci la rappresentazione concreta locale in C dei tipi di dato della sintassi astratta.

XDR library e rpcgen

82


Protocol.x(sintassi astratta XDR)

rpcgen

Protocol_xdr.c(funzioni di

de/codifica per i tipi definiti nella sintassi

astratta)

Protocol.h(rappresentazione concreta locale di

valori della sintassi astratta)

XDR Library

chiama

produce

User program(C)

chiama

include

chiama

83


RPC_protocol.x(sintassi astratta XDR del protocollo Sun RPC v2)

rpcgen

RPC_protocol_xdr.c(funzioni di

de/codifica per rpc_msg e tipi riferiti)

RPC_protocol.h(rappresentazione concreta locale di PDU del protocollo

Sun RPC v2)

XDR Library

chiama

produce

Sun RPC v2 Protocol Entity

(C)

chiama

include

chiama

84

• Definizione XDR:typedef int VarIntegerList<1000>;

• Struttura dati C per la rappresentazione concreta locale del tipo XDR:typedef struct { u_int VarIntegerList_len; int *VarIntegerList_val;} VarIntegerList;

• Funzione filtro di de/codifica generata da rpcgen:bool_t xdr_VarIntegerList(register XDR *xdrs, VarIntegerList *objp) { register int *buf; if (!xdr_array(xdrs, (char **)&objp->VarIntegerList_val, (u_int *)&objp->VarIntegerList_len, 1000, sizeof (int), (xdrproc_t)xdr_int)) return (FALSE); } return (TRUE);}

Uso di rpcgen: array di lunghezza variabile

85

• Rappresentazione concreta locale C del tipo XDR:

typedef int VarIntegerList<1000>;

• Definizione della variabile:

VarIntegerList arrayVar;

Uso di rpcgen: array di lunghezza variabile

arrayVar

. . .

VarIntegerList_len

VarIntegerList_val

VarIntegerList_len

86

• Definizione XDR:typedef int IntegerList[1000];

• Struttura dati C per la rappresentazione concreta locale del tipo XDR:typedef int IntegerList[1000];

• Funzione di de/codifica:bool_t xdr_IntegerList(register XDR *xdrs, IntegerList objp) { register int *buf; if (!xdr_vector(xdrs, (char *)objp, 1000,

sizeof (int), (xdrproc_t) xdr_int)) return (FALSE); } return (TRUE);}

Uso di rpcgen: array di lunghezza fissa

87

• In generale, ogni variabile definita in un programma dovrebbe essere correttamente inizializzata (infatti nei linguaggi object-oriented gli oggetti sono creati da costruttori che provvedono anche ad inizializzarli).

• Quando si utilizza XDR l’inizializzazione della variabile target e’ necessaria prima di poter effettuare una operazione di decodifica su di essa.

Infatti, se non fosse inizializzata correttamente, date le regole del decoder XDR un campo puntatore con valore diverso da NULL verrebbe interpretato come puntare al buffer su cui effettuare la decodifica.

• Di conseguenza la maniera corretta di inizializzare una rappresentazione locale e’ di settare tutti i suoi byte a 0.

Questo assicura che qualunque campo puntatore presente nella struttura sia interpretato come avere valore NULL.

• Una rappresentazione locale deve essere azzerata ogni volta che vogliamo effettuarci sopra una operazione di decodifica.

Inizializzazione della rappresentazione locale

88

• La XDR library contiene un secondo insieme di funzioni dedicato alla gestione degli XDR stream da/su cui i dati vengono de/serializzati.

• Esistono diversi tipi di XDR stream che consentono di de/serializzare dati su

• File del file system (compresi device di I/O),• Connessioni TCP/IP,• Memoria centrale.

• Esistono operazioni per:• creare (inizializzare) un XDR stream (di un tipo specifico),• distruggere (terminare l'accesso a) un XDR stream.

• Ogni XDR stream definisce anche la direzionalita' delle operazioni che gli sono applicate: XDR_ENCODE, XDR_DECODE, XDR_FREE.

• In ogni caso occorre per prima cosa allocare una variabile per il descrittore dello stream:

#include <rpc/xdr.h>

XDR xdrs;

La XDR library: gestione degli XDR stream

89

• Inizializzazione di un XDR stream su file.

#include <stdio.h>


void xdrstdio_create(XDR *xdrs,

FILE *fp,

enum xdr_op x_op);

dove x_op definisce la direzionalita' dello stream.

• Inizializzazione di un XDR stream su memoria centrale.


void xdrmem_create(XDR *xdrs,

char *addr,

u_int len,

enum xdr_op x_op);

La XDR library: creazione di un XDR stream

90

• Se si sta utilizzando un XDR stream su memoria e’ necessario poter sapere quanti byte sono stati scritti nel buffer.

• ad esempio per trasmettere questi byte in rete attraverso un socket (e’ quello che fa il supporto RPC Sun quando utilizza UDP come trasporto).

• La funzione xdr_getpos() fornisce questa informazione:


u_int xdr_getpos(XDR *xdrs);

dove, per uno stream su memoria in direzione XDR_ENCODE, il valore tornato rappresenta il numero di byte scritti nello stream.

• Non tutti gli XDR stream supportano il controllo della posizione, ma quelli su memoria si’.

• E’ possibile anche, almeno per gli stream su memoria, settare il valore della posizione, ad esempio per iniziare la scrittura di un nuovo messaggio:

bool_t xdr_setpos(XDR *xdrs, u_int pos);

La XDR library: posizione in un XDR stream

91

XDRstream in memoria centrale

XDR stream

buffer

len

len

pos

Partedel

buffer gia’

utilizzata

pos

x_op

• N.B.: se si eseguono piu’ operazioni successive di encodifica su uno stream ciascuna di queste inizia a scrivere nel buffer a partire dalla posizione pos corrente (e di conseguenza la fa avanzare).

• N.B.: se si eseguono piu’ operazioni successive di decodifica su uno stream ciascuna di queste inizia a leggere il buffer a partire dalla posizione pos corrente (e di conseguenza la fa avanzare).

92

• Uno XDR stream, di qualunque tipo, viene terminato attraverso la chiamata della funzione:


void xdr_destroy(XDR *xdrs);

• L'utilizzo di un XDR stream dopo che su di esso e' stata eseguita l'operazione xdr_destroy() e' illegale.

La XDR library: distruzione di un XDR stream

93

int xid = 0;XDR xdrEnc;char txBuff[8192];. . .xdrmem_create(&xdrEnc, txBuff, 8192, XDR_ENC);. . .void sendCallMsg(unsigned progN, unsigned versN, unsigned procN, XDR *xdrE, char txBuff[], int fd, struct sockaddr_in *dst) { rpc_msg m; m.xid = xid++; m.body.mtype = CALL; m.body.body_u.cbody.rpcvers = 2; m.body.body_u.cbody.prog = progN; m.body.body_u.cbody.vers = versN; m.body.body_u.cbody.proc = procN; m.body.body_u.cbody.cred.flavor = AUTH_NULL; m.body.body_u.cbody.verf.flavor = AUTH_NULL; xdr_setpos(xdrE, 0); xdr_rpc_msg(xdrE, &m); sendto(fd, txBuff, xdr_getpos(xdrE), 0, dst, sizeof(dst));}

Esempio: invio di un rpc_msg su UDP

94

• Implementare la funzione della libreria XDR:

void xdr_free(xdrproc_t proc, char *objp);

dove:

• The first argument is the XDR routine for the object being freed.

• The second argument is a pointer to the object itself.

• Note: if a pointer is passed to this routine the pointer is not freed, but what it points to is freed (recursively, depending on the XDR routine).

Esercizio 1

95

• Esiste uno stream XDR per la serializzazione (e la trasmissione) di informazioni su una connessione TCP,ma non esiste uno stream analogo per operare su UDP.

• Per utilizzare XDR su UDP:

• Si utilizza uno stream XDR in memoria.

• Si utilizza il buffer di memoria dello stream per de/codificare il messaggio (il buffer serve a contenere il messaggio in rappresentazione canonica di rete).

• Si trasmette/riceve sul socket UDP il contenuto del buffer.

• Il buffer di memoria associato allo stream XDR deve essere abbastanza grande da contenere l’intero datagram UDP.

• Come mai se l’uso di XDR su UDP e’ cosi’ semplice sono stati introdotti degli appositi stream XDR su TCP?

• Se volessimo utilizzare come layer di trasporto TCP ma non volessimo utilizzare gli stream XDR appositi, di cosa avremmo bisogno?

Esercizio 2

Lez. 91 Reti di Calcolatori XDR - eXternal Data Representation Vedi: SunSoft, Network Interfaces...

Documents

Transcript of Lez. 91 Reti di Calcolatori XDR - eXternal Data Representation Vedi: SunSoft, Network Interfaces...