• Mike Hibler's avatar
    Avoid (as best we can) port collisions on the frisbee client/server/uploader. · 0a7fd856
    Mike Hibler authored
    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().
config.c 14.3 KB