Dc Project 1.1

8/4/2019 Dc Project 1.1

1/30

Concurrent & Distributed ComputingSemester Project

Version 1.1

March 21, 2011

Goal

This project aims to equip students with a better understanding of howvarious RPC mechanisms work behind-the-hood by developing a solutionfor calling remote methods without relying on any existing libraries, e.g.,Sun RPC, CORBA etc.

1 Introduction

In this project you will be implementing a scaled down version of the RPCprotocol described in [1]. You will be writing code for both client and serversides. During the course of development you shall be faced with challengespertaining to any RPC implementation and shall be required to come up withworking solutions.

1

8/4/2019 Dc Project 1.1

2/30

2 RPC System

2.1 Overview

An RPC system essentially allows clients to execute procedures on remoteservers . This allows not only the computation load to be distributed but alsogives the clients restricted access to the servers address space. For example,the Folding@home is the worlds most powerful distributed computing clusterwhich is deployed on volunteers Playstation 3 systems around the world. TheRPC calls in this aspect are intended to exploit the Cell microprocessors com-putational abilities for biological simulations. On the other hand, Facebookallows developers to communicate with its servers using XML-RPC calls whichin turn allows your C++, Python or Java applications to get details of a loggedin Facebook user (e.g., friends count, wall posts etc.) In the latter example the

focus is on fetching particular details from Facebooks address space into theclient application.

Several different implementations for RPC calls exist such as Sun RPC,XML-RPC and Facebooks Thrift protocol with each one having its own setof pros and cons. While these solutions cater to many of the issues faced bydevelopers, they shield away the nitty-gritty details of RPC mechanisms fromthe eyes of the programmer. For example, you dont need to bother yourself with the endianness of your messages when communicating over XML-RPC withFacebook. To align this project with the contents we studied during the classlectures you shall be required to code your own RPC stack (albeit a considerablysimple one when compared to the real-world counterparts mentioned above).

Our RPC world shall be entirely asynchronous. Everything shall be com-

mmunicated using UDP packets. After receiving a CALL, a server shall decidehow to respond to it and send a RESULTpacket whenever and if it decides toentertain the client.

2

8/4/2019 Dc Project 1.1

3/30

2.2 RPC Interface

RPC procedures are generally described using an Interface Denition Lan-guage (IDL). While you will not be asked to build one, we short circuit theprocess by providing you with the three procedures that your server has tosupport.

uint32 t calculate factorial(uint32 t n) :(Idempotent) For 0 < n < 10, calculate and return n !, return 0 otherwise.

uint32 t get balance(void) :(Non-idempotent) Return the current balance of the calling client.

uint32 t add balance(uint32 t amount) :(Non-idempotent) For amount < 1000, deposit and return the new bal-

ance, return 0 otherwise.

The function IDs are read from the conguration les at both the serverand client side. You do not have to worry about mismatching IDs as dur-ing the project testing it shall be ensured that function IDs mentioned in anyclient.cfg are the same as those in corresponding server.cfg .

3

8/4/2019 Dc Project 1.1

4/30

2.3 Project Overview

Your RPC system will consist of a single client and a single server for now.Both client and server will run on separate machines. The project evaluatorwill sit on the server machine and launch your RPC enabled server from thecommand line (after compiling the project using a student-provided command).The server is launched with a conguration le as the parameter:. / s e r v e r s e r v e r . c f g

Through the conguration le, the server can be run in one of the followingthree modes:

In REPLYmode, the server shall respond to any client packet it receivesimmediately.

In HOLDmode, the server shall delay the responses to all clients or in otherwords, put them on hold. All held clients are serviced as soon as aRETURNkey is pressed on the console.

In DROPmode, the server shall not respond to the client at all.

Here is an example output of a server in HOLDmode (assuming a client isalready running and sending commands):

Call receivedClient ID: 0, Sequence ID: 0, Function ID: 42, N: 3Result: RPC ErrorCall held

