GitLab

handling.

with tag fragmentation which can causes us to not find any free tags
even there are plenty. Add some debugging when we do fail to find
a free tag.

profiles. Problems still perist, I am sure.

Ultimately, this needs a lot of rewriting to make the control flow
more obvious and less fragile.

Two different fixes here.

The first affects frisbeed ("the server") and frisuploadd ("the uploader").
In both, the master server was choosing the port to use as an obscure function
of the current value of emulab_indicies frisbee_index without regard to whether
the port was already in use by someone else.

To fix this, the "-p <port>" option of both programs has been changed to
allow a value of 0 to indicate that the program (rather, the kernel) should
choose the first available port. It will also take a port range (e.g.,
"-p 50000-50100") which says to find the first available port in that range.
To communicate The Chosen Port back to the master server, there is a new
option to frisbeed and frisuploadd, "-A <file>", which says to write the
address info into the indicated file in the <IP-addr>:<port> format.
Note that we don't care about the <IP-addr> part since that is just the
multicast address (frisbeed) or our unicast address (frisuploadd) that we
pass in to the program. The "Emulab configuration" of the master server uses
the defs file FRISEBEEMCASTPORT and FRISEBEENUMPORTS vars to determine what
to pass via the "-p" option. See the comment in defs-example. The "null
configuration" (aka, on a subboss) just passes "-p 0" to frisbeed.

The second fix was an attempt to avoid port conflicts on the client side
(frisbee). There is only so much we can do since all clients of a multicast
frisbee session have to use the same port, but we can avoid conflicts with
other UDP apps that bind to INADDR_ANY:<port>.

We make use of the REUSEADDR socket option and bind specifically to
<mcaddr>:<port>. This also requires that the server multicast the JOIN
reply that was previously unicast. Note that use of REUSEADDR will also
allow multiple frisbee clients on the same host to be in the same session
(not that we ever do that).

Since the server is typically updated whenever the Emulab software is, but
the client is embedded in images and MFSes, there can be pretty much any
combo of {old,new} server and {old,new} client in the field. So backward
compatibility was essential and there are a variety of implementation details
related to that. See the comment in network.c::ClientNetInit().