At first I was, but when I couldn't get the multicast senders to wait for the clients I tried manually running udp-sender and receiver.
This to take flamethrower out of the equation and to pinpoint what was causing it.
However, I already found the bug, and made a patch for it this morning.
The problem is the time struct udp-sender uses to store the time at which the first receiver connects is never initialized to 0, while a if statement later on assumes that the value is 0 if no receiver has connected yet.
This causes the udp-sender doesn't know the time of the first connected client and that it doesn't wait
The fix is initializing the variable correctly and setting it to 0.
I have attached a diff patch which corrects it, it works great now :)
Regards, Ramon.
-----Original Message----- From: Brian Elliott Finley [mailto:finley@mcs.anl.gov] Sent: donderdag 27 mei 2004 17:46 To: Ramon Bastiaans Cc: udpcast@udpcast.linux.lu Subject: Re: [Udpcast] udp-sender does not wait at all?
Are you using flamethrower to do this?
Thus spake Ramon Bastiaans (bastiaans@sara.nl):
Hi,
I have been working on getting multicast systemimager image
broadcasts
to work, but I am having a hard time.
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. ramon@u5:~/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?
Kind regards,
Ramon Bastiaans.
Udpcast mailing list Udpcast@udpcast.linux.lu http://udpcast.linux.lu/mailman/listinfo/udpcast
--
Brian Elliott Finley Argonne, MCS Division Mobile: 630.631.6621 Office: 630.252.4742 gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52
begin Friday 28 May 2004 10:46, Ramon Bastiaans quote:
At first I was, but when I couldn't get the multicast senders to wait for the clients I tried manually running udp-sender and receiver.
This to take flamethrower out of the equation and to pinpoint what was causing it.
However, I already found the bug, and made a patch for it this morning.
The problem is the time struct udp-sender uses to store the time at which the first receiver connects is never initialized to 0, while a if statement later on assumes that the value is 0 if no receiver has connected yet.
Thanks for the note. I put this into the new 20040531 version. RPM and images available at http://udpcast.linux.lu
Regards,
Alain
The next devel (3.3.x) and stable (3.4.x) releases of SystemImager will include this new release of udpcast.
Thanks, -Brian
Thus spake Alain Knaff (alain.knaff@lll.lu):
begin Friday 28 May 2004 10:46, Ramon Bastiaans quote:
At first I was, but when I couldn't get the multicast senders to wait for the clients I tried manually running udp-sender and receiver.
This to take flamethrower out of the equation and to pinpoint what was causing it.
However, I already found the bug, and made a patch for it this morning.
The problem is the time struct udp-sender uses to store the time at which the first receiver connects is never initialized to 0, while a if statement later on assumes that the value is 0 if no receiver has connected yet.
Thanks for the note. I put this into the new 20040531 version. RPM and images available at http://udpcast.linux.lu
Regards,
Alain
-
Alain Knaff -
Brian Elliott Finley -
Ramon Bastiaans