Dear all,
let me thank you to Zijian and Mohsen for openning such discussion - earlier I
was trying to do so, but without any response from RR community.
About the message length - I think, that there is a question, what HW equipment
(e.g. WiFi or other technology) and protocols should be used for interagent
connection in a real situation. Common length of a packet in UDP or TCP/IP
protocol is in rank of kB (maybe among 2 and 8 - I don't know - maximal is
about 65kB I think...). In addition the packet/message either
comes OK or not - so restricting length to hundrets of bytes according
to "realistic conditions" I don't understand. The number sent/received of
messages restrictions - it's a good idea, of course. But I think that important
is to agree together what is the reason of such restriction. One such reason
could be, that the agents would be able to process only some final number of
messages. OK, but why to restrict them in an opportunity to choose them as much
intelligent way as possible and allow an only attribut (sender's ID - 12kkId)
in message header to choose a message to be read? An impotant question is, what
is more important: to make unbrokable rules for RR competitions or to develop
useful multi-agent system for planning and coordination rescue operations?
Actually one could think that RR is focused more on RR competitions than on
development of a rescue support system. If the second is more important I have
to treat 12kkId as ungroundedly restrictive. If RR supposes robotic teams and
devices of digital assistence for rescuers, there is a robust communication
and message filtration to be developed under conditions of very "small"
communication volumes (that in praxis are rather kB than hundrets of bytes) and
unreliable connection (e.g. unaccesability of the agent that would be too far
from others or from the communication backbone). On one hand I think that the
RR MAS realization should not stand on a massive communication, on other hand I
think that the dicussion should be based on capabilities of existing
technologies. A question is: is there such technology, usable in such disaster
environment, that would be able to support actuall communication support
supposed in RR? Does actuall communication restriction really meet real
conditions? Would a real communication system really restrict communication
between agents if there were free communication means? And would such system
really guarantee delivering e.g. 4 messages to every agent (actually the
allowed number of messages is chosed by agents according to fair-play rules,
but in this context it is only a detail) in spite of a momentary communication
jam and overload of communication system? I think that these are more important
topics to discusion than whether message should have 80 or 256 bytes ;).
To be it clear, I do not kick again communication restrictions. It is very
important not to omit them!!! If I should mention one impotant think that RR
brings, it would be a fact it is a good testbet for developing new protocols
and technologies for interagent coordination and cooperation under hard
communication restrictions (e.g. if I mention commonly used CNP protocol - in
RR it is unusable for mobile agents in roles of contractors - the contractor
cannot evaluatethe all the offers of competing agents if there vere more than 4
competing agents - there is to be developed other way of closing coalitions).
But I think that communication restrictions should be built on more realistic
grounds than are those actual (to be honest I have no idea on which grounds are
the actually used rules built...).
If there should not be rebuilt all the communication in actual RR, I think that
the communication rules should allow agents to communicate more free (what does
not mean in a bigger amount) and more reflect real restrictions of existing
technologies. To be more concrete, I think that the message length could be
restricted to e.g. 2kB, there could be used e.g. some clone of FIPA ACL, that
becomes a standard in industry applications (messages should be only text
strings - binary encoding should be hidden in lower communication levels - e.g.
by some commonly used compression-decompression means - I thing that in RR we
could omit such technical detail and to restrict the messages not to contain
binary encoded data), the number of messages to be read/sent I would let be as
are, but I would give no restriction on messages' contents or I would devide
the message to header and body as it is actually, but with more rich header
allowing agents to choose (but only to choose) messages more inteligent way
than now (there could be built some intelligence in message choice according to
the actual only attribut - sender's ID, but very poor) and any handling the
message header data for other purposes than message choice I would claimed as
unfair - all the unreaded messages should be discarted as it is actually...
But a question is, whether - if the developers of simulators (blockades,
collapse, etc.) want to make the simulation more realistic - not to rebuild all
the approach to communication in RR to be also more realistic...
Best regards,
Jiri Biba
BB_Agents
Cituji z emailu od zijian <zren@engineering.uiowa.edu>:
> Dear Mohsen,
>
> > > but we need to cooperate with new changes in rescue
> > > 0.44. Rescue 0.44 uses
> > > random object IDs which is 9 bytes long while object
> > > IDs in old rescue is
> > > 1-4 bytes.
> >
> > IDs in rescue-0.44 are also 4 bytes long, it means
> > that a 32-bit Integer is being used for transfering
> > IDs(no change from rescue-0.43).
>
> New IDs are 4 bytes in hexadecimal and 9 bytes in decimer.
> Of course, we can convert between them and it just add the program
> complexity ( I use java).
> It is not a big issue.
>
> >
> > > One goal of rescue simulation, in my opionin, is to
> > > simulate the real rescue
> > > situation. We need to discuss which way is more
> > > realistic and popular in
> > > real rescue communication situation, very short
> > > messages (such as 80 bytes)
> > > or relatively long messges (such as 256 bytes)?
> >
> > We also think that it's a good point for discussion.
> > With a 256-byte message agents can easily share
> > dynamic properties of the whole city with each
> > other within just 2 messages. It certainly is not
> > the case in real rescue situations.
> >
>
> I agree that exchanging the whole city property may be too much.
>
> But even with 80 bytes limitation, there are deliberate methods to bypass
> it.
> For example, using several bits represents an information which is usually
> much longer in "normal" representation.
> Using special compression-decompression protocals, a long normal text can be
> compressed into a short special "text" for message passing.
>
> As I metioned before, the length may be not important. The evaluation of
> message should be subjective, examined by the technical committee and/or
> teams. In future, we may propose subjective standards for communication
> rather than a simple maximum length of message. One subjective standards may
> look like: Don't allow transfer whole city and agents' information.
> Simulation communication should follow limits of real communication.
>
> Hope other members in rescue simulation have better proposals in this
> communication issue.
>
>
> best regards,
>
> zijian ren
> phoenix team
>
>
>
>
>
This archive was generated by hypermail 2.1.3 : Mon 23 Feb 2004 - 14:25:27 GMT