[robocup-small] New Referee Box Protocol

[Christopher Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

There is no such thing as TCP broadcast/multicast. It doesn’t make
sense, because recipients can set arbitrary window sizes which need not
be equal to each other, so the sender may have to tune each segment to
each recipient individually, meaning a single Ethernet frame can’t be
shared between multiple recipients. TCP only exists in unicast
point-to-point form, where you would send data to each recipient
separately. You can fake TCP multicast if you try hard enough by
sending data to each recipient in turn, but that’s NOT true multicast:
it uses bandwidth linear, rather than constant, in the number of
recipients, and delivery is not simultaneous.

I still don’t understand why you want TCP. What benefit does it give
us? “Dynamic subscription/removal”? We already have that with UDP
multicast: it’s called IGMP (i.e. multicast group joining) and is
handled by the OS kernel for us for free. Reliable delivery? TCP isn’t
magic, it just does retransmission. We do retransmission too, just with
lower overhead.

My rationale for keeping the referee box and the vision computer
separate is simply that it’s hard for two people to sit and watch one
computer. The vision expert needs to keep an eye on SSL-Vision and be
immediately ready to handle vision issues, while the referee box
operator needs to be at the keyboard of the referee box and have the
various timers and readouts onscreen. Dual-screen on one computer might
work, but you would still have the problem of only one keyboard shared
between two people. Low-end computers are cheap, and the referee box
doesn’t require powerful hardware, so why not go with the easy way and
give each person their own box?

Chris

On Mon, 12 Nov 2012 12:05:43 -0500
Joydeep Biswas <joydeep at cmu.edu> wrote:

> Some thoughts:
> 
> 1. Timestamp: Any format with precision better than millisecond is
> fine. Like Angelo said, to maintain consistence, it's best to stick to
> the same type for both vision and the referee.
> 2. Timestamp and counts: I agree with Chris. They are both useful, and
> even if you drop a packet, it is important to know (for log analysis
> later) that you did drop it, not that a packet was not sent.
> 3. UDP vs. TCP: We're currently using UDP just for the ease of
> programming. Every other feature that we want, including dynamic
> subscription / removal and subnet broadcast is perfectly doable in
> TCP, and there are numerous programs with these features implemented
> with TCP today. I do however agree that coding this would be more
> involved, and especially since I'm not volunteering to do this (yet),
> I'll live with the UDP solution.
> 
> On a somewhat related topic: Why not combine the referee and vision to
> a single computer? The referee program takes negligible resources, and
> using the same computer for vision and referee would obviate the time
> sync issue between vision and the referee (especially if they both
> used the same format :) ).
> 
> -Joydeep
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEAREDAAYFAlCh/IQACgkQXUF6hOTGP7dLrwCdHXnXL5LCQFTtldHTwUu0x0H4
GBoAnA2gduuSbCXo8KQhqUlt9VdYJLZl
=MUYn
-----END PGP SIGNATURE-----