Call receivedClient ID: 1, Sequence ID: 0, Function ID: 0, N: 3Result: 6Call held

(Administrator pressed RETURN )

Results sent.

In the rst case an RPC error occurred since the server could not nd afunction with the ID 42. Please not that the error is communicated to the clientafter RETURNis pressed by the administrator.

The above format is not required, but similar information should be visibleto ensure evaluator is aware of progress. All marks will however be assignedbased on scripts run over your logs (explained in section 3).

4

8/4/2019 Dc Project 1.1

5/30

Clients are also launched with a conguration le as its parameter:

. / c l i e n t c l i e n t 0 . c f g

The main function for the client must contain the following code:

# inc lude < s t d i o . h ># inc lude < s t d i n t . h ># inc lude < s t d l i b . h >

#i n c l u d e c l i e n t . h

i n t m ai n ( i n t a rgc , c h a r arg v [ ] ){

c h a r c h o i c e ;

i f ( a rg c < 2) {p r i n t f ( u sa ge : . / c l i e n t c o n f i g f i l e \ n) ;

e x i t ( 1 ) ;}

r p c r e a d c o n f i g ( a rg v [ 1 ] ) ;

w hi l e ( 1 ) {p r i n t f ( C ho os e f u n c t i o n : \ n) ;p r i n t f ( \ t [ c ] a l c u l a t e f a c t o r i a l \ n) ;p r i n t f ( \ t [ g ] e t ba la nce \ n) ;p r i n t f ( \ t [ a ] dd balan ce \ n) ;do {

scanf ( %c , &cho ice ) ;} w h i l e ( c h o i c e == \ n ) ;

s w i t c h ( c h o i c e ) {c a s e c :

c a s e C :r p c c a l c u l a t e f a c t o r i a l ( ) ;break ;

c a s e g :c a s e G :

r p c g e t b a l a n ce ( ) ;break ;

c a s e a :c a s e A :

r p c a d d b a l a n c e ( ) ;break ;

}}

r e tu r n 0 ;}

Listing 1: client-main.c

5

8/4/2019 Dc Project 1.1

6/30

The client.h header shall contain the following prototypes:

v oi d r p c r e a d c o n f i g ( c o ns t c ha r f i l en ame ) ;v oi d r p c c a l c u l a t e f a c t o r i a l ( v oi d ) ;v o id r p c g e t b a l a n c e ( v o id ) ;v o i d r p c a d d b a l a n c e ( v o i d ) ;

Listing 2: client.h

Denitions for these functions have to be present in client.c .

The main function in listing 1 ensures that rpc read config gets the con-guration le name from the command-line argument. The job of rpc read -config is to parse the conguration le for parameters explained in section2.4.

After the conguration values are parsed, the user selects an RPC procedure

in the main function and one of the following functions is called: rpc calculate factorial

rpc get balance

rpc add balance

These functions input the call parameter from the user and execute theRPC by sending a CALLwith the appropriate function ID (scanned from theconguration le) to the server. After receiving back a response its contents aredisplayed:

Choose function:[c]alculate factorial[g]et balance[a]dd balancecFunction: calculate factorial Enter n: 3Result: 6

6

8/4/2019 Dc Project 1.1

7/30

A client keeps retransmitting the CALLs after specic intervals until it eitherreceives a positive response or it decides that the server is no longer alive.Example run of a client in such situations is shown below:

Choose function:[c]alculate factorial[g]et balance[a]dd balancecFunction: calculate factorial Enter n: 3Result: RPC ACK, server is busy Result: RPC ACK, server is busy Result: 6

Choose function:[c]alculate factorial[g]et balance[a]dd balancecFunction: calculate factorial Enter n: 4Timeout Timeout Timeout, cannot execute call

Both client and server are supposed to log events in the background to anXML le. The entire project will be graded based on this resulting log le. Formore details refer to section 3.

7

8/4/2019 Dc Project 1.1

8/30

2.4 Binding

