In my previous post, I explored how the cast device find and configure the Chromecast dongle. In this post, I'll dig into the actual cast process.

There are plenty resources online that explains how Chromecast works. But most of them focus on up-layer protocols, such as mDNS, DIAL/HTTP. I am more interested in the 802.11 MAC layer. In particular, I was curious in questions such as:

• What happens when you set up a Chromecast?
• How the cast device (such as an Android phone) and Chromecast communicate (in 802.11 layer)?

Some of the questions were obvious, others are not. In this post, I will document the process about the Chromecast setup process. This will be the first of the series of posts on this topic.

The HT-SIG field of 802.11n PLCP preamble contains a 8-bit CRC for the receiver to validate the sanity of the header. Here is how to calculate it.

Now we have designed the simulator, add a new MAC protocol to NS2, and implement the Random Resend MAC protocol, the final part will be analyze the trace file to measure the performance of our new protocol.

Now we have the simulation script, and also added our protocol to the NS2 simulator, which is still a placeholder. Now we're going the actually implement our own random MAC protocol.

In previous post, we wrote an NS2 simulation program that fits the project specification, except that we're using the standard 802.11 MAC protocol. In this post, we'll discuss how to add our own MAC protocol to NS2.

In this network project, we would need to:

• Write an simulator using TCL
• Add an new MAC protocol to NS2
• Analyze the simulation results

Let's tackle them one by one. In this post, we'll mainly focus on the simulator part.

In a few network projects, we're asked to write an interactive shell, to receive command from user input. Here is the general pattern I used. The example I used here is from the P2P network project, and you can find my earlier post about use select to monitor user input and socket at the same time.

You have probably seen this error quite often. The detailed reason why this error occurs is explained in detail here.

In short, if a TCP socket is not closed properly when the program exits, the OS will put that socket in a TIME_WAIT state for a period of time (2MSL ...

In the P2P network project, we were asked to simultaneously monitor user input and also potential in-coming messages, yet we're not supposed to use multiple threads or processes. That leaves us no choice but the select function.

I encounter this problem while doing an network course project. Easy as it sounds, it's actually not a trivial task.