We use udpcast in an environment somewhat based on systemimager but
highly modified.
We have run in to a very sad situation where a particular model of switch
decides it doesn't want to pass the multicast data packets and none of them
get through. It is an extremely hard problem to duplicate because it seems
to work 99% of the time.
The end result when we hit the problem is the udp-receiver "waits forever".
So I've begun to consider setting some additional timeouts in the system
to try to work around this switch problem.
I investigated receive-timeout and start-timeout. Since I'm never able
to reproduce the problem "on demand", I emulated the problem by using
iptables to block the data stream packets.
I found that receive-timeout isn't in play in a situation where not one
data channel packet has been sent. However, start-timeout is in play.
There seem to be a couple select()-like situations that use the start-timeout.
Prior to the "Connected as" message in udp-receiver, if you hit start-timeout
there, udp-receiver will exit with an exit code that can be captured by a
script for a re-try. However, the selectWithConsole() call in
dispatchMessage(), while returning a 0 on select timeout, the caller
(netReceiverMain()) doesn't test the return value of the timed out transfer.
It turns out selectWithConsole is where I hit the timeout for the "no
multicast data packets transferred" problem.
After digging further, I realized this is likely because there are threads
involved and this makes it more complicated to handle status.
I'm rusty with my C but I came up with a work around to get us going. I am
not suggesting that this is a good solution, but it does solve it for me
and could be used as an illustration of my problem. Maybe some of you
experts can quickly come up with the correct solution.
Basically, I exit with 100 if zero bytes were transferred. Then I can test
that easily in our scripts and re-try if needed in some sort of loop.
I realize the correct solution is to exit with an error code if the
selectWithConsole() call in dispatchMessage() times out, but it looked
hard to deal with when combined with my C-programming rust.
Other suggestions welcome. Attached is my "patch" for illustration reasons
and not a suggested "fix" for the problem.
Erik