Binding is the process of locating a particular server and its services acrossa network. For example, before any calls can be made across Sun RPC a clientneeds to gure out the target servers IP address and port numbers of its ser-vices. In this case the IP addresses are generally resolved through a DNS orNetBIOS server while the port numbers are obtained through a portmapperdaemon (which in turn is xed to run at port 111).

Our project simplies the binding procedure through conguration les.Servers obtain these values from server.cfg upon being launched while clientsrefer to their particular conguration les (specied on the command-line). Oneach line of these les a name value pair is provided. The pairs are delimited bya single space and the values are scanned according to the data types speciedin tables below. Empty lines are ignored.

my log char [64]server mode char [8]server port char [16]

server byte order uint32 tclient 0 balance uint32 tclient 1 balance uint32 t

calculate factorial id uint32 tget balance id uint32 tadd balance id uint32 t

Table 1: server.cfg

my log char [64]server ip char [64]

server port char [16]server byte order uint32 t

my id uint32 t my port char [16]

my timeout uint32 t my int size uint32 t

calculate factorial id uint32 tget balance id uint32 tadd balance id uint32 t

Table 2: client.cfg

8

8/4/2019 Dc Project 1.1

9/30

An example server.cfg is provided in listing 3 which outlines the followingsetup:

Server logs its activity in server-0.xml .

Server is in REPLYmode.

Server listens on port 4950 .

Server follows big-endian byte order (explained in section 2.5.1).

Client 0 has a starting balance of 0.

Client 1 has a starting balance of 100.

calculate factorial has an id of 0.

get balance has an id of 1.

add factorial has an id of 2.

m y lo g s e r v er 0.xml

s e rv e r m od e r e p l ys e r v e r p o r t 4 95 0s e rv e r b y t e o r d er 0

c l i e n t 0 b a l an c e 0c l i e n t 1 b a l a n ce 100

c a l cu l a t e f a c to r i a l i d 0g e t b a la n c e i d 1a d d b a la n ce i d 2

Listing 3: server.cfg

9

8/4/2019 Dc Project 1.1

10/30

A corresponding client.cfg is given in listing 4:

Client logs its activity in client-0.xml .

Client ID is 0.

Client listens on port 4951 .

CALLs time out after 5 seconds.

Input and output is done through 32-bit integers (explained in section2.5.2).

m y l og c l i e n t 0.xml

s e r v e r ip 1 2 7 . 0 .0 . 1

s e r v e r p o r t 4 95 0s e rv e r b y t e o r d er 0

m y i d 0my por t 4951my t imeout 5m y i n t s i z e 32

c a l cu l a t e f a c to r i a l i d 0g e t b a la n c e i d 1a d d b a la n ce i d 2

Listing 4: client.cfg

10

8/4/2019 Dc Project 1.1

11/30

2.5 Marshalling

Marshalling is the process of packing or serializing data into a binarystream suitable for transmission or persistent storage. There are signicantlyprecarious considerations involved in this step, such as:

The unpacker who is unmarshalling the data might have an entirelydifferent memory space, making memory pointers useless.

Similarly, the unpacker might have entirely different byte order, align-ment, padding and integer sizes than the packer.

Standardized notations such as XDR and ASN.1 exist which marshall dataaccording to a pre-dened set of rules. For marshalling CALLs and RESULTs, oursystem again has a simplied set of constraints which are explained below.

2.5.1 Byte Order

The conguration les in section 2.4 specify the byte order according towhich the server should receive and send messages. It is the responsibility of a particular stub to convert the endianness of received messages to match itsnative byte order. In the conguration les 0 indicates the big endian byte orderand vice versa.

Figure 1: Server Byte Order

11

8/4/2019 Dc Project 1.1

12/30

2.5.2 Integer Sizes

The server shall always be dealing with 32-bit integers ( uint32 t ). Eachclient conguration species the integer sizes according to which it should inputand output the values. In case theres a conict between the two sizes, theclient is required to rst pad or trim zeros from appropriate number of mostsignicant bits. If theres a loss of information during the conversion the clientshould print an appropriate error.

