Unit home

help3002

Lecture recordings
via LMS

Schedule

Project

Final exam

Unit outline

Resources

Textbooks

Extra reading

Look after yourself!

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.