[Udpcast] Timing problem with starting PXE boot and udp-sender
dteed at artistic.ca
Thu Apr 29 21:20:24 CEST 2004
On Thu, 29 Apr 2004, Alain Knaff wrote:
> The idea is simple:
> - when receiver starts, it sends out CONNECT packet
> - when sender starts, it sends out HELLO packet
> - on recept of HELLO, receiver tries CONNECT again.
> With this, it does not matter whether receivers or senders are started
> up first, at least in theory:
> - if receiver starts first, it's the sender's HELLO that triggers the
> successful rendez-vous
> - if on the other hand the sender starts first, it's the receiver
> CONNECT that triggers the rendez-vous.
> Now, in your case, what may be happening is the following:
> - due to the flakiness of the card, the card may not yet be ready to
> send once udp-receiver starts up, and thus the CONNECT is not really
> sent. In case you start the sender afterwards, this doesn't matter,
> because by the time the sender sends it HELLO, the receiver is ready
> to receive that message and reply to it.
> - for those receivers that needed a reboot: if these start after the
> sender, there is no HELLO.
If a CONNECT can trigger the rendez-vous, then if I notice a certain
number of machines not connecting, I should be able to simply
reboot them and have them try this again. The wierd thing was
that we tried that, and the same 4 machines did not rendezvous
while 11 were standing by ready. That was what led me to conclude
there was a window of time to rendez-vous and it had elasped.
However on a third session the 4 missed machines were included in
a new batch and did get imaged OK.
> > I checked the options and I don't see any that are designed to increase
> > how long it will wait to see more machines responding as ready.
> There is the "--rexmit-hello-interval 3000" option which instructs
> the sender to keep on resending its HELLO packets until transmission
> is started. The number is the interval, in milliseconds, between to
> HELLO packets. This might solve the issue.
> udp-sender --rexmit-hello-interval 3000 --file fileimage.gz
OK, cool, that might be useful.
There are a few things I need to test. I can try substituting
the switch involved. In general the client machines are a
little unpredictable since they were carried around daily by
University students for 2 or 3 years.
More information about the Udpcast