Choose function:[c]alculate factorial[g]et balance[a]dd balancec

Function: calculate factorial Enter n: 9RPC Decode Error: cannot convert result to uint16 t

The following gure claries the conversion process. The client stubs aretranslating the uint32 t s received from the server into uint16 t and uint64 trespectively.

Figure 2: Integer Size Conversion

12

8/4/2019 Dc Project 1.1

13/30

2.6 Transport

The client starts the RPC call by sending a CALLto the server. Each call iscomposed of:

char [16] uint32 t uint32 t uint32 t uint32 tclientport clientid functionid seqid n

Table 3: CALL Contents

clientport is a 16-byte long string which contains the port the clientshall subsequently listen on for server responses. This is specied throughthe conguration le.

clientid is a 32-bit integer specifying our client ID, also specied throughthe conguration le.

functionid is a 32-bit integer specifying which function does the userwant to execute on the server. The function IDs correspond to the onespresent in both server and clients congurations.

seqid is a 32-bit integer which is increased on each subsequent retransmitof this CALL.

n is the 32-bit integer which is the parameter of our RPC method.

After sending the CALLthe client waits for a response from the server. Incase it times out before receiving the response, it checks whether it shouldresend or abort the call. Otherwise it gures out whether the response wasan acknowledgement, an error or a successful result. Algorithm 1 provides asimplied outline of this process. The initial timeout period for the client isgiven by my timeout parameter in the conguration le.

13

8/4/2019 Dc Project 1.1

14/30

Algorithm 1 Client Processsend CALLloop

wait for server response on clientportif timed out then

if retry count is below 3 thenincrease seqid and retransmitincrement retry count

elsegenerate error and abandon the call

end if else

if RESULTis an acknowledgement thendouble waiting period

reset retry countelsedetermine whether the RESULTis validprint the outcome and abandon the call

end if end if

end loop

Each RESULTcontains the following elds:

uint32 t uint32 t uint32 t uint32 t uint32 tstatus clientid functionid seqid result

Table 4: RESULT Contents

status is 0 for a SUCCESSful result, 1 for an RPC ERROR(e.g., invalidclientid ) and 2 for an ACKnowledgement.

clientid , functionid and seqid are copied from the CALLto which theserver is responding.

result contains the return value in case of a SUCCESSful result, otherwiseits value is ignored.

The server keeps listening for packets on the port specied in its conguration

le. Upon receiving a CALL it determines how to deal with it according tothe behavior specied on its command-line. The REPLY and DROPmodes arestraightforward in nature and just respond to the incoming calls or drop themaltogether. The HOLDmode can be implemented with algorithm 2. It should benoted that a mechanism for unholding the calls shall be required for sendingback the results after the RETURNkey is pressed by the administrator.

14

8/4/2019 Dc Project 1.1

15/30

Algorithm 2 Server Processloop

receive CALLif CALLfrom clientid is already held then

send a RESULTwith status ACKelse

update client database to indicate CALLfrom clientid is now heldend if

end loop

The communication ows for different server modes are explained in thefollowing sections.

2.6.1 REPLY

In the most simple case the server shall respond to the CALLwith a RESULTindicating SUCCESSor an ERROR:

Figure 3:REPLY

15

8/4/2019 Dc Project 1.1

16/30

2.6.2 DROP

The client shall retransmit the CALLafter timing out. The seqid is increasedby the client on each retransmit. In case there is a time out after the thirdretransmit the client shall exit with an appropriate error.

Figure 4: DROP

16

8/4/2019 Dc Project 1.1

17/30

2.6.3 HOLD

Holding implies that the server is busy but is still alive. In this case, foreach subsequent retransmit by the client the server shall respond with an ACK.Tthe client shall increase its waiting period exponentially for the next time outafter receiving the ACK.

Figure 5: HOLD

17

8/4/2019 Dc Project 1.1

18/30

3 Logging

3.1 Overview

