Hi!
On 2 de set de 2004, at 8:27, Mahdi Milani Fard wrote:
> Well if you have buffer overflows that means the module is not reading
> from the buffer fast enough to get all the data recived on the socket.
Right. The problem is that you never have the guarantee that that
will happen. You may do a lot of hack-like optimizations, write obscure
code, etc, and make it REALLY fast, but you can NEVER say for sure
"there will be no problems at all". With TCP, you can.
> Even if it goes on TCP you still can not get all the data due to the
> slow
> module. You can increase the UDP buffer, but even with that, the
> problem
> would not be solved (please do change the buffer size and see if it
> makes
> any difference). The only thing that would change in the TCP
I alredy tested it with a bigger buffer. Naturally, it looses less
packets, but the problem still occurs. I'm having this problem right on
the beggining of the simulation, because the server sends a burst os
packets (more or less 230) to the client. There is no problem in
reading the packets a bit slower, because on the next second there will
be no messages at all. The problem is that the buffer overflows.
> commiunication is that you get the failaure masseges. But there is a
> problem here. TCP commiunication retries to send the packets if the
> dest
> computer does not comfirm that the packets are recived. If it fails
> for a
> few time, then it sends a faliure message to the sender. But what can
> you
> do if you find out that in 5 cycles ago a message was lost? You have
> the
> garantee that even if the packet is not recived, you'll get a faliure
> messaage. But it doesn't mean that you can do anything useful with
> that.
> The faliure message might be too late.
The question here is not failure, but flow control. TCP provides flow
control, and that is essencial for controlling the data transfer speed,
and not letting any buffer overflow. Of course, the network COULD loose
a packet, and your agent will loose some cycles, but that alredy
happens with UDP. Worse, with UDP you may crash the communication stack
of your agent (if you use the Java API, that will probably occur, look
at the code). So, there is nothing here that TCP will make worse, and
there are a lot of stuff TCP will make better. I don't really see why
should we stick with UDP.
> I believe we should be working to find the "real" problem here. As
> someone
> said, if the kernel and agent modules run on the same machine, no
> packet
> losts occurs which means that this is a network commiunication error.
> And
No it isn't, because Ethereal shows every packet arrive the
destination computer. The problem IS the system buffers. I belive the
problem occurs less frequently using everything on the same computer,
but it does occur, and, of course, it limits you to use the same
computer for everything. That was not the case in RoboCup 2004, where
you had to run your client on a separate machine.
> Well, I wanted to start a base in python. Python has many potentials
> that
> seems to nicely fit the needs for a base. As for YabAPI there are many
> usages of lists, properties, conditions and actions, and all of these
> can
> be easily implemented in python with much less labor than it would take
> for Java or C++. But as I'm a newbie here, I don't think I can do that
> by
> myself. We are a new team here in UT and it's a bit difficult for us to
> start a base from scratch. So if anyone is interested and wants to
> help,
> I'll be happy to start the base with the help.
I'm a newbie (not just for RoboCup, but for LISP) and I'm writing a
base in LISP! :-) Just take a deep breath, and go for it. It will give
you some work, but it's not a very complicated thing to do. Warning:
the protocol specification (on paper) is not updated. You will need to
check the Java code many times, specially to see what are the right
constants.
Yours
Miguel Arroz
"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
This archive was generated by hypermail 2.1.3 : Thu 02 Sep 2004 - 10:31:28 GMT