Novell Home

ZfD 3 Imaging and IP Multicast

Novell Cool Solutions: Feature
By Drake Backman

Digg This - Slashdot This

Posted: 18 Apr 2001

Version: ZENworks for Desktops 3

Engineer Drake Backman works on ZENworks Imaging in the ZENworks development team. Here's what he has to say about this hot topic.

There has been quite a bit of debate about whether or not ZENworks for Desktops 3 Imaging supports IP multicast. ZfD Imaging does indeed support IP multicast, but you must be at the Linux command-line to access it. (This has caused some confusion in users.) To use the ZEN imaging multicast feature, you enter the same command line on each station.

For example, the command 'img session myImage' on each station tells the computers that they will participate in a multicast session (hence the name of the second argument) named 'myImage.' Each computer opens a multicast port at a class D IP address derived from the session name, and waits for a master computer to announce itself. At the computer holding the image you wish to multicast out, you press 'm' to designate it as the master for the session. It then announces itself on the session every few seconds. When the other computers see that a master has been declared, they register themselves and the master keeps a count of how many stations have registered. When all the stations have registered, press 'g' (for 'go') on the master and the multicast begins.

The multicast does wait for all clients to join, but once the image multicast has begun, no new clients may join. (I think this makes sense. Who wants the last half of an image?)

The other issue I wanted to comment on is the multicast technology itself. It really is a natural extension of the broadcast function of IP. In broadcast, the originator sends a single packet, and the network hardware ensures that each node on the network (or subnet) receives the packet. That is great technology and was used in early imaging products. The problem is that the packet goes to every node, whether it needs it or not.

Then came multicast, which can be crudely thought of as directed broadcast. It is much more complicated than that, of course, since you then have problems of joining and leaving sessions, as well as new features such as multiple originators and consumers, but the main idea (at least for our purposes) is that you have a single packet that is sent to a limited number of consumers, and that the packet replication is handled by the networking infrastructure.

IP multicast is actually defined in an RFC. It is an industry standard. It is not implemented (or even possible) in IPX. I have seen some products claiming to do IPX multicast and I have to shake my head since, to my knowledge, IPX does not support, and cannot support, multicast. The products I have tested that claim to have IPX multicast are actually using IPX broadcast and a cool buzzword. So ideally IP multicast would reduce the number of packets going across the wire when imaging a number of computers simultaneously.

The problem is that multicast was not really designed for hard drive imaging. IP multicast has no mechanism for guaranteeing packet delivery and ordering. It seems that its main purpose is for streaming lossy data across a network. If you drop a packet or two while listening to a song coming from a multicast stream no big deal. If you drop a packet or two while receiving NTLDR for your computer, major big deal.

For ZEN imaging we had to develop a mechanism to ensure that every computer gets every packet and that they get them in the proper order. This requires extra traffic on the wire, which has caused some frustration in users who didn't understand why this was happening. On occasion a packet needs to be resent to a station that did not get it. The upshot of all this is that multicast ALWAYS results in more traffic than if the image were sent to a proxy server. But if you take into account the number of packets that would be needed to bring that image down to each station individually using unicast, then multicast very quickly becomes not only more efficient, but vastly more efficient.

There are some extreme case where data packets need to be resent so often that all packet savings are lost. These cases are rare and usually caused by a faulty network. I find that multicast works really well for the quick and dirty make-this-computer-look-like-that-computer" jobs. I have done multicast using only a single set of diskettes and a cross-over cable to move a NetWare server from one computer to another.

There are some nice improvements coming soon. The next release of ZfD will include even better support for multicast, including having multicast sessions originate from a proxy server, which will multicast an existing file, the ability to configure multicast imaging from within ConsoleOne, and compression in the multicast stream.

For More Info

For more information, see Why Use Multicast in the online documentation.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© 2014 Novell