Pooched the backward-compat case.
I thought I would be clever and check the client ID on a JOIN reply to make sure we match up the proper request/reply (an issue when replies are multicast). However, on a JOINv1, the reply does not include the clientid. Unfortunately, for previous backward-compat situations, we still do generate JOINv1 requests most of the time. So for JOINv1's we don't try to check the clientid. This means that with a newer server that MCs replies, a JOINv1 client may see someone else's reply and start transmitting requests even before the server has seen that client's join request. This is not an issue for us right now since the server only loosely tracks its clients and does so just so that it can report stats when the client leaves. I say "loosely" because, e.g., the server does not require that block requests come from a JOIN'ed client.
Showing with 4 additions and 2 deletions