Both the server and the client shall create XML logs in their working di-rectories. For grading your submission, your applications shall be run with aspecic set of conguration les and the log les shall than be parsed througha grading script. In case the automated grading process fails on your logs youshall receive zero marks for that particular test. It is entirely your responsibilityto ensure that the structure of your logs conform to the required specications.

18

8/4/2019 Dc Project 1.1

19/30

3.2 Client Logs

3.2.1 Structure

The overall structure of your client logs has to follow the pattern givenbelow. The nodes are explained in detail in section 3.2.2. The numbers insquare brackets after each node are not a part of the XML le and denote thenumber of times the node can occur in that particular place.< lo g >

< c o n f i g > [ 1 ]< s e r v e r i p > s t r i n g < / s e r ve r i p > [ 1 ]< s e r v e r p o r t > s t r i n g < / s e r v e r p o r t > [ 1 ]< s e r v er b y t e o r d e r > i n t e g e r ( v a l ue : { 0 | 1 } ) < / s e r v e r b y t e o r d e r > [ 1 ]< m y i d > i n t e g e r < /my id > [ 1 ]< m y p o r t > s t r i n g < /my por t > [ 1 ]< m y i n t s i z e > i n t e g e r ( v a l ue : { 1 6 | 3 2 | 6 4 } ) < / m y i n t s i z e > [ 1 ]

< / c o n f i g >< command > [ 1 . . ]

< c a l l > [ 1 . . ]< n > i n t e g e r < /n > [ 1 ]< packet > [ 0 . . 1 ]

< c l i e n t p o r t > s t r i n g < / c l i e n t p o r t > [ 1 ]< c l i e n t i d > s t r i n g < / c l i e n t i d > [ 1 ]< f u n c t i o n i d > s t r i n g < / f u n c t i o n i d > [ 1 ]< s e q i d > s t r i n g < / s e q i d > [ 1 ]< n > s t r i n g < /n > [ 1 ]

< /packet >< r e s u l t > [ 0 . . 2 ]

< r e s u l t > i n t e g e r < / r e s u l t > [ 1 ]< packet > [ 1 ]

< s t a t u s > s t r i n g < / s t a t u s > [ 1 ]< c l i e n t i d > s t r i n g < / c l i e n t i d > [ 1 ]< f u n c t i o n i d > s t r i n g < / f u n c t i o n i d > [ 1 ]< s e q i d > s t r i n g < / s e q i d > [ 1 ]< r e s u l t > s t r i n g < / r e s u l t > [ 1 ]

< /packet >< / r e s u l t >< t imeout > [ 0 . . 1 ]

< s e c o n d s > i n t e g e r < / seconds > [ 1 ]< / t imeout >

< / c a l l >< summary >

s t r i n g ( v a l ue : {SUCCESS |ERROR |TIMEOUT |

ENCODE ERROR |DECODE ERROR } )< /summary > [ 1 ]

< /command >< / l o g >

Listing 5: client.xml

19

8/4/2019 Dc Project 1.1

20/30

3.2.2 Rules

Each client must create an XML le in its current directory with the namespecied by the my log conguration parameter. The rst two lines of this lemust be:< ?xml version =1 .0 encoding=ISO 8859 1 ? >< ?xml s t y l e s h e e t t y pe= t e x t / x s l h r e f = c l i e n t . x s l ? >

The root-node must be log with the following parameters:< ?xml version =1 .0 encoding=ISO 8859 1 ? >< ?xml s t y l e s h e e t t y pe= t e x t / x s l h r e f = c l i e n t . x s l ? >

< lo g xm ln s: xs i= ht tp : //www.w3. org /2001/XMLSchema i n s t a n c e xsi :noNamespaceSchemaLocat ion= ht t p: / / in sp ir a t ed . com/xml/

c l i e n t . x sd >

< / l o g >

Inside log , rst of all the conguration parameters must be specied for thatparticular invocation of client:< ?xml version =1 .0 encoding=ISO 8859 1 ? >< ?xml s t y l e s h e e t t y pe= t e x t / x s l h r e f = c l i e n t . x s l ? >


