[robocup-small] New Referee Box Protocol

KANJANAPAN SUKVICHAI fengkpsc at ku.ac.th
Tue Nov 13 04:19:52 EST 2012


  

Dear all 

 I agree with Chris for UDP packet and two computers,
one for referee box and one for vision. 

 I also think TIMESTAMP is a
good idea. 

regards, 

KANJA 

On Mon, 12 Nov 2012 23:53:33 -0800,
Christopher Head wrote: 

> -----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 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-----
>
_______________________________________________
> robocup-small mailing
list
> robocup-small at cc.gatech.edu [2]
>
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small [3]

 


Links:
------
[1] mailto:joydeep at cmu.edu
[2]
mailto:robocup-small at cc.gatech.edu
[3]
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/20121113/51191dc0/attachment.html>


More information about the robocup-small mailing list