Multicast Procedure Questions
I’ve been using FOG for a year or two now and love it. However, one thing that still confounds me is how the multicast feature works. I have a couple (semi)specific questions:
How does the ‘Timeout’ function? In previous imagine solutions I’ve used every time you join a new client to the multicast it restarts the timeout, but that doesn’t seem to fit the way I see FOG multicasts function.
If clients don’t join catch the multicast before the timeout hits, they seem to just sit there patiently, not doing anything. Will the multicast restart at the end of the push, thereby catching the latecomers?
I’ve tried using the ‘Multicast to group’ feature in the past(I think one version ago), but it never worked for me(and seemed to be broken on the coding side from feedback I had got at the time), and I haven’t tried with the current release, is it more functional at this point? Or is it a layer 8 issue on my side?
I appreciate your patience and responses, I know most of this I could probably figure out by trial and error, but I’m extremely multi-hatted and short on time(aren’t we all?) and sometimes it’s easier just to get feedback from those who know rather than experimenting myself. (also, I hope these haven’t been answered before, I tried to search but that link seems to be broken for me…)
@george1421 thank you for your responses. The timeout is fine the way it is, as long as I understand how it functions. Just need to turn it up while I join 100 clients to it. Though, since you say it’s probably a layer 8 problem on the group based multicast, I’ll try to find the time to run a few experiments on my side and see if it’s now working. I have a fairly simple network (air gaped single subnet educational lab), so that shouldn’t be the issue.
The repeating multicast would be handy but, as you say, there are certainly potential issues there as well. Again, as long as I understand the mechanic I can work with it! Thanks again for your answers(and all your help in the past as well).
@george1421 timer begins after the first machine connects to the udpsender
Lets see if I can address these based on what I know so far @Developers please correct me if I’m wrong.
- The multicast timeout is based on when the task is initiated on the FOG server. It doesn’t get reset as new clients join the stream. I can see the logic in your request to reset the counter on each client that joins the stream, but I can also see the value in having an absolute timer too.
- Not the multicast stream is one shot, if a client misses the stream it misses the stream. It might not be too hard to add this feature, but there would have to be some kind of trigger, like min clients not met otherwise I could see it looping forever or a new client possibly picking up on the wrong stream.
- I can’t speak to the multicast being broken, I wasn’t aware of this maybe a developer can chime in here. I know from a multicast standpoint it works out of the box when the client and fog server are on the same subnet. If you need to cross subnets then your subnet router needs to support multicasts or you need a multicast router to send traffic across. Successful multicasting is more dependent on your infrastructure capabilities than FOG related issues.
 thinking about this a bit more (reset timeout on connect), that would be the function of udpsend. Once FOG schedules the udpsend task, udpsend/udpreceive is managing the multicast stream. So if a timeout reset on connect is needed it will have to be added to the udpsend code, not specifically FOG.
imt_fog last edited by
@flipwalker +1 for your question no. 3
I also noted that behavior, and considered it as a configuration issue because we just started to deploy multicast on our core routers and switches. We want to deploy with multicast (ee have 1180 clients in about 50 lab rooms) and manually joining a session is quite annoying even in only one lab room.
Hence I am willing to to dig a bit in the source code - if someone has an idea where to start I’d be thankful!