📄 j-sim evaluation.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0036)http://www.j-sim.org/comparison.html -->
<HTML><HEAD><TITLE>J-Sim Evaluation</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<H1 align=center>Evaluation of <I>J-Sim</I></H1>
<P align=center><EM><!--webbotbot="Timestamp" startspan s-type="REGENERATED"s-format="%B %d, %Y" -->October
17, 2003<!--webbot bot="Timestamp"i-checksum="30348" endspan --></EM></P>
<UL>
<LI><A href="http://www.j-sim.org/comparison.html#s1">1 Qualitative
Comparison</A>
<LI><A href="http://www.j-sim.org/comparison.html#s2">2 Quantitative
Comparison</A>
<UL>
<LI><A href="http://www.j-sim.org/comparison.html#ex1">2.1 Experiment 1</A>
</LI></UL></LI></UL>
<H2><A name=s1>1 Qualitative Comparison</A></H2>
<P>In what follows, we summarize notable research efforts on network simulation
and compare <I>J-Sim</I> against them wherever appropriate. Some of the
simulation packages are out-dated (but the results of which have been leveraged
in subsequent projects) and are listed here for historical purpose:</P>
<UL>
<LI><A href="ftp://ftp.cs.columbia.edu/nest/"><B>NEtwork Simulation Testbed
</B><B><I>(NEST</I></B><B>)</B></A> is a general-purpose simulation package
designed to simulate distributed networked systems and protocols. It provides
a client-server based graphical environment for simulation construction and
execution control.<BR>
<LI><B><A href="http://www.ccs.neu.edu/home/matta/software.html">Maryland
Routing Simulator (<I>MaRS</I>)</A></B> is a network simulation package based
on a general-purpose network simulator <I>NetSim</I> developed earlier. As the
name suggests, it is mainly used to study different routing algorithms.<BR>
<LI><B><A href="http://minnie.tuhs.org/REAL/">The REalistic And Large
(<I>REAL</I>) network simulator</A></B> is a substantially improved, and
faster, version of NEST and is designed specifically for studying different
congestion and flow control mechanisms in TCP/IP networks.<BR>
<LI><B><I><A href="http://www.isi.edu/nsnam/ns/">Ns-2</A></I></B> is part of
the collaborative <I>VINT</I> project involving USC/ISI, Xerox PARC, LBNL, and
UC Berkeley. <I>Ns-2</I> began as a variant of the <I>REAL</I> network
simulator in 1989, and has evolved substantially over the past few years. It
provides substantial support for simulation of TCP, routing, and multicast
protocols, but due to the special node structure in <I>ns-2</I>, it is
non-trivial, and sometimes difficult, to include other protocols/algorithms or
accommodate other network architectures in <I>ns-2</I>. In addition, the
not-so-structured software architecture and the mixture of compiled and
interpreted classes make it difficult to understand and validate ns-2
codes.<BR>
<LI><A href="http://dimacs.rutgers.edu/Projects/Simulations/darpa/"><B>The S3
project</B></A> and <A
href="http://www.ssfnet.org/homePage.html"><B>SSF</B></A> are collaboration
efforts of Rutgers University, Dartmouth College, Georgia Tech, and Boston
University, and come closest to our proposed work. The project focuses on
distributed and parallel simulation for large network simulation and proceeds
along two fronts: design and implementation of (i) a simulator-independent
network modeling framework, called Scalable Simulation Framework (SSF); and
(ii) parallel and distributed simulation kernels (such as Georgia Time Warp
(<I>GTW</I>)). SSF consists of 5 base classes: Entity, inChannel, outChannel,
Process, and Event, and defines APIs to separate simulation modeling from
parallel simulation internals. Two independent implementations of the SSF API
have been provided: JSSF (written in Java) and DaSSF (written in <I>C++</I>).
They also include a Domain Modeling Language (<I>DML</I>) to synthesize a
model and instantiate a simulation. </LI></UL>
<BLOCKQUOTE>
<P>SSF and <I>J-Sim</I> are similar in terms of the (i) object-oriented,
layered software architecture design and (ii) isolation of modeling from
simulation internals. There are nevertheless several important differences
between SSF and <I>J-Sim,</I> which are tabulated in Table 1.
<P><B>Table 1.</B> A comparison between <I>SSF </I>and
<I>J-Sim</I>.</P></BLOCKQUOTE>
<BLOCKQUOTE>
<TABLE borderColor=#0000ff borderColorDark=#0000ff width=911
borderColorLight=#0000ff border=1>
<TBODY>
<TR>
<TH noWrap width=169 height=16>Aspect</TH>
<TH vAlign=top noWrap width=345 height=16><I>SSF</I></TH>
<TH vAlign=top noWrap width=375 height=16><I>J-Sim</I></TH></TR>
<TR>
<TH vAlign=top noWrap width=169 height=289>Object-oriented paradigm</TH>
<TD vAlign=top width=345 height=289>Five base classes:
<P>(i) <I>Entity</I> serves as a container mechanism for defining
alignment of a group of components to common local time (e.g.,
<I>ProtocolGraph</I> extends <I>Entity</I>);</P>
<P>(ii) <I>inChannel </I>and (iii) <I>outChannel</I> are communication
endpoints for event exchange;</P>
<P>(iv) <I>Event</I> is the base class for information exchange; and</P>
<P>(v) <I>Process</I> is the base class for describing dynamic behavior.
Each instance of process is owned by a specific entity and may wait for
input to arrive on channels owned by the entity, wait for some amount of
simulation time to elapse, or do both.</P></TD>
<TD vAlign=top width=375 height=289>A simple and well-defined
component-based software architecture: <I>Component</I> is the base
class. <I>Ports</I> are the only interfaces of a component to
send/receive data. When data arrives at a port, an execution context (a
Java thread) is created for the component to process the data.
Components are asynchronous in the sense that two components may process
different data at the same time without synchronizing between each
other.
<P>Components can be hierarchically structured. A component may be
itself a container mechanism and consist of subcomponents. This
facilitates hierarchical modeling of complex systems.</P></TD></TR>
<TR>
<TH vAlign=top noWrap width=169 height=68>Simulation framework</TH>
<TD vAlign=top width=345 height=68>Classes interact with the underlying
simulation engine with defined APIs</TD>
<TD vAlign=top width=375 height=68>Simulation engine is built in the
runtime and is transparent to components.</TD></TR>
<TR>
<TH vAlign=top noWrap width=169 height=74>Process-oriented modeling</TH>
<TD vAlign=top width=345 height=74>A set of <I>wait</I>() methods is
provided for modelers to write process-based models.</TD>
<TD vAlign=top width=375 height=74>Provides, in addition to the set of
wait() methods, synchronization methods to further extend programming
flexibility</TD></TR>
<TR>
<TH vAlign=top noWrap width=169 height=42>Simulation technique</TH>
<TD vAlign=top width=345 height=42>Discrete event simulation</TD>
<TD vAlign=top width=375 height=42>Can work with both discrete event
simulation and real-time process-based simulation</TD></TR>
<TR>
<TH vAlign=top noWrap width=169 height=121>Performance scalability</TH>
<TD vAlign=top width=345 height=121>Highly scalable by use of parallel
simulation kernels</TD>
<TD vAlign=top width=375 height=121>Will implement a parallel simulation
engine (that takes advantage of the <I>conservative</I> approach) in the
autonomous component architecture </TD></TR></TBODY></TABLE></BLOCKQUOTE>
<BLOCKQUOTE>
<P>As <I>INET/J-Sim</I> is laid atop the autonomous component architecture, a
component layer, called <I>SSFNET,</I> is positioned on top of SSF, contains
classes for network hosts and routers, and implements major Internet protocols
(IP, TCP, UDP, OSPFv2, BGP-4, and the pseudo-network interface drivers,
sockets), global Internet topology construction and IP address assignment. The
differences between <I>SSFNET</I> and <I>INET </I>are tabulated in Table
2.</P>
<P><B>Table 2.</B> A comparison between <I>SSFNET </I>and
<I>INET/J-Sim</I>.</P></BLOCKQUOTE>
<BLOCKQUOTE>
<TABLE borderColor=#0000ff borderColorDark=#0000ff width=911
borderColorLight=#0000ff border=1>
<TBODY>
<TR>
<TH noWrap width=169 height=16>Aspect</TH>
<TH vAlign=top noWrap width=345 height=16><I>SSFNET</I></TH>
<TH vAlign=top noWrap width=375 height=16><I>INET/J-Sim</I></TH></TR>
<TR>
<TH vAlign=top noWrap width=169 height=109>Configuration</TH>
<TD vAlign=top width=345 height=109>The configuration files are in the
Domain Modeling Language (<I>DML</I>) format. They are used to
synthesize a model and instantiate a simulation run with the help of the
configuration database package <I>SSF.DML</I>. The language is, however,
not suitable to be used in an interaction environment.</TD>
<TD vAlign=top width=375 height=109>A dual-language environment is
provided: Java is used to create components and a script language is
used as a glue or control language that integrates components in a
desired fashion at run time and provides high-level, dynamic control.
This facilitates fast prototyping of customized simulation scenarios,
and runtime configuration and diagnosis.</TD></TR>
<TR>
<TH vAlign=top noWrap width=169 height=80>Modeling</TH>
<TD vAlign=top width=345 height=80>A node is an <I>Entity</I>. The
infrastructure inside a node does not follow the container semantics in
SSF but follows the protocol graph/protocol session semantics in
x-kernel. It is unclear on how to extend the structure.</TD>
<TD vAlign=top width=375 height=80>A node is a composite component and
all modules in a node are components. A general node structure is
developed in <A href="http://www.j-sim.org/whitepapers/ns.html">INET</A>
to facilitate constructing specific node structures.</TD></TR>
<TR>
<TH vAlign=top noWrap width=169 height=128>Network and
Protocol<BR>Models</TH>
<TD vAlign=top width=345 height=128>Support major Internet protocols
(IP, TCP, UDP, OSPFv2, BGP-4, and the pseudo-network interface drivers
NIC, sockets), global Internet topology construction and IP address
assignment.</TD>
<TD vAlign=top width=375 height=128>Support, in addition to those
supported by SSFNET (except BGP), also
<OL>
<LI>multicast routing protocols (such as DVMRP, MOSPF, CBT),
<LI>QoS-driven protocols (such as QoS extension to OSPFv2, QoS
extension to CBT, and various rate-based message scheduling
disciplines),
<LI>protocols in the integrated services architecture (such as RSVP
signaling),
<LI>components in the differentiated services architecture
(marker/tagger at edge routers and buffer management algorithms at
core routers). </LI></OL></TD></TR></TBODY></TABLE></BLOCKQUOTE>
<UL>
<LI><B>Fluid simulation</B> also aims to improve scalability, but from a
different perspective. It consists of two major approaches: (i) hierarchical
fluid modeling: it abstracts a potentially complex component of the simulation
by a simpler model and substitution of this simpler model into the larger
simulation; (ii) modeling at multiple time scales: it simulates system
behavior at coarser time-scales, allowing for significant savings in
simulation execution times. Conceptually, network traffic is modeled as a
continuous fluid model and time-driven simulation is used to discretize the
continuous fluid mode and simulate the fluid backlogs (e.g., the back-logged
fluid at a server, the departure process at a server) at discrete times. They
prove that the discretization error is bounded by a constant proportional to
the discretization interval length. Although conceptually innovative, it is
not clear whether or not most, if not all, traffic can be well characterized
in fluid models without losing modeling accuracy.<BR>
<LI>Although the <A href="http://ptolemy.berkeley.edu/"><B>Ptolemy
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -