[robocup-small] New Referee Box Protocol

[Mani Monajjemi]

Hi All,

Thank you Chris for taking care of this. I have a couple of recommendations:

I think it is better to add "Team Name" as a string to the "TeamInfo"
message and extend RefBox software to facilitate setting these values. This
can be helpful for both logging and external match state display
programsthat may be used
during competitions.

There is a C++ class inside the current referee box source package
(called GameState
as far as I can remember) that can interpret the current refbox protocol. I
think it would be great if a similar interpretion facility is provided for
the new protocol.

I also agree with Joydeep's first suggestion regarding using float64.

Cheers,
Mani


Mani Monajjemi


On Fri, Nov 9, 2012 at 11:49 AM, Christopher Head <chead at chead.ca> wrote:

> 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));
> > }
> _______________________________________________
> robocup-small mailing list
> robocup-small at cc.gatech.edu
> https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cc.gatech.edu/pipermail/robocup-small/attachments/20121109/9546e07d/attachment-0001.html>