The Line on Casting

No, the headline does not pertain to fishing. Though, if you enjoy fishing as I do, that’s where your mind went, right? To cast means to project, put or send forward. In networking, that’s exactly what we need to do with our data — to send it forward.

There are a few different ways to do that, depending on what kind of data we’re sending and a few other variables.

In fishing, I can cast a large net over a big section of lake and hope to hit something, or hit lots at one time. Or, I can take my pole and put the bait precisely where it needs to go. In the case of networking, I have one more method that would be kind of like having one pole with multiple lines that could put the bait in several good spots, and nowhere else, at once. It’s called multicasting. More on that after a review of other casting alternatives.

The Problem Of Managing Streams

[IMAGE]11689[/IMAGE]

As has been discussed many, many times before, digital video takes up a big   chunk of the network pipe. It can, if not controlled properly, choke a network to its knees. An example would be video on a hub. As soon as the first video packet hits the device, it (and every one after it) will be flooded out each and every port. As you can imagine, it wouldn’t leave much room for any other data to travel. Collisions would be off the charts.

If you have a managed switch, those packets could be directed to a single port (which is what switches do), but what happens when you have multiple locations that need to see that video? Again, video packets are replicated over and over again and forwarded to the selected ports, no matter where they are on the network. Multiple streams of video are swimming all over the network.

Broadcast Mode Floods A Network

The fishing net would be an example of broadcast. Broadcast traffic is flooded to all locations on the network. Some broadcast traffic is normal and proper, such as switches sending out announcements in an attempt to discover addresses of connected computers. Video in a broadcast condition, however, would quickly shut down the network.

Unicast Is Effective For Basic Uses

A unicast transmission is as it sounds: A single stream of video traveling between one source and one receiver. This is the most basic and common way for video to be sent on a network.

A direct connection is established between two devices. Both devices send each other their addresses, to make sure the traffic is delivered. In some cases, each packet is checked for accuracy, a function of TCP (transmission control protocol). If a bad packet is found, it is requested again. This isn’t practical for streaming live video however, so for our applications we usually use UDP (user datagram protocol), where the traffic is just sent and not checked for errors.

For small camera systems, unicast may not be a bad option. It doesn’t require any special hardware or programming, and it’s very simple to set up. On larger systems, however, with hundreds of cameras and many receiving locations, or for Internet transmission, it may not be the best option.

Consider a single 2Mbps (megabits per second) video stream. It’s not going to seriously impact the network. With unicast, however, if I want to view that video at multiple locations the camera would have to now create as many streams as I have viewing locations. This would not only greatly increase the traffic streaming from that camera, but there may also be a limit on the number of streams from the camera itself.

Data On Demand

So, if we can’t flood the network, and establishing a new stream for each viewer isn’t practical, what can we do? We can multicast. A multicast stream is unique in that only one stream is sent from the camera, but the network infrastructure replicates that stream as needed and directs it to only the ports that request it.

This selectivity happens at the very last possible moment on the network. That means the video stream only goes where it’s requested, at the switch with the requesting device directly attached.

When you pull a camera into the viewing window on your DVR client or video management software application, a message is sent from your computer to the switch it’s connected to stating that you want to join the multicast group for that camera. That message is then sent up the network directly to the switch that the camera is connected to. The stream is started and then sent out the port in which the join message was received. The video only goes where the join messages came from, all the way down to your machine, where you first made the request.

If multiple locations are asking for the same stream, switches along the path replicate that stream; but again, it is only sent along the same path on which the join messages traveled up.

If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our FREE digital newsletters!

Security Is Our Business, Too

For professionals who recommend, buy and install all types of electronic security equipment, a free subscription to Commercial Integrator + Security Sales & Integration is like having a consultant on call. You’ll find an ideal balance of technology and business coverage, with installation tips and techniques for products and updates on how to add to your bottom line.

A FREE subscription to the top resource for security and integration industry will prove to be invaluable.

Subscribe Today!

Get Our Newsletters