Fog Multicast Sessions: What happens when a host in session is powered off and what happens when it is powered back on?

[Sebastian Roth]

@zacadams Sorry, I meant below 421… see here. To add the --retries-until-drop option insert a field into the $buildcmd array. Let us know if you need assistance with coding.

[Szeraax]

@tom-elliott

have full controls

This would be cool. I don’t use multicast currently cause I’ve used it on a prod network midday before… But, being able to do stuff like “rolling multicast” where the sender will start over for clients that joined later and get them all to completion ASAP (maybe that’s a thing that udpsender already does and I’ve missed it). etc.

[Tom Elliott]

@szeraax by full controls I simple meant joining /leaving sessions/clients while still being able to image. Rolling multicast doesn’t make sense to me as it would cause the whole session to wait until the other “behind” are catching up. This would seem to be more appropriate, then, as a unicast. At least in my eyes. Of course as @Sebastian-Roth stated, this would be a massive undertaking just getting what I hope.

[Szeraax]

@tom-elliott I mean rolling as in:

If the multicast is 50% done and a new client connects, it will begin writing at the same block as the others. Once all others complete, the storage node sees that there are clients who aren’t done. Asks them what block ranges they still need, and then gives out those blocks. Thus, I could start a multicast and join any number of clients while it is going. Assuming that the last one joins before the first one finishes, the total data sent would be less than 2x the image. Additionally, the first client was not slowed down in any way by the new clients joining.

a la, a feature that I think Ghost had once upon a time.

[zacadams]

@sebastian-roth I apologize again they have had me bouncing around all last week so I haven’t had a change to test the
–retries-until-drop option yet. I’ll report back this morning about what I find.

[zacadams]

@sebastian-roth that did not appear to do anything.

[Sebastian Roth]

@zacadams What exactly did you try? Which values? Did the udp-sender calls on the FOG server look different according to the changes you made in the code? Check with ps ax | grep udp on the console while a multicast task is scheduled.

[zacadams]

@sebastian-roth to line 421 I have changed to:

$buildcmd = array(
            UDPSENDERPATH,
            (
                $this->getBitrate() ?
                sprintf(' --max-bitrate %s', $this->getBitrate()) :
                null
            ),
            (
                $this->getInterface() ?
                sprintf(' --interface %s', $this->getInterface()) :
                null
            ),
            sprintf(
                ' --min-receivers %d',
                (
                    $this->getClientCount() ?
                    $this->getClientCount():
                    self::getClass('HostManager')->count()
                )
            ),
            sprintf(' --max-wait %s', '%d'),
            (
                $address ?
                sprintf(' --mcast-data-address %s', $address) :
                null
            ),
            (
                $multicastrdv ?
                sprintf(' --mcast-rdv-address %s', $multicastrdv) :
                null
            ),
            sprintf(' --portbase %s', $this->getPortBase()),
            sprintf(' %s', $duplex),
            ' --ttl 32',
            ' --nokbd',
            ' --nopointopoint',
            ' --retries-until-drop retries 100',
        );

This has been done to the main fog server and the fog storage node that will be performing the multicast session. The udp-sendercalls did look different in the logs as well.

[zacadams]

Oh lord I see what I may have done wrong, I need to remove the retries. Let me try this again this morning.

[zacadams]

@sebastian-roth ok after fixing my error to the multicasttask.class.php I ran the 3 tests you suggested

• do not turn off any of the clients to see if it still is reliable

• pull the network cable of one of the clients while multicast is on for 5 seconds - see if that is enough for it to be dropped already

• turn off one of the clients while multicasting and see how long it takes for it to drop

During the first test, multicast worked normally and the new argument added to multicasttask.class.php was reflecting in the logs. During the second test pulling the network cable did not appear to drop the disconnected host, but upon plugging the network cable back in the session returned to normal speeds. During the last lest of powering a client off during a session, the multicast session came to a near halt and is only transferring at around 100 MBpm. I’ve left the session going all night and the session is still active and moving at the throttled pace.