Apr-10: No lecture today. I will be using this time to finish grading your Project-1 work and return it to you. On Monday, we will begin discussing, in more detail, encoding, compression, and encryption.
Apr-06: If you want to test that your Project-2 solution allows each host to be both sender and receiver simultaneously, feel free to grab the following two-way simulator code: TwoWaySimulator.java
Apr-03: Today we will be using our lecture time as a lab/help session for those still trying to wrestle Project-2 to the ground. No lecture on new stuff until Monday, Apr-06.
Mar-30: Regarding the deadline for Project-2: It is Tuesday, Mar-31, 11:59 pm. By this deadline, submit whatever you have. However, I am also going to employ the following policy: I will not grab your submitted work for Project-2 until three days after I have returned Project-1 to you. Until that moment arrives, you are welcome and encouraged to resubmit updated work for Project-2.
I have not yet returned your graded Project-1. I am working on it, but it hasn't happened yet, and will likely will not happen until later in this week. So submit some work before the deadline, and then use any extra days that follow to improve your Project-2 solutions.
Mar-26: A number of you have encountered, while working on Project-2, inconsistent errors in the form of exceptions thrown by code performing operations on some queues. We briefly discussed this problem in class a couple of weeks ago, but I didn't provide much of a description of why it's happening, nor did I provide a fix. I will do so here.
Remember that the simulator for this project runs as a set of three threads. Those threads communicate with one another through queues: one thread will insert elements into one end of a queue, while another thread removes those elements. Threads are tricky because they make it possible for one thread to be updating the queue while the other is trying simultaneously to read from it. Of course, updates require multiple steps; for example, adding an element to a queue requires both incrementing the count of elements in the queue and adding the value to the queue structure itself. These operations must be done in sequence by the adding thread, which means that at some point, the queue (as a whole) is in an inconsistent state---the count of elements doesn't match what's in the actual structure.
The LinkedList class is not made for multi-threaded use, and has this problem. The thread that is adding an element to the queue will first increment the count, then link the new value into the structure. The thread that is reading from the queue may then see that the queue length is non-zero, yet attempts to remove an element fail because the element hasn't been fully inserted into the list itself.
I accounted for this problem in one part of the code, but not in another. Specifically, the PhysicalLayer uses, for its queue of bits being delivered, a ConcurrentLinkedQueue. This particular implementation of the Queue interface is made for multi-threaded use, and guarantees that a thread reading from the queue never sees an inconsistent picture of what's in the queue; the length will always match the actual number of elements fully in the structure. It does so by using semaphores, which allow access to the queue to be locked by one thread while it performs its update, preventing other threads from accessing the partially changed queue.
However, I forgot to update DataLinkLayer itself. Specifically, the sendBuffer data member uses a LinkedList (created in the DataLinkLayer constructor), even though two threads access this queue: the main simulator thread, and the sender thread. Thus, this line of the constructor should be changed:
sendBuffer = new ConcurrentLinkedQueue();
Additionally, at the top of the DataLinkLayer.java source code file, add:
import java.util.concurrent.ConcurrentLinkedQueue;
Mar-22: We will be meeting via Zoom starting tomorrow (Monday, Mar-23) at our usual time of 10 am EST. There is a link on the course Moodle page for that Zoom meeting. Please do connect so that we can begin the project of figuring out how our class meetings will operate remotely. I look forward to seeing you all tomorrow!
Feb-17: Starting this week, there will be TA help sessions on Tuesdays from 3-5 pm in SCCE A331. Feel free to go and work on Project-1 there.
Feb-09: Two things:
Jan-17: Welcome to Networks! There are a few key pieces of information that you should know before classes begin:
Our first class meeting will be on Monday, Jan-27, at 10:00 am, in SCCE A131. We will spend some time discussing an overview of the class, but we will quickly dive into the material, so it is critical that you are present from the very beginning.
Before our first class meeting, read the Course Information. This document covers the course topics, expectations, structure, grading, etc. You are expected to have reviewed this document thoroughly.