Suppose we use CRC with a divisor of C = 101, so that c = 3. We place no restriction on m, other than the CRC restriction m > c-1. In this problem, you will use polynomials to prove that this particular C has certain error catching/error missing properties. Follow the lines of proof used in our printed lecture notes.
A. Show that this C will fail to report as erroneous any message which has exactly 2 errors, 2 bit positions apart.
B. Do Part A with "2 bit positions apart" replaced by "4 bit positions apart."
C. Show that this C will fail to report as erroneous any message which has exactly 4 errors, in burst form.
D. Show that this C will succeed in detecting as erroneous any message which has exactly 2 errors, 3 bit positions apart.
We know from the theory presented in the notes that any C will catch all burst errors of length at most c-1. (Note: That property of CRC will not be directly used in this problem.) Assume that each bit has probability p of being incorrect, and that successive bits are independent.
A. Find the probability of a burst error of length at most c-1. This is a set of k consecutive errors (k between 1 and c-1, inclusive) with no other bits in error. Remember, all or part of the burst could be in the CRC field. Your answer will be a function of m, c and p.
B. Given that a burst error of length at most c-1 occurs, what is the probability that none of the CRC bits is corrupted?
The fields of networks is very quantitative, since we are always trying to get higher speed and lower response time. The telephone companies began doing mathematical research in the early 1900s, and an extensive body of theory has been developed.
However, mathematical theory has its limitations. It is quite difficult to derive, and one must make assumptions which sometimes do not reflect reality well. An alternative tool is to write a simulation program as a tool for analyzing communication systems. In this problem, you will write a discrete-event simulation program which you will use to analyze the Go-Back-N protocol. The goals are:
You are required to use my JSim simulation package. I have placed the package in ~matloff/Pub/JSim on CSIF. You will find it convenient to take as a starting point the StopAndWait example from the package.
Your command line arguments must consist (in this order) of:
The reason I speak about "mean" frame length is that I want you to treat the frame length as a random variable. Specifically, you will generate the frame length as being uniformly distributed on the interval (m-d,m+d), where m is the mean and d = 0.1m. Note: If a frame must be retransmitted, do NOT generate a new random frame length for it; it is, after all, the same message as before.
Note that your program need not explicitly keep track of sliding windows. Simply keep track of k, the number of unacknowledged frames currently pending, a number which will always be between 0 and n, inclusive. In particular, you do NOT have to keep track of which ACK node A is expecting next, etc.
If A receives a NAK from B (corrupted frame) or a timeout occurs, all currently unacknowledged frames must be sent again (and thus k reverts to 0). When this occurs, your code will go through the event list, removing each frame which is there, and retransmitting it with the same frame length as before. (Of course, remove the timeouts too.)
Node A sends whenever it can, subject to the constraint that no more than n frames can be pending at once. When A receives an ACK for a given frame, A will immediately send a new frame. Your code can do this on the same instance of FrameElt, simply by generating a new frame length.
Your output must report: the mean time it takes for a frame to successfully (time for the last bit to reach B, measured from the time the first bit goes onto the link for the first time), and the mean number of tries it takes to send a frame.
Run your program with the data on p.277 of Leon-Garcia, with p = q = 0.1, for a value of n of your choosing. Find the best timeout period.
When the Reader grades your simulation program, his main checking will be via running your program in debug mode (debug flag = 1). This way he can easily tell if the right events are happening at the right times. He will also look closely at your "bookkeeping" code, to make sure it is collecting the right totals. Don't worry about the grading; as long as your program runs, and the Reader's spot check show that the program seems to be doing reasonable things, you will get full credit or nearly so.
You will probably want to use StopAndWait.java as your base, and modify it. (Note: Do NOT modify the JSim files themselves, i.e. JSSim.java, JSElt.java and JSFacil.java, though you can subclass.) You should of course add a frame length field to FrameElt, and you may wish to add other member data as well.
Remember, you have access to the "global" variables JSElt.JSCurrEvnt and JSElt.JSSchedListHd. You will probably make use of them here.
In modeling the phenomenon of a lost frame, one suggestion would be to generate an infinite latency for it. This way node A will time out waiting for the ACK for that packet, so the effect will be the same as if it were lost. This may make your code much simpler, and also your debugging simpler.
I suggest that you adopt the following approach (details may vary):
Set up an array Frame of FrameElt. Add a member item to FrameElt which serves as an array index, ranging from 0 to n-1. Initialize all of them being "old," with each one already having 1 try and a start time of 0.0. (Don't worry; the effect of this will become negligible when you run the simulation for a long time.) Then call SendFrame() on Frame[0].
Have these event types: "done with sending"; "arrive at B"; "arrive back at A"; "timeout". The "done with sending" event means that A is done getting this frame, say Frame[I], out onto the link. Your corresponding function DoDoneWithSending() will then schedule an "arrive at B" event for that frame, and will also call SendFrame() on Frame[I+1].
Similarly, if a timeout occurs, then remove everything from the event list (you could just set JSSchedListHd to NULL), and call SendFrame() on Frame[0] to get everything started again.