[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Agents in C++ or OTcl?
Hi
I guess we just followed the existing design patterns largely - the
thre bits of UCL work (a weighted proportional fair TCP, a reliable
multicast transport and self orgnising distributed transcoders)
represent both approaches - the TCP stayred with the agent code as per
existing TCPs - there's no reason really to change it much, unless we
wanted to play with a lot of different variants within the same
simulation run maybe
the rlc work and sot work involve a first pass at getting the protocol
itself right (typically joint design of real implementation
and simulator code, or even a large degree of shared code if all goes
well) whereas the "realworld" agent would be soemthign that is part of
an application, and therefore has a lot of realworld complexity tro do
with the OS environment (e.g. in extremis, is something thast sits
above winsock or sockets) whereas an angent in the simulation is
simple, and therefore doa-ble in Tcl, but is also typically quite low
on event complexity (start something up, stop it, ask it things) sites
well in Tcl, while everythign thats hard to get right (looks like a
state machine, and operates on packet arrival, timers firing) goes
in C++
of course, on re-reading this, i think it should all be re-written in
realtime smalltalk:-)
In message <[email protected]>, Kannan Varadhan typed:
>>Hi Jon,
>>
>>> let me know if you want anything else!
>>
>>> p.s. i'm still trying to collect our thoughts generally about hat we
>>> did in each case....
>>
>>On how you did your implementations, and the OTcl/C++ split,
>>how about responding to this question on the ns-users list?
>>
>>--------------------------------
>>Date: Mon, 2 Mar 1998 12:53:06 UTC-0800
>>From: Jining Tian <[email protected]>
>>Cc: [email protected]
>>Subject: Agents in C++ or OTcl?
>>
>>There are two flavors of simulation in ns: writing Agents in C++ as in
>>the tcp related simulations and writing Agents in Otcl as in multicast
>>related stuff. I personally prefer the former, but I'd like to hear
>>some analysis from the experts, especially on the performance, memory
>>consumption, debuging, etc.
>>
>>Thanks in Advance,
>>
>>Albert
>>--------------------------------
>>
>>Thanks,
>>
>>
>>Kannan
>>
>>--
>>[email protected]
>>http://www.isi.edu/~kannan
cheers
jon