c l i e n t . x sd >< c o n f i g >

< s e r v e r i p > 1 2 7 . 0 . 0 . 1 < / s e r v e r i p >< s e r v e r p o r t > 4950< / s e r v e r p o r t >< s e r v e r b y t e o r d e r > 0< / s e r v e r b y t e o r d e r >< my id > 0< /my id >< my port > 4951< /my port >< m y i n t s i z e > 32< / m y i n t s i ze >

< / c o n f i g >< / l o g >

20

8/4/2019 Dc Project 1.1

21/30

After the user selects the function and inputs the parameter, a command nodeis appended below the config :< ?xml version =1 .0 encoding=ISO 8859 1 ? >< ?xml s t y l e s h e e t t y pe= t e x t / x s l h r e f = c l i e n t . x s l ? >


c l i e n t . x sd >< c o n f i g >

< s e r v e r i p > 1 2 7 . 0 . 0 . 1 < / s e r v e r i p >< s e r v e r p o r t > 4950< / s e r v e r p o r t >< s e r v e r b y t e o r d e r > 0< / s e r v e r b y t e o r d e r >< my id > 0< /my id >< my port > 4951< /my port >< m y i n t s i z e > 32< / m y i n t s i ze >

< / c o n f i g >

< command >< c a l l >< n> 7< /n >< packet >

< c l i e n t p o r t > 4951< / c l i e n t p o r t >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >< s e q i d > 0x00000000 < / s e q i d >< n> 0x000000007 < /n >

< / packe t >< r e s u l t >

< r e s u l t > 5040< / r e s u l t >< packet >

< s t a t u s > 0x00000000 < / s t a t u s >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >

0x00000000

< r e s u l t > 0x000013b0 < / r e s u l t >< / packe t >

< / r e s u l t >< / c a l l >< summary > SUCCESS < /summary >

< /command >< / l o g >

The client has sent the value 7 to the server. The rst node inside commandis call . Inside the call , n species the parameter in its original decimal rep-resentation. The packet node contains the information sent over-the-wire.For example, since the server byte order is big-endian for our conguration,0x00000007 is transmitted for n.

A result node follows the packet . While the structures are similar, resultis contained inside the call node. In the example above, 5040 was returnedwhich was received on the wire as 0x000013b0 .

21

8/4/2019 Dc Project 1.1

22/30

If the client times out, a timeout node follows packet instead of result . Itonly species the number of seconds after which the client timed out:

< c a l l >< n> 3< /n >< packet >


< / packe t >< t imeout >

< seconds > 5< / s econds >< / t imeou t >

< / c a l l >

The following example shows a call receiving an ACK(i.e., with a statusof 2) from the server and subsequently timing out after 10 seconds:

< c a l l >< n> 5< /n >< packet >



< r e s u l t > 83886080 < / r e s u l t >< packet >

< s t a t u s > 0x00000002 < / s t a t u s >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >< s e q i d > 0x00000001 < / s e q i d >< r e s u l t > 0x05000000 < / r e s u l t >

< / packe t >< / r e s u l t >< t imeout >

< seconds > 10< / s econds >< / t imeou t >

< / c a l l >

22

8/4/2019 Dc Project 1.1

23/30

If instead of timing out a result is received after an ACK, its contents areappended after which the current call node is closed:

< c a l l >< n> 5< /n >< packet >




< s t a t u s > 0x00000002 < / s t a t u s >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >

< s e q i d > 0x00000003 < / s e q i d >< r e s u l t > 0x05000000 < / r e s u l t >< / packe t >

< / r e s u l t >< r e s u l t >

< r e s u l t > 12 0< / r e s u l t >< packet >


< / packe t >< / r e s u l t >

< / c a l l >

Just before the end of command, a summary of SUCCESS, ERROR, TIMEOUTisreported:

< command >< c a l l >

