I figured out what was wrong, and the problem was udp-sender. I found a little bug in the source code of udp-sender, which caused udp-sender not being able to track the time that passed since the first connection.
I attached a diff patch to this e-mail which fixes that issue. If you apply this patch to udpcast and recompile udp-sender, it should wait correctly according to the parameters you pass. It works great now over here. * Attached: udpcast-waitfix.patch On a side note, I came across a few other things on my 'quest for flamethrower multicasting': - the flamethrower_client function in /etc/init.d/functions of the ramdisk does not remove /tmp/multicast.tar after untarring it. In some situations, in particular with small .tar's (i.e.: the flamethrower autoinstall scripts dir) the udp-receiver doesn't recreate the file correctly and the .tar becomes corrupt. * Adding 'rm -f /tmp/multicast.tar' to that function, after untarring, fixes this. - there is a other little bug in the flamethrower_client function in /etc/init.d/functions. The COUNT variable is never initialized and set to 0. This causes that udpcasts are not retried correctly, in stead of the default 7 times or specified number of retries. * Adding 'COUNT=0' to the top of that function fixes it. - flamethrowerd has a small bug; when a PORTBASE is set for one of the modules in flamethrower.conf, it keeps on trying to start udp-sender for that module, and overwriting the .pid file in the state dir. This causes that some udp-sender processes are not killed when using the init.d script to restart/stop flamethrower. * Workaround: don't specify a PORTBASE :) Perhaps one of the code maintainers could have a look at these issues and/or apply these fixes? Over here, we now have multicasting images working, after fixing the issues above. I hope this information is of any use for anyone. Kind regards, Ramon. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sisuite-users- > [EMAIL PROTECTED] On Behalf Of Samuele Tognini > Sent: donderdag 27 mei 2004 20:24 > To: [EMAIL PROTECTED] > Subject: R: [Sisuite-users] _multi_ casting -> udp-sender does not wait? > > I had the same problem, and i did not resolve it in a good way. > Anyway i got multicast to work on redhat 9 (after some little manual > changes > in source code and master script ). > To get all pc to start all the same moment, i dind't start flamethrowerd > service till all clients were waiting for udpcast server ( in fact if the > udp client does not connect the udp server then it remains in wait). > > Regards, > Samuele Tognini > > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Per conto di Ramon > Bastiaans > Inviato: gioved� 27 maggio 2004 9.56 > A: [EMAIL PROTECTED] > Oggetto: [Sisuite-users] _multi_ casting -> udp-sender does not wait? > > Hi, > > I have been working on getting multicast systemimager image broadcasts > to work, but I am having a hard time. > > After testing with flamethrowerd, I tried manually casting with the udp > sender and receiver, to see if that would work. > > Is it just me (am I doing something wrong?) or does udp-sender > completely ignore the wait and client parameters? > > Udp-sender doesn't wait at all for a minimum number of clients, after > the first connection, it immediately starts the multicast to the first > client. > > On the server: > > # udp-sender --pipe 'tar -B -S -cpf - -C /home/test/sara/ramon/testdir . > ' --portbase 12345 --min-clients 20 --max-wait 1800 --min-wait 600 --fec > 8x8/128 --interface eth0 --max-bitrate 20M --full-duplex --nopointopoint > --nokbd > stripes=8 redund=8 stripesize=128 > Udp-sender 2004-02-22 > Using mcast address 234.168.44.1 > Compressed UDP sender for (stdin) at 10.168.44.1 on eth0 > Broadcasting control to 10.168.44.255 > New connection from 10.168.44.5 (#0) 00000019 > Starting transfer: 00000019 > bytes= 11 929 600 re-xmits=000000 ( 0.0%) slice=1024 73 709 551 > 615 - 0 > Transfer complete. > Disconnecting #0 (10.168.44.5) > > On the client: > > # udp-receiver --interface eth0 --portbase 12345 --nokbd --nosync --file > ./bla.tar > Udp-receiver 2004-02-22 > UDP receiver for ./bla.tar at 10.168.44.5 on eth0 > received message, cap=00000019 > Connected as #0 to 10.168.44.1 > Listening to multicast on 234.168.44.1 > bytes= 11 929 600 ( 15.91 Mbps) 11 929 600 > Transfer complete. > [EMAIL PROTECTED]:~/1.udptest$ > > > Now there is no timestamps, but the udp-sender starts the multicast in > about 2 seconds after the connect from the client. But the sender does > not have 20 clients connected, and it didn't wait 10 minutes at all (I > kind of overdid the values here, but with lower values it doesn't work > either). > > Am I missing something? I would be happy to hear if anyone got the > _multi_ cast to work or has any tips. > > > Kind regards, > > Ramon Bastiaans. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id149&alloc_id�66&op=ick > _______________________________________________ > Sisuite-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/sisuite-users > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id149&alloc_id�66&op=ick > _______________________________________________ > Sisuite-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/sisuite-users
udpcast-waitfix.patch
Description: udpcast-waitfix.patch
