[robocup-small] New Referee Box Protocol

[Christopher Head]

Thanks for the comments! With respect to using floating point instead
of integer timestamps, I don’t see much point (NTP is unlikely to get
much better than millisecond synchronization anyway), but there’s really
no reason not to either. If you want FP, and nobody else says anything,
I’ll go with FP.

With respect to using TCP, I disagree. I think UDP actually suits our
situation better. First, UDP allows us to use multicast so all the
teams receive the packet at exactly the same time; TCP would require us
to rotate between the teams and send updates to them one at a time.
Second, TCP would require us to maintain a collection of sockets and
handle new and closing connections, increasing code complexity. This
would also introduce the need to start up the referee box and the
teams’ AIs in the proper order (presumably refbox first), whereas
today, those can be started in any order and the refbox can even be
restarted while a team’s AI is running. Third, I believe TCP would
actually give us exactly the same level of reliability but with lower
performance: in TCP, if a packet is dropped, you have to wait for the
timeout to expire before it’s resent. The current referee box protocol,
and the one I proposed, just send the UDP packets unconditionally at a
fixed frequency. This means you already have automatic resending to
deal with dropped packets, and the longest time you can possibly wait
is 100 ms (and we could reduce this if we wanted). With TCP, you would
have to wait for the retransmit timeout before getting the data.
Finally, TCP gives you a byte stream while UDP maintains message
boundaries, so with TCP we would have to add length prefixes, making
both the sending and receiving code more complex.

Are you aware of any problems that UDP has caused with either the
referee box or SSL-Vision? I personally haven’t seen any problems.

Chris

On Fri, 9 Nov 2012 09:27:46 -0500
Joydeep Biswas <joydeep at cmu.edu> wrote:

> Hi Chris & the rest of the TC,
> 
> It's good to see the referee protocol be modernized. I have a couple
> of recommendations:
> 
> 1. The time stamp should be a double precision float (float64), in
> terms of epoch time in seconds. This will allow precision of up to
> fractions of microseconds (see calculation [1]), and can be used for
> time comparisons much more easily. Code for GetTimeSec() in [2]. These
> time stamps are only as meaningful as the synchronization of the
> clocks between the computers. Therefore, I recommend that the referee
> computer be configured to run ntpd. Teams can then sync times with the
> referee.
> 
> 2. We should move to TCP. The additional couple of microseconds of
> latency is a minuscule price to pay for the reliability gain.
> 
> Regards,
> Joydeep
> 
> [1] Current epoch time in seconds (only order of magnitude important),
> divided by 2^(mantissa bits) =  1352471098 / (2^52) = 0.3 usec
> 
> [2]
> double GetTimeSec() {
>   timespec ts;
>   clock_gettime(CLOCK_REALTIME,&ts);
>   return( static_cast<double>(ts.tv_sec) +
> static_cast<double>(ts.tv_nsec)*(1.0E-9));
> }