Multicast software delivery

Multicast delivery enables parallel software distribution to an unlimited number of client systems while simultaneously reducing server and network resource requirements and bandwidth consumption for high-volume, high population software distribution.

The CM multicast capabilities enable software to be distributed to thousands of desktops in the same time it takes to deliver software to a single desktop, while making optimal use of server and network resources.

Multicast delivery enables parallel software distribution to a virtually unlimited number of client systems while simultaneously reducing server resource and network bandwidth requirements for high-volume, high-population software distribution. The multicast principle is to send a file on a virtual multicast address advertised to all target clients where each of these will get the file. Contrary to unicast, the server sends the file only one time.

Based on UDP protocol, it also has the advantage of being able to transfer this data without knowing beforehand when the targets connect nor how long they remain connected. It is therefore the perfect transport mode for e-business application distribution or for nomad targets. The clients can connect and disconnect at any time to recover the data frames. Depending on the settings of the multicast parameters the server might never stop sending packets to the multicast address, therefore clients can pick them up whenever it is the most convenient for them. This is specially useful to meet the software distribution needs of remote and mobile devices where network access and bandwidth are irregular or unpredictable.

The choice to transfer a package via the multicast channel is defined through a transfer window. If the multicast option is selected, the files can be transferred in multicast mode if they respect some conditions.

1. Server Unicast Announcement
   If a transfer window is configured for multicast transfer the Server contacts each client concerned by the transfer through the notify thread of the FileStore module and informs it that a transfer is going to start on a specified address and port. The client immediately begins listening on this address and port and answers the request that it is listening. The server stores the replies and checks if all conditions are valid for the transfer in multicast mode:
   • The size of the file to be transferred has to be larger than the size defined in the configuration parameters.
   • A minimum number of clients must have replied to the announcement.
   • The maximum retry number must not yet were reached.
   • A delay is necessary before the start of the notification, to allow clients to answer to the assignment.
   • In multicast mode the relay never informs the clients that files are available.
     After all parameters were verified and found to be valid, the notify thread informs the multicast thread by setting a flag (TransferToBeStarted) to start sending the file in multicast mode.If one parameter is found to be invalid the transfer will start as well, but it will be sent in unicast mode.
2. Client Unicast Reception
   If the client is online and has received the notification from the server, the client:
   • starts listening on the specified address and port, and
   • replies to the server that it has received the notification and is listening.
     If target clients are currently not connected or are nomads, the multicast parameters may be specified in such a way, that they can send back their request when logging on, and still have the opportunity to recover all data frames without having to reschedule the software delivery.
3. Multicast Data Transfer
   The server waits for the specified delay and then begins to send blocks of the file to be transferred. The header of each block contains the starting and stopping offset of the file. The client receives the block, determines its position and inserts it in the file. No processing of the file will be carried out until the client has received all blocks and the file is complete.
   Clients that did not receive the announcement the first time, because they were switched off, for example, will receive further notification by the server. Depending on the parameter settings either of the following situations can ensue:
   • Based on the number of requests, the server will again decide whether to use multicast or unicast transfer for the retry.
   • If the number of retries is set very high, the blocks of the file continue to be sent through the network and the clients, which just relogged on to the network, can start recuperating the blocks.
4. Post-Transfer
   At the end of the first transfer of all blocks, the relay asks the clients if they have recovered the complete file. In this case they stop listening. If it is missing blocks it will wait for a retry to recover the missing pieces. If the file is not complete when the multicast mode is stopped according to the retry parameter (MulticastRetry), the relay demands the client to stop listening. The multicast transfer can also be stopped after a transfer if the specified success rate (MulticastMinimumSuccessRate) is reached. After the transfer the retry parameter will be reset to allow for a new multicast delivery of this package.

Due to the fact that Multicast is integrated with the Transfer Windows node of the console, the use of this protocol is generic and no specific configuration is required for each distribution. The parameter settings for the multicast functionality are defined in the configuration file of the FileStore module, FileStore.ini , of the server which sends the data.

The following topics provide more information about using multicast software delivery:

• Configuring multicast
• Locally accessing multicast delivery information