The University of Western Australia
Computer Science and Software Engineering
 
 

Department of Computer Science and Software Engineering

CITS3002 Computer Networks

Labsheet 1 - sample solutions and discussion

  1. This is not really a solution for Q1, but gives a very strong hint as to what is going on. We can read the 32-bit (4-byte) integers from the provided file in the same way that they were written, and then print the values both as decimal values and as hexadecimal values (producing output very similar to the standard od utility):

    #include <fcntl.h>
    #include <stdint.h>
    #include <unistd.h>
    .....
        int  fd = open("Q1.datafile", O_RDONLY, 0);
    
        if(fd >= 0) {        //  IFF FILE OPENED SUCCESSFULLY
            for(int32_t i = -50 ; i<50 ; i++) {
                int32_t value;
    
                read(fd, &value, sizeof(value));
                printf("%4i\t0x%08x\t%10i\t0x%08x\n", i, i, value, value);
            }
            close(fd);
        }
    

    Each pair of characters in the hexadecimal representation represents one byte (8-bits). What do you observe about the hexadecimal representations from your standard Intel processor, compare to the 'equivalent' value in the SPARC-generated data file?

     -50    0xffffffce      -822083585      0xceffffff
     -49    0xffffffcf      -805306369      0xcfffffff
     -48    0xffffffd0      -788529153      0xd0ffffff
    .....
      -3    0xfffffffd       -33554433      0xfdffffff
      -2    0xfffffffe       -16777217      0xfeffffff
      -1    0xffffffff              -1      0xffffffff
       0    0x00000000               0      0x00000000
       1    0x00000001        16777216      0x01000000
       2    0x00000002        33554432      0x02000000
       3    0x00000003        50331648      0x03000000
    .....
      47    0x0000002f       788529152      0x2f000000
      48    0x00000030       805306368      0x30000000
      49    0x00000031       822083584      0x31000000
    

    While we wouldn't perform this in practice (in our own application's code) we could verify that the integer's bytes are being swapped. Again, ask yourself what this may mean for internetworking.

        int32_t i   = -49;
        char bytes[ sizeof(i)];
    
        printf("original: %10i\t0x%08x\n", i, i);
    
        memcpy(bytes, &i, sizeof(i));
        char tmp    = bytes[0];
        bytes[0]    = bytes[3];
        bytes[3]    = tmp;
    
        memcpy(&i, bytes, sizeof(i));
        printf("swapped:  %10i\t0x%08x\n", i, i);
    
    //
    //  will produce this output:
    //       original:        -49   0xffffffcf
    //       swapped:  -805306369   0xcfffffff
    

  2. To demonstrate that the standard checksum functions are robust, we need to demonstrate that thay can detected a high proportion of typical (burst) errors. We need to perform our experiments using many (thousands, millions) of randomly generated frames, corrupt each frame (guaranteed), and determine if the checksum functions can detect the corruption. A checksum function fails if the calculated checksum of a frame before corruption, is the same as the calculated value after corruption.

    A commented solution here.

  3. A function which simply adds up all bytes in a frame would not be very effective at detecting frame corruption. As an example, consider a frame containing two successive bytes 'A' and 'B'. If frame corruption resulted in the first byte being modified into a 'B', and the second byte being modified into an 'A', the arithmetic sum of all bytes in the frame would still be the same.

  4. To provide a solution to this exercise, we simply take the code from Q2 and fill each frame with data read from a large file, rather than being randomly generated. Again, we need to ensure that each checksum algorithm is tested with exactly the same data.

    Knowing that we transmit actual files, rather than random data, across networks, should we be now concerned about the very different performance?

    A commented solution here.


Chris McDonald
March 2020.

This Page

Written by: [email protected]