Hello all,
Been on this list since the beginning.. :-) But dont work in Robocup anymore.
My research revolves around networks. Which is why Im finding much of the
discussion quite interesting.
Someone mentioned that after using tcpdump that they were able to verify that
packets were infact being delivered to the clients, but that the packets were
lost in the stack somewhere. Overflow? The UDP buffer is 64K by default. This
can be increased.
Typically, unless you are going over an "Internet", UDP should not be too bad
for local connections. Yes it will suffer if you have a bad switch, packet
rate is very high, and there are many clients. Buffers do overflow. But
realistically error rates are quite low.
I think you need to start from the basics first:
How many packets per second are sent from the server to the clients and vice
versa?
This will give you some idea of the load on the network connections and on the
buffers.
you may use "netstat -s" to look for buffer overflows.
Has anyone tried running both server and client on the same machine?
Are packets still lost? If so, then it may be buffer overflow or some other
obscure bug.
Has any looked at how things are done in the Robocup - Simulator league?
Ive forgotten myself, but the server seemed reasonably good at the time
(1999).
Kind regards,
Justin
On Thursday 02 September 2004 09:03, Miguel Arroz wrote:
> Hi!
>
> I brought this TCP subject to the mailing-list some weeks ago, and I
> will try to explain the problem the best I can (english is not my
> native language).
>
> I am developing a client-base for the RoboCup Rescue in the LISP
> language. The main reason is that LISP is a very, very powerful
> language, with features you can not find in other popular languages,
> and it's really easy and fast to develop agents with a very interesting
> behaviour in this language. I'm sure many of you do not agree with me,
> or may agree, but even so, they prefer other languages for some reason.
> That's OK, and I think that having more choice on the base language is
> a good thing. Someone asked about a Python base, and I think that's
> great.
>
> Because of this, I had to carefully analize the protocol
> specification, and it's implementation in Java (because, unfortunately,
> the documentation is not updated, and some modification were only
> reflected in the code, not the docs). I found out some bad things. For
> example, the Java implementation doesn't check a lot of stuff (it
> doesn't even check the magic number, so a "strange" packet may arrive
> to the machine, on the same port, and the program may simply crash).
> But, worst of all, the protocol does NOT work. More exactly, its
> specification is not correct, so **there is no guarantee that it will
> work in any situation**. Obviously, if you have very fast machines, and
> a network segment just for your usage, the problem might never show up.
> But it's there, and, as Murphy well said, it will hit you on the worst
> possible time (probably in the middle of RoboCup 2005!).
>
> As I am developing the LISP kernel on my personal notebook (an Apple
> Powerbook G3 @ 500 Mhz), I cannot say that my machine is fast, for
> todays standards. Even worst, my server is a Pentium 4 @ 3 Ghz, so it
> pushes information very fast, and the powerbook cannot handle it. I
> knew that I *could* loose packets, but anyway, I implemented most of
> the LISP base. And, surprise, surprise, I'm loosing packets. Right on
> the first message kernel sends to the agent, with all the world
> information. It's about 230 packets, and half of them do not arrive. As
> you described, they arrive to the network card, but not to the process.
>
> The main problem is that this is supposed to happen! UDP protocol
> does not offer you ANY guaratee. Even on the same machine, you simply
> DO NOT HAVE THE GUARANTEE that the information will arrive ok. Of
> course, in near-optimal conditions, that happens most of the time. But
> it's pure luck. And I think RoboCup Rescue should not be based on luck.
> If anyone wants to implement a protocol on top of UDP, that protocol
> MUST be fault-tolerant. That means the protocol MUST be ready to
> recover from failures that may include "strange" packets arriving
> (packets from other computer, not expected), packets not arriving in
> the right order, repeated packets, and lost packets. It's obvious that
> the RocoCup protocol does not support some of this features, so it
> cannot be done over UDP, because there are no guarantees that it will
> work (and as you may see, several people are having problems).
>
> This is why I think that building a UDP-TCP bridge is no solution at
> all (in the end, it will make the problem worse, because it's another
> process slowing down the computer), and it will be a lot of work for
> nothing. If we are decided to make a good solution, we have to improove
> it's quality, and build a good working base. We should NOT make hacks,
> that solve nothing, require work, and that may delay the right solution
> to be made (because, if people are busy doing the hack, they cannot be
> doing the "good thing").
>
> I hope I have made my point clear. Is there is something that you do
> not understand, due to my english, or some other reason, feel free to
> send mail.
>
> Yours
>
> Miguel Arroz
>
> On 1 de set de 2004, at 8:00, Cameron Skinner wrote:
> > I'm not sure if the TCP-UDP bridge idea will fix the problem or not,
> > largely because no-one seems to know exactly where the problem is. For
> > example, I used tcpdump to track all packets going between our
> > simulator
> > machine and our agent machine. As far as I could see every packet that
> > was
> > sent did arrive at the agent machine's network card, but some did not
> > make
> > it to the agent processes. This suggests a buffer overflow, or possibly
> > malformed packets. On the other hand, when both the simulators and the
> > agents are run on one machine there are no lost packets - which
> > suggests a
> > network problem rather than an OS buffer problem.
> >
> > In short, we do not know what the problem is. Perhaps someone
> > (preferably
> > the person who suggested the idea) could implement the TCP-UDP bridge
> > and
> > let us all know how it performs.
> >
> > In the meantime, do we have any volunteers to take responsibility for
> > migrating the kernel and simulators to TCP? Come to think of it, a good
> > first step would be to create a robocup rescue library in C. I've just
> > added a module to the CVS repository on sourceforge called librescue -
> > feel free to start writing stuff and submit it via the sourceforge web
> > page (only the Technical Committee have commit rights on the CVS
> > repository).
> >
> > Cameron Skinner
> > TC Chair
> >
> > --
> > Cameron Skinner
> > Artificial Intelligence Group
> > Department of Computer Science
> > The University of Auckland
> >
> > email: cam@cs.auckland.ac.nz
> > phone: +64 9 3737599 x82924
>
> "I felt like putting a bullet between
> the eyes of every Panda that wouldn't
> scr*w to save its species." -- Fight Club
>
> Miguel Arroz - arroz@guiamac.com - http://www.guiamac.com
-- Smart Internet Technology Cooperative Research Centre University of New South Wales, Sydney, Australia http://www.cse.unsw.edu.au/~justinl
This archive was generated by hypermail 2.1.3 : Thu 02 Sep 2004 - 02:23:08 GMT