Homework 7 Solutions

22C:116, Spring 1999

1. Part A: The ISO OSI protocol hierarchy is not the final word in hierarchic analysis of communication protocols. For example, the given protocol can be broken down into the following layers:
   • DB-9 connectors and attached cables.
   • RS-232 voltage levels.
   • 1200 baud asynchronous data.

   • ENQ/ACK/NAK handshaking on 1K blocks.
   • ASCII data.
   The 5 levels given above are grouped into 3 for the physical layer and 2 for the data-link layer. Each layer is sufficiently independent of the others that it could be used with other layers above or below it -- for example, 1200 baud asynch data could be sent using other encodings, and the use of ENQ/ACK/NAK handshaking would work just as well if the data were interpreted in any other character code, so long as the ENQ, ACK and NAK characters were not used by that code for any other purpose. the protocol hierarchy described above?

   Part B: Here is one solution, where the interrupt service routines themselves do everything involved in handshaking and retransmission.

   asynch_input_interrupt_service:
       get ch from UART data input register
       if ch = ACK
         mode = normal
         enable output interrupt requests from UART
       else if ch = NAK
         mode = retransmit
         enable output interrupt requests from UART
       else
         character must be part of some other data flow
       endif
   
   asynch_output_interrupt_service:
       if mode = normal
         ch = dequeue( output_queue )
         buffer[ptr] = ch
         ptr++
         put ch in UART output data register
         if ptr = 1K then
           mode = sendenq
         else if empty( output_queue )
           disable output interrupt requests from UART
         endif
       else if mode = sendenq
         put ENQ in UART output data register
         ptr = 0
         disable output interrupt requests from UART
       else if mode = retransmit
         ch = buffer[ptr]
         ptr++
         if ptr = 1K then
           mode = sendenq
         endif
   
   put_byte(ch):
       disable output interrupt request from UART
       enqueue( output_queue, ch )
       enable output interrupt request from UART
   

2. Remote-procedure-call protocols and the abstraction of a remote procedure allow code running on one machine to access functional behavior implemented on a remote machine. Typically, the remote procedure is implemented as part of a server that serves requests from any of many clients that may wish to call this procedure. Thus, remote procedure calls are implemented using a client-server architecture, and they are typically the primary tool used by clients of more complex servers for accesing the services offered by those servers.

3. Part A: Canonical data representations solve the problem of accomodating arbitrary parameter and result structures across a variety of machines, even though some have adically differing native data representations. Canonical data representations do nothing to solve the problem of efficient calls to remote procedures that involve minimal parameter information, and in fact, the conversion to a canonical format may add significant overhead to such calls.

   Part B: Here is a proposal for a canonical data representation for data sent by a C program on one machine to a C program on another.

   • All data will be sent as a stream of 8-bit bytes.
   • All textual data will be sent using 8-bit ASCII.
   • All variable-length string data will be sent with a null terminator.
   • All integers will be sent least-significant byte first.
   • 2's complement representations will be used for all signed integers.
   • All short integers will be sent as 16 bit quantities.
   • All unqualified integers will be sent as 32 bit quantities.
   • All long integers will be sent as 64 bit quantities.
   • Where the native representation of an integer or character is longer than the representation specified here, the code to convert to canonical form will raise an exception when it such a conversion cannot be precisely done.
   • This definition of a canonical form does not dictate how the conversion is to be performed, nor how exceptions for unconvertable data are to be communicated to the application.