. . .< / c a l l >< summary > TIMEOUT < /summary >

< /command >

23

8/4/2019 Dc Project 1.1

24/30

In case there is an RPC encoding error because of integer sizes as explainedin section 2.5.2, the packet node is not included in the call and a summaryof ENCODE ERRORis reported. In the example below client is dealing with 64-bitintegers, hence while a number larger than 0xFFFFFFFF can be input it shallgenerate in an encoding error:

< c o n f i g >. . .

< m y i n t s i z e > 64< / m y i n t s i ze >< / c o n f i g >


< n> 87178291200 < /n >< / c a l l >< summary > ENCODEERROR < /summary >

< /command >

Similarly, a DECODE ERRORcan occur while unmarshalling the RESULT. In theexample below the client is dealing with 16-bit integers, hence while a numbersmaller than 0xFFFF can be input the reply from server shall generate a decodingerror:

< c o n f i g >. . .

< m y i n t s i z e > 16< / m y i n t s i ze >< / c o n f i g >


< n> 10< /n >< packet >

4951

< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >< s e q i d > 0x00000000 < / s e q i d >< n> 0x00000000A < /n >



< s t a t u s > 0x00000000 < / s t a t u s >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >< s e q i d > 0x00000000 < / s e q i d >< r e s u l t > 0x00375f00 < / r e s u l t >


< / c a l l >< summary > DECODEERROR < /summary >

< /command >

24

8/4/2019 Dc Project 1.1

25/30

3.3 Server Logs

3.3.1 Structure

The overall structure of your client logs has to follow the pattern givenbelow. The nodes are explained in detail in section 3.3.2. The numbers insquare brackets after each node are not a part of the XML le and denote thenumber of times the node can occur in that particular place.< lo g >

< c o n f i g > [ 1 ]< s e r v e r m o d e > s t r i n g ( v a l u e : { r e p l y | hold | drop } ) < / s e r v e r m o d e > [ 1 ]< s e r v e r p o r t > s t r i n g < / s e r v e r p o r t > [ 1 ]< s e r v er b y t e o r d e r > i n t e g e r ( v a l ue : { 0 | 1 } ) < / s e r v e r b y t e o r d e r > [ 1 ]

< / c o n f i g >< event > [ 1 . . ]

< c a l l > [ 0 . . ]< n > i n t e g e r < /n > [ 1 ]< packet > [ 1 ]

< c l i e n t p o r t > s t r i n g < / c l i e n t p o r t > [ 1 ]< c l i e n t i d > s t r i n g < / c l i e n t i d > [ 1 ]< f u n c t i o n i d > s t r i n g < / f u n c t i o n i d > [ 1 ]< s e q i d > s t r i n g < / s e q i d > [ 1 ]< n > s t r i n g < /n > [ 1 ]

< /packet >< r e s u l t > [ 0 . . 1 ]



< /packet >< / r e s u l t >

< / c a l l >< r e s u l t > [ 0 . . 1 ]



< /packet >< / r e s u l t >< a c t i o n > s t r i n g ( v a l ue : { REPLIED | DROPPED | HELD | ACKED } ) < / a c t i o n > [ 1 ]

< / l o g >

Listing 6: server.xml

25

8/4/2019 Dc Project 1.1

26/30

3.3.2 Rules

Each server must also create an XML le in its current directory with thename specied by the my log conguration parameter. The skeleton is similarto client.xml :< ?xml version = 1. 0 enco ding=UTF 8 ? >< ?xml s t y l e s h e e t t y pe= t e x t / x s l h r e f = s e r v e r . x s l ? >


se r ve r . x sd >< c o n f i g >

< se rve r mode > r e p l y < / s e r v e r m o d e >< s e r v e r p o r t > 4950< / s e r v e r p o r t >< s e r v e r b y t e o r d e r > 0< / s e r v e r b y t e o r d e r >

< / c o n f i g >< / l o g >

26

8/4/2019 Dc Project 1.1

27/30

Every CALLreceived by the server generates an event :

< ?xml s t y l e s h e e t t y pe= t e x t / x s l h r e f = s e r v e r . x s l ? >


se r ve r . x sd >. . .

< even t >< c a l l >

< n> 7< /n >< packet >



< r e s u l t > 5040< / r e s u l t >< packet >

< s t a t u s > 0x00000000 < / s t a t u s >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >< s e q i d > 0x00000000 < / s e q i d >< r e s u l t > 0x000013b0 < / r e s u l t >


< / c a l l >< a c t i o n > REPLIED < / a c t i o n >

< / even t >< / l o g >

Each event generates an action of either REPLIED, HELD, DROPPEDor ACKED.In the following example an incoming CALLis HELD:

< even t >< c a l l >

< n> 5< /n >< packet >


< / packe t >< / c a l l >< a c t i o n > HELD< / a c t i o n >

< / even t >

27

8/4/2019 Dc Project 1.1

28/30

Similarly, an ACKis sent below by sending a result with status set to 2:

< c a l l >< n> 5< /n >< packet >






< / c a l l >< a c t i o n > ACKED < / a c t i o n >

< / even t >

If the RETURNkey is pressed, all held CALLs results should be sent. In thiscase, the event tag contains the result directly:

< even t >< r e s u l t >

< r e s u l t > 12 0< / r e s u l t >< packet >

< s t a t u s > 0x00000000 < / s t a t u s >< c l i e n t i d > 0x00000000 < / c l i e n t i d >< f u n c t i o n i d > 0x00000000 < / f u n c t i o n i d >< s e q i d > 0x00000000 < / s e q i d >< r e s u l t > 0x00000078 < / r e s u l t >< / packe t >

< / r e s u l t >< a c t i o n > REPLIED < / a c t i o n >

< / even t >

28

8/4/2019 Dc Project 1.1

29/30

3.4 Log Structure Verication

Fortunately, you shall be able to validate the structure of your logs beforesubmitting your code using the following procedures. It is recommended thatyou rst try these tests with the example logs to gain familiarity.

3.4.1 W3C XML Schema Validator

Open [2] in Firefox.

Scroll down to the form with label: File to upload.

Click on Browse, locate the server.xml log on your hard disk.

Click on Upload and get results.

Depending on errors in your logs structure you shall get either the fol-lowing output:

No schema-validity problems were found in the target

Or something similar to:

1 schema-validity problem was found in the target

Repeat the process for client logs.

3.4.2 XSL Stylesheets

Download the stylesheets from SLATE.

Unzip and place the server.xsl in the same directory as server.xml .

Open server.xml in Firefox.

Ensure that the contents are being displayed correctly.

Repeat the process for client logs.

29

8/4/2019 Dc Project 1.1

30/30

4 Submission Guidelines

This is an individual project. You are allowed to have healthy discussions,but code will be checked for plagiarism and you will be failed if caughtcheating.

You can only code in C or C++.

You can not use any external libraries.

You have to submit a Makefile which compiles your code without any errors using the make command.

Similarly, make clean should clean any object les and logs created byyour code.

In case you do not submit a Makefile , every submission must have aREADMEle containing the commands needed to compile and clean thecode.

Your submissions shall be graded according to the latest revision of thisdocument. Please check SLATE regularly for updates.

5 References

[1] A. D. Birrell and B. J. Nelson, Implementing remote procedure calls, ACM Trans. Comput. Syst. , vol. 2, pp. 3959, February 1984.

[2] W. W. W. Consortium, XML schema validator. http://www.w3.org/2001/03/webdata/xsv , March 2001.

30
http://www.w3.org/2001/03/webdata/xsvhttp://www.w3.org/2001/03/webdata/xsvhttp://www.w3.org/2001/03/webdata/xsvhttp://www.w3.org/2001/03/webdata/xsvhttp://www.w3.org/2001/03/webdata/xsv

Dc Project 1.1

Documents

Transcript of Dc Project 1.1