Skip to main content

UNICAST, MULTICAST, BROADCAST

When traffic is passed between hosts on a network, three different transmission mechanisms are possible. These include unicasts, multicasts, and broadcasts.

Unicasts

A unicast is the most simple network transmission. As the name suggests, it is a direct transmission from one system to one other system only. As such, the destination address will always uniquely identify a single host for whom the data is meant. In a shared Ethernet environment (where a system might be exposed to all frames), systems would check to see whether the destination MAC address matched their own. If it did, it would process the frame. If not, it would discard the frame. On an IP-based network, the address 192.168.1.24 represents a unicast address.

Multicasts

Unlike unicasts, which are meant for a single host, a multicast is meant for a group of systems. Think of multicasts as a one-to-many transmission method. Multicasts are generally used when traffic such as video needs to be passed to many hosts at the same time. In this way, a sender would transmit a single stream of data, which would in turn be picked up by many different hosts. On IP networks, a special group of addresses is reserved for multicasting, those in the Class D range. When multiple hosts need to receive a multicast, they are all configured with an identical multicast IP address. When they receive traffic destined for this shared address, they process it. Do not confuse a multicast address with a regular IP address. In this example, all systems still have a unique IP address, but also “listen in” on a configured multicast address.

Broadcasts

The final type of network transmission is a broadcast. Quite simply, a broadcast is a transmission destined for all hosts. A special destination address designates a broadcast – in Ethernet, the broadcast address is FF-FF-FF-FF-FF-FF. When a host sees frames with this destination MAC address, it knows it has to process the frames. While excessive broadcasts on a network are generally undesirable, many network services depend on this type of transmission.

Comments

Popular posts from this blog

Sexy C#

Download samples   Table of Contents   1.   Introduction  2.   Background    3.   Sexy Features 3.1.   Extension Methods   3.2.   Anonymous Type   3.3.   Delegate   3.4.   Lambda Expression 3.5.   Async-Await Pair   3.6.   Generics   4.   Conclusion   1. Introduction     C#  is a very popular programming language. It is mostly popular in the .NET arena. The main reason behind that is the C# language contains so many useful features. It is actually a multi-paradigm programming language. Q.   Why do we call C# a muti-paradigm programming language? A.  Well, C# has the following characteristics:  Strongly typed   Object Oriented  Functional  Declarative Programming  Imperative Programming   Component based Programming Dynamic Programming ...

Making Python Programs Blazingly Fast

Let’s look at the performance of our Python programs and see how to make them up to 30% faster! Python  haters always say, that one of the reasons they don’t want to use it, is that it’s  slow . Well, whether specific program — regardless of the programming language used — is fast or slow is very much dependent on the developer who wrote it and their skill and ability to write  optimized  and  fast  programs. So, let’s prove some people wrong and let’s see how we can improve performance of our  Python  programs and make them really fast! Timing and Profiling Before we start optimizing anything, we first need to find out which parts of our code actually slow down the whole program. Sometimes the bottleneck of the program might be obvious, but in case you don’t know where it is, then here are options you have for finding out: Note: This is the program I will be using for demonstration purposes, it computes  e  to pow...

Kubernetes – init containers, CNI and more

Certain questions about Kubernetes seem to come up again and again: What’s up with this init container stuff? What’s a CNI plugin? Why is Kubernetes complaining about pods not finishing initialisation? Kubernetes is a complex system with a simple overall purpose: run user  workloads  in a way that permits the authors of the workloads to not care (much) about the messy details of the hardware underneath. The workload authors are supposed to be able to just focus on Pods and Services; in turn, Kubernetes is meant to arrange things such that workloads get mapped to Pods, Pods get deployed on Nodes, and the network in between looks flat and transparent. This is simple to state, but  extremely  complex to implement in practice. (This is an area where Kubernetes is doing a great job of making things complex for the Kubernetes implementors so that they can be easier for the users – nicely done!) Under the hood, Kubernetes is leaning heavily on a number of technologies to ma...