From chris@cs.vu.nl Mon Mar 1 09:01:49 1999 From: chris@cs.vu.nl (Christoph Haenle) Date: Mon, 01 Mar 1999 10:01:49 +0100 Subject: Virtual memory exceeded in new In-Reply-To: Your message of "Sat, 27 Feb 1999 07:33:26 MET." <3749.199902270733@tina.comp.lancs.ac.uk> Message-ID: Hi Randa, > > Also, I have done ps and pagesize commands while program is running. > > But I have not tried to increase the swap area. I am working on ultra-10 SunOS 5.6. Does anyone know how to increase it? Under Solaris, become root and create a dummy file with mkfile somewhere. Then tell the system to use this file as swap area by adding it with "swap -a filename". See also the man pages for mkfile and swap. -Chris. From s6356bod@hszk.bme.hu Mon Mar 1 09:06:49 1999 From: s6356bod@hszk.bme.hu (Bodog Gyula) Date: Mon, 1 Mar 1999 10:06:49 +0100 (MET) Subject: Flowmonitor Message-ID: Daer all, I've some problem with flowmonitor. I install 20 FTP flow between two nodes, and hwen i collect the stats for the flow, I get only one row. Which means for me, that there's only one flow. Now I used NS 2.1b4, but when I used NS 2.1b3 I didn't have any problem with this. Here's my script, which collect the flow stats: proc flowq {qmon ist} { global ns ; set time [$ns now] set ch [open dump w] $qmon attach $ch $qmon dump $ns at [expr $time + $ist] "flowq $qmon $ist" set qmon [makeflowmon] attach-fmon $l $qmon $ns at 30.0 "flowq $qmon 30" Any comment could be helpful. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Gyula Bodog * * e-mail: s6356bod@ural2.hszk.bme.hu * * tel.: (06 1) 3-691-839 * * Student at Technical University of Budapest * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From Lloyd Wood Mon Mar 1 12:30:08 1999 From: Lloyd Wood (Lloyd Wood) Date: Mon, 1 Mar 1999 12:30:08 +0000 (GMT) Subject: ns-2.1b5 In-Reply-To: Message-ID: On Sat, 27 Feb 1999, Juana Elias Nakfour wrote: > I've been reading the e-mails that have been going around, and I > saw two e-mails concerning the new version of ns. One said that it will be > out in the end of February and the other said it is still unknown. does > anyone know the exact date? (checks calendar. 1 March.) I vote for the latter for a new beta release - unless you're running snapshots, when there's a new version of ns every day. > My current research includes running snoop.tcl. I just want to know if > anyone was able to run it cause I am having a bit of trouble. I did see > the mail archive and it really doesn't explain a lot. IIRC (and this is mentioned in the archive in a couple of places), snoop's broken, is not currently maintained, time spent by someone to fix it would be appreciated, pointers/help would be provided. cheers, L. PGP From gpol@telecom.ntua.gr Mon Mar 1 01:54:36 1999 From: gpol@telecom.ntua.gr (George Politis) Date: Mon, 1 Mar 1999 03:54:36 +0200 Subject: A question on CBQ mechanism. Message-ID: <01BE6397.3A9E7FB0@hwpc176.telecom.ece.ntua.gr> Dear all, I'm not quite sure about the queuing mechanism of the CBQ, whether it implements: 1. one queue per flow (IntServ model), or 2. one queue per class (DiffServ model). I would appreciate to your help. Kind regards, ======================================= George Politis Electrical Engineer National Technical University of Athens tel +301 7722423 fax +301 7722534 e-mail gpol@telecom.ntua.gr ======================================= From Qian_Ming/nsih2_RALEIGH/alcatel/US/Telemail/alcanet@aurfh1.aur.alcatel.com Mon Mar 1 15:47:31 1999 From: Qian_Ming/nsih2_RALEIGH/alcatel/US/Telemail/alcanet@aurfh1.aur.alcatel.com (Qian_Ming/nsih2_RALEIGH/alcatel/US/Telemail/alcanet@aurfh1.aur.alcatel.com) Date: Mon, 1 Mar 99 10:47:31 -0500 Subject: bad font for nam, help wanted! Message-ID: I try to run an example simulation and get the following error message. Can anybody on this list help me to fix this problem? Please advise. poitier qianmi> ns example1.tcl poitier qianmi> Cannot connect to existing nam instance. Starting a new one... X Error of failed request: BadFont (invalid Font parameter) Major opcode of failed request: 55 (X_CreateGC) Resource id in failed request: 0x4c00027 Serial number of failed request: 89 Current serial number in output stream: 91 From Marc.Volmer@oenzl.siemens.de Mon Mar 1 16:51:47 1999 From: Marc.Volmer@oenzl.siemens.de (Volmer, Marc) Date: Mon, 01 Mar 1999 17:51:47 +0100 Subject: AW: A question on CBQ mechanism. Message-ID: <1999Mar01.183100.2013.82630@msmail.oenzl.siemens.de> Hi, The CBQ mechanism, as it is implemented in ns, uses one queue per class (look at tcl/lib/ns-queue.tcl). Marc Volmer ENST, Paris. ---------- >Von: George Politis >An: 'NS mailing list' >Betreff: A question on CBQ mechanism. >Datum: Montag, 1. März 1999 17:37 > >Dear all, > >I'm not quite sure about the queuing mechanism of the CBQ, >whether it implements: > 1. one queue per flow (IntServ model), or > 2. one queue per class (DiffServ model). > >I would appreciate to your help. > >Kind regards, > >======================================= >George Politis >Electrical Engineer >National Technical University of Athens >tel +301 7722423 >fax +301 7722534 >e-mail gpol@telecom.ntua.gr >======================================= > > > >------ Message Header Follows ------ >Received: from oenzl.siemens.de by msmail.oenzl.siemens.de > (PostalUnion/SMTP(tm) v2.1.9f for Windows NT(tm)) > id AA-1999Mar01.173757.2013.58532; Mon, 01 Mar 1999 17:37:58 +0100 >Received: from herkules.siemens.de by oenzl.siemens.de (4.1/SMI-4.1) > id AA06694; Mon, 1 Mar 99 17:37:58 MET >Received: from david.siemens.de (david.siemens.de [192.35.17.14]) > by herkules.siemens.de (8.9.3/8.9.3) with ESMTP id RAA10147 > for ; Mon, 1 Mar 1999 17:38:10 +0100 (MET) >X-Envelope-Sender-Is: owner-ns-users@mash.CS.Berkeley.EDU (at relayer >david.siemens.de) >Received: from mash.CS.Berkeley.EDU (mash.CS.Berkeley.EDU [128.32.130.10]) > by david.siemens.de (8.9.3/8.9.3) with ESMTP id RAA20529 > for ; Mon, 1 Mar 1999 17:37:57 +0100 (MET) >Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [147.102.222.230]) > by mash.CS.Berkeley.EDU (8.9.1/8.9.1) with ESMTP id HAA21653 > for ; Mon, 1 Mar 1999 07:45:25 -0800 (PST) >Received: from ektor.telecom.ece.ntua.gr (ektor.telecom.ece.ntua.gr >[147.102.7.1]) > by ulysses.noc.ntua.gr (8.9.3/8.9.3) with ESMTP id RAA13555 > for ; Mon, 1 Mar 1999 17:45:17 +0200 (EET) >Received: by telecom.ntua.gr with SMTP > id RAA22496 at Mon, 1 Mar 1999 17:40:22 +0200 (EET) >Received: by hwpc176.telecom.ece.ntua.gr with Microsoft Mail > id <01BE6397.3A9E7FB0@hwpc176.telecom.ece.ntua.gr>; Mon, 1 Mar 1999 03:54:38 >+0200 >Message-Id: <01BE6397.3A9E7FB0@hwpc176.telecom.ece.ntua.gr> >From: George Politis >To: "'NS mailing list'" >Subject: A question on CBQ mechanism. >Date: Mon, 1 Mar 1999 03:54:36 +0200 >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: 7bit > > From sunmin@orff.ecse.rpi.edu Mon Mar 1 20:04:49 1999 From: sunmin@orff.ecse.rpi.edu (Mingzhou Sun) Date: Mon, 01 Mar 1999 15:04:49 -0500 Subject: Q: Problem compiling rtProtoLS with egcs-1.1.1 In-Reply-To: Your message of "Fri, 26 Feb 1999 18:17:10 PST." <36D755A6.1958DFB9@cs.ucdavis.edu> Message-ID: <199903012004.PAA16533@orff.ecse.rpi.edu> > Hi, > > For one of my research problems, I need to simulate a link-state routing > protocol in ns-2 (basically, I need an implementation of a simplified > version of OSPF). > > So, I downloaded rtProtoLS (developed by Mingzhou Sun at RPI > http://networks.ecse.rpi.edu/~sunmin/rtProtoLS/) and tried compiling it > with egcs-1.1.1. This is what happened: > > 1. packet.cc and trace.cc compiled successfully. > 2. While compiling rtProtoLS.cc, I got the following error(s): > > ---------------------------------------------------------------- > c++ -c -DNSLS -I. -I/home/sahasrab/ns/ns-allinone-2.1b4a/ns-2 > -I/home/sahasrab/ns/ns-allinone-2.1b4a/tcl8.0/generic > -I/home/sahasrab/ns/ns-allinone-2.1b4a/otcl -I. -I/usr/include > -I../tclcl -I../otcl -I../tkbox/include -I../tclbox/include -g -Wall > -DNO_TK -DTCLCL_CLASSINSTVAR -DNDEBUG -DUSE_SHM -DHAVE_DBG_H > -DHAVE_LIBTCLCL1_0B7 -DHAVE_TCLCL_H -DHAVE_LIBOTCL1_0A3 -DHAVE_OTCL_H > -DHAVE_LIBTK8_0 -DHAVE_TK_H -DHAVE_LIBTCL8_0 -DHAVE_TCL_H > -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_TCL_H=1 -DHAVE_LIBTCL8_0=1 > -DHAVE_TK_H=1 -DHAVE_LIBTK8_0=1 -DHAVE_OTCL_H=1 -DHAVE_LIBOTCL1_0A3=1 > -DHAVE_TCLCL_H=1-DHAVE_LIBTCLCL1_0B7=1 -DHAVE_DBG_H=1 -DHAVE_GETRUSAGE=1 > -DHAVE_SBRK=1 -o rtProtoLS.o rtProtoLS.cc > ls.h: In method `LsList::LsList()': > ls.h:183: instantiated from here > In file included from rtProtoLS.h:12, > from rtProtoLS.cc:6: > ls.h:96: Internal compiler error. > ls.h:96: Please submit a full bug report to `egcs-bugs@cygnus.com'. > ls.h:96: See for > details. > gmake[1]: *** [rtProtoLS.o] Error 1 > gmake[1]: Leaving directory > `/home/sahasrab/ns/ns-allinone-2.1b4a/rtProtoLS_b4' > make: *** [all] Error 2 > ---------------------------------------------------------------- > > Maybe the problem is in the compiler and I will be sending a bug report > to egcs-bugs@cygnus.com, but if you know a quick fix or you have some > suggestions, please let me know asap. Btw, I have sent a separate > request to Mingzhou Sun (the author of rtProtoLS). > > Also, if you know of some other OSPF-like module (not rtProtoLS) that > works with ns-2, please let me know. > > Thanks in advance, > Laxman. sahasrab, Thanks for trying out rtProtoLS and finding out problems. I am not good with the compiler thing either, but I would suggest that you try comment out that line altogether, and see if the compiler will generate the correct default constructor for it. Thanks for reporting the problemI'd appreciate it if you can tell me how it goes. Mingzhou Sun RPI From Lloyd Wood Mon Mar 1 21:33:52 1999 From: Lloyd Wood (Lloyd Wood) Date: Mon, 1 Mar 1999 21:33:52 +0000 (GMT) Subject: Core-Stateless Fair Queuing for ns Message-ID: http://www.cs.cmu.edu/~istoica/csfq/ A quick check of the ns research and contributed code pages on the mash server didn't turn up a mention of or link to this, so I thought I'd point its existence out. Looks like simulations of traffic conditioning at network edges; for ns 2.1b2. Haven't tried the code. Cheers, L. PGP From Steven.Russert@PSS.Boeing.com Tue Mar 2 00:47:24 1999 From: Steven.Russert@PSS.Boeing.com (Russert, Steven W) Date: Mon, 1 Mar 1999 16:47:24 -0800 Subject: nam - no display Message-ID: <618FD3AF120DD111A27900805F19D9C4039DCF8A@xch-blv-03.ca.boeing.com> Hello, I'm running too short of hair to continue alone, so... I have a P-133 machine with Red Hat Linux 2.0.36 tcl 8.0.3 came with the OS I have installed tclcl 1.0b7 (then changed to 1.0b6, just in case), otcl 1.0a3, ns 2.1b4, and nam 1.0a6 ns runs the verification suite ok, but whenever nam is invoked, it just goes away, pegs the cpu utilization guage, and doesn't display anything. I even let nam run for 3 days with no change. I'm using X from a desktop NT4 system, but I haven't seen any problems with other applications getting to the display. Any ideas? Thanks, Steven W. Russert Boeing Phantom Works M&CT steven.w.russert@boeing.com 425-865-3588 From haoboy@isi.edu Tue Mar 2 00:52:38 1999 From: haoboy@isi.edu (Haobo Yu) Date: Mon, 1 Mar 1999 16:52:38 -0800 (PST) Subject: nam - no display In-Reply-To: <618FD3AF120DD111A27900805F19D9C4039DCF8A@xch-blv-03.ca.boeing.com> Message-ID: I'm using nam with tcl8.0.4 and others the same as yours and haven't seen this kind of problem. Did you test nam on any of its example traces (nam/ex/*.nam)? If you run it on your own nam trace file, could you please send me that file? Thanks. - Haobo > I have a P-133 machine with Red Hat Linux 2.0.36 > tcl 8.0.3 came with the OS > I have installed tclcl 1.0b7 (then changed to 1.0b6, just in case), otcl 1.0a3, ns 2.1b4, and nam 1.0a6 > ns runs the verification suite ok, but whenever nam is invoked, it just goes away, pegs the cpu utilization guage, and doesn't display anything. I even let nam run for 3 days with no change. > I'm using X from a desktop NT4 system, but I haven't seen any problems with other applications getting to the display. > Any ideas? > > Thanks, > > Steven W. Russert > Boeing Phantom Works M&CT > steven.w.russert@boeing.com > 425-865-3588 > > From Steven.Russert@PSS.Boeing.com Tue Mar 2 01:00:20 1999 From: Steven.Russert@PSS.Boeing.com (Russert, Steven W) Date: Mon, 1 Mar 1999 17:00:20 -0800 Subject: nam - no display Message-ID: <618FD3AF120DD111A27900805F19D9C4039DCF8B@xch-blv-03.ca.boeing.com> Haobo, Thanks for the reply. I ran nam against several of the examples, and I even took the shortest one and cut off everything but the first 10 or 12 lines. I have even run nam with no arguments, and I get the same thing. Steve > ---------- > From: Haobo Yu[SMTP:haoboy@isi.edu] > Sent: Monday, March 01, 1999 4:52 PM > To: Russert, Steven W > Cc: 'ns-users@mash.cs.berkeley.edu' > Subject: Re: nam - no display > > I'm using nam with tcl8.0.4 and others the same as yours and haven't seen > this kind of problem. Did you test nam on any of its example traces > (nam/ex/*.nam)? If you run it on your own nam trace file, could you please > send me that file? Thanks. > > - Haobo > > > I have a P-133 machine with Red Hat Linux 2.0.36 > > tcl 8.0.3 came with the OS > > I have installed tclcl 1.0b7 (then changed to 1.0b6, just in case), otcl 1.0a3, ns 2.1b4, and nam 1.0a6 > > ns runs the verification suite ok, but whenever nam is invoked, it just goes away, pegs the cpu utilization guage, and doesn't display anything. I even let nam run for 3 days with no change. > > I'm using X from a desktop NT4 system, but I haven't seen any problems with other applications getting to the display. > > Any ideas? > > > > Thanks, > > > > Steven W. Russert > > Boeing Phantom Works M&CT > > steven.w.russert@boeing.com > > 425-865-3588 > > > > > From sva0392@tntech.edu Tue Mar 2 04:25:39 1999 From: sva0392@tntech.edu (Syamsundar V Appala) Date: Mon, 01 Mar 1999 22:25:39 -0600 (CST) Subject: Lossmonitor? for packet losses Message-ID: Hi, I'm currently working on the implementation of Scalable Relaible Multicast protocol. For obtaining packet losses at a particular receiver what do I need to use. Is it loss monitor Agent or Mcastmonitor.Please let me know. Regards, Syam Appala From p.losi@netline.it Tue Mar 2 08:55:17 1999 From: p.losi@netline.it (Paolo Losi) Date: Tue, 02 Mar 1999 08:55:17 +0000 Subject: PGPS (WFQ) code submission feedback request Message-ID: <36DBA775.EC74C8E5@netline.it> I would like to contribute the ns-2 community with my implementation of Packet-by-Packet Generalized Processor Sharing (generally know as Weighted Fair Queueing). Is there anyone interested in it? I'd like to have a feedback from ns2 developers also. Thanks Paolo Losi From greis@cs.uni-bonn.de Tue Mar 2 09:44:45 1999 From: greis@cs.uni-bonn.de (Marc Greis) Date: Tue, 2 Mar 1999 10:44:45 +0100 (MET) Subject: PGPS (WFQ) code submission feedback request In-Reply-To: <36DBA775.EC74C8E5@netline.it> from "Paolo Losi" at Mar 2, 99 08:55:17 am Message-ID: <199903020944.KAA09739@zeus.informatik.uni-bonn.de> Paolo Losi wrote: > I would like to contribute the ns-2 community with > my implementation of Packet-by-Packet Generalized > Processor Sharing (generally know as Weighted Fair > Queueing). > Is there anyone interested in it? > I'd like to have a feedback from ns2 developers also. Paolo, >From my own experience, I know that there is a huge interest in WFQ modules among the ns-2 users (I would say that about 30-40% of the people who request my RSVP modules want them for the WFQ code), so I would think that many people would appreciate it. Is there already some way for getting the code, or did you want to wait for feedback? I think I'd be interested in taking a look at it myself. ;) Marc -- Marc Greis greis@cs.uni-bonn.de From p.losi@netline.it Tue Mar 2 09:53:01 1999 From: p.losi@netline.it (Paolo Losi) Date: Tue, 02 Mar 1999 09:53:01 +0000 Subject: PGPS (WFQ) code submission feedback request References: <199903020944.KAA09739@zeus.informatik.uni-bonn.de> Message-ID: <36DBB4FD.127BC316@netline.it> Marc Greis wrote: > > Paolo Losi wrote: > > I would like to contribute the ns-2 community with > > my implementation of Packet-by-Packet Generalized > > Processor Sharing (generally know as Weighted Fair > > Queueing). > > Is there anyone interested in it? > > I'd like to have a feedback from ns2 developers also. > > Paolo, > > >From my own experience, I know that there is a huge interest in WFQ > modules among the ns-2 users (I would say that about 30-40% of the > people who request my RSVP modules want them for the WFQ code), so I > would think that many people would appreciate it. Is there already > some way for getting the code, or did you want to wait for feedback? I > think I'd be interested in taking a look at it myself. ;) > > Marc > > -- > Marc Greis greis@cs.uni-bonn.de The code I'm talking about is the one I used for my graduation work that is now completed. Some time ago I asked the research group I was working for for a permission to distribute the code. At that time the answer was "quite" positive. I'd like to see now if there is any interest in my work ... if so, I'll ask a more official permission. I'm documenting the whole thing now, aiming at internal use, but I hope I'll able to share the WFQ modules with the community Paolo Losi From Chadi.Barakat@sophia.inria.fr Tue Mar 2 12:56:11 1999 From: Chadi.Barakat@sophia.inria.fr (Chadi M. BARAKAT) Date: Tue, 02 Mar 1999 13:56:11 +0100 Subject: Problem Message-ID: <36DBDFEB.5AB75383@sophia.inria.fr> Hello, I got the following error message while installing ns. Do you have any idea?? Chadi cc tclAppInit.o -L/0/mistral2/cbarakat/Ns/tcl8.0/unix -ltcl8.0 -ldl -lsocket -lnsl -lm -lc \ -o tclsh Undefined first referenced symbol in file fixstrtod /0/mistral2/cbarakat/Ns/tcl8.0/unix/libtcl8.0.a(tclObj.o) ld: fatal: Symbol referencing errors. No output written to tclsh *** Error code 1 make: Fatal error: Command failed for target `tclsh' tcl8.0 make failed! Exiting ... -- ** Chadi Mohamad BARAKAT ** http://www.inria.fr/mistral/personnel/Chadi.Barakat /\ PhD Student - MISTRAL - INRIA / \ Chadi.Barakat@sophia.inria.fr 2004, Route des Lucioles BP 93 \ / Phone : + 33 4 92 38 71 99 06902 Sophia Antipolis - France \/ Cell : + 33 6 10 42 36 30 From Lloyd Wood Tue Mar 2 13:25:02 1999 From: Lloyd Wood (Lloyd Wood) Date: Tue, 2 Mar 1999 13:25:02 +0000 (GMT) Subject: Problem In-Reply-To: <36DBDFEB.5AB75383@sophia.inria.fr> Message-ID: On Tue, 2 Mar 1999, Chadi M. BARAKAT wrote: > I got the following error message while installing ns. from the allinone package? You don't say. > Do you have any idea?? Hmmm, Inria Sophia Antipolis recently upgraded en masse to Solaris 2.6 - or so Antoine tells me. (although you neglect to say what you're using.) So, since I'm also using Solaris... If you look in ~tcl8.0/unix/configure.in you'll see: #-------------------------------------------------------------------- # Under Solaris 2.4, strtod returns the wrong value for the # terminating character under some conditions. Check for this # and if the problem exists use a substitute procedure # "fixstrtod" that corrects the error. #-------------------------------------------------------------------- (for my Tcl 8.0p2, anyway), followed by various bits and pieces. My guess is that Tcl isn't taking account of Solaris 2.6 in this and strtod is fixed (no idea about 2.5/2.5.1), and configure needs adjusting. I'd also guess that a later Tcl (you don't specify what version you're running) may fix this. Looks very much like a Tcl problem, rather than an ns problem, to me. Cheers, L. all this from 'grep * fixstrtod'! I've never liked find. > cc tclAppInit.o -L/0/mistral2/cbarakat/Ns/tcl8.0/unix -ltcl8.0 -ldl > -lsocket -lnsl -lm -lc \ > -o tclsh > Undefined first referenced > symbol in file > fixstrtod > /0/mistral2/cbarakat/Ns/tcl8.0/unix/libtcl8.0.a(tclObj.o) > ld: fatal: Symbol referencing errors. No output written to tclsh > *** Error code 1 > make: Fatal error: Command failed for target `tclsh' > tcl8.0 make failed! Exiting ... > > -- > ** Chadi Mohamad BARAKAT ** > http://www.inria.fr/mistral/personnel/Chadi.Barakat > /\ > PhD Student - MISTRAL - INRIA / \ Chadi.Barakat@sophia.inria.fr > 2004, Route des Lucioles BP 93 \ / Phone : + 33 4 92 38 71 99 > 06902 Sophia Antipolis - France \/ Cell : + 33 6 10 42 36 30 PGP From softrel9@nortelnetworks.com Tue Mar 2 15:57:34 1999 From: softrel9@nortelnetworks.com (Sarah Liu) Date: Tue, 2 Mar 1999 10:57:34 -0500 Subject: dropped packet in nam Message-ID: <03E3E0690542D211A1490000F80836F43E45BD@zcard00f.ca.nortel.com> Hi, everybody: I wrote several scripts to generate some packet loss on different links using SelectErrorModel and LossMonitor. I got the following as part of the result: (In this topology, I have 6 nodes) rcvr 0 lost 55 pkt, rcv 72 rcvr 1 lost 78 pkt, rcv 73 rcvr 2 lost 32 pkt, rcv 49 rcvr 3 lost 7 pkt, rcv 18 rcvr 4 lost 7 pkt, rcv 48 rcvr 5 lost 14 pkt, rcv 38 Right now, I am using nam-1.0a7 and from the nam documentation I got, it seems that "dropped packet can be shown as a rotating squares and disappear at the end of the screen". But I didn't see any such rotating packet during the animation. So, my question is : Is that possible to visualize the loss of packet in nam and How? I would very appreciate for the help of anyone who know this. Cheers, Sarah ---------------------------------------------------------------------------- -------------------------------- Sarah Xiaohui Liu, 613-765-3203 o__ o~__ Email: softrel9@nortelnetworks.com _,>/_ _,>/_ u1452573@csi.uottawa.ca (*) (*) (*) (*) Mail Stop: 0C32, Nortel Networks Corp. ---------------------------------------------------------------------------- -------------------------------- From haoboy@isi.edu Tue Mar 2 18:25:50 1999 From: haoboy@isi.edu (Haobo Yu) Date: Tue, 2 Mar 1999 10:25:50 -0800 (PST) Subject: dropped packet in nam In-Reply-To: <03E3E0690542D211A1490000F80836F43E45BD@zcard00f.ca.nortel.com> Message-ID: If packets are dropped from queues, it's automatically written to nam trace if you do namtrace-all{}. But if you use error models to drop packets you have to add those packets to nam traces yourself. All those error models have a OTcl method drop-target{} to allow you put a drop trace object there: # Assume you want to monitor loss at an error model $em on a simplex link (n1, n2) $em drop-target [$ns create-trace Drop [$ns get-nam-traceall] $n1 $n2 "nam"] Do this in your sim script after you've called namtrace-all{} and it'll add a trace line for each dropped packet there. - Haobo On Tue, 2 Mar 1999, Sarah Liu wrote: > Hi, everybody: > > I wrote several scripts to generate some packet loss on different links > using SelectErrorModel and LossMonitor. I got the following as part of the > result: (In this topology, I have 6 nodes) > > rcvr 0 lost 55 pkt, rcv 72 > rcvr 1 lost 78 pkt, rcv 73 > rcvr 2 lost 32 pkt, rcv 49 > rcvr 3 lost 7 pkt, rcv 18 > rcvr 4 lost 7 pkt, rcv 48 > rcvr 5 lost 14 pkt, rcv 38 > > Right now, I am using nam-1.0a7 and from the nam documentation I got, it > seems that "dropped packet can be shown as a rotating squares and disappear > at the end of the screen". But I didn't see any such rotating packet during > the animation. So, my question is : Is that possible to visualize the loss > of packet in nam and How? > > I would very appreciate for the help of anyone who know this. > > Cheers, > > Sarah > > ---------------------------------------------------------------------------- > -------------------------------- > Sarah Xiaohui Liu, 613-765-3203 o__ o~__ > Email: softrel9@nortelnetworks.com _,>/_ _,>/_ > u1452573@csi.uottawa.ca (*) (*) (*) (*) > Mail Stop: 0C32, Nortel Networks Corp. > > ---------------------------------------------------------------------------- > -------------------------------- > > From twu2@eos.ncsu.edu Tue Mar 2 18:57:29 1999 From: twu2@eos.ncsu.edu (twu2@eos.ncsu.edu) Date: Tue, 2 Mar 1999 13:57:29 -0500 (EST) Subject: NS tools Message-ID: <199903021857.NAA06725@loki.csc.ncsu.edu> Hi, Is there any tools/ways to show the statistics such as throughput, dropped packets' seqno, Cwnd values, or RTTs of a NS result? Thanks. Tsungli Wu From softrel9@nortelnetworks.com Tue Mar 2 19:26:16 1999 From: softrel9@nortelnetworks.com (Sarah Liu) Date: Tue, 2 Mar 1999 13:26:16 -0600 Subject: dropped packet in nam Message-ID: <03E3E0690542D211A1490000F80836F43E45BF@zcard00f.ca.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE64E2.8D6F6C4E Content-Type: text/plain; charset="iso-8859-1" Hi, Haobo, Thanks for your quick reply. I have followed your suggestion to modify the code, but unfortunately, it doesn't work. I don't know if I did it right? The error message is following: (_o208 cmd line 1) invoked from within "_o208 cmd drop-target_o211" invoked from within "catch "$self cmd $args" ret" (procedure "_o208" line 2) (SplitObject unknown line 2) invoked from within "$loss_module1 drop-target[$ns create-trace Drop [$ns get-nam-traceall] $n0 $n1 "nam"]" (file "fault4.tcl" line 132) But if I changed this line to : $ns create-trace Drop [$ns get-nam-traceall] $n0 $n1 "nam" and keep the original drop-target command line. The test runs well just as before -- still without the "d" in the nam file and can't see any rotating square dropped. For fear that I didn't put the drop-target command line in the right place, I attached the test file for your reference. Best Regards, Sarah ------_=_NextPart_000_01BE64E2.8D6F6C4E Content-Type: application/octet-stream; name="fault4.tcl" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fault4.tcl" Content-Location: ATT-0-E19E5B91D0D0D211A19D0000F81ABA04-F AULT4.TCL # tests/fault4.tcl=0A= # 0=0A= # +-+--+=0A= # 1 2=0A= # +--+-+--+--+=0A= # 3 4 5=0A= #=0A= set ns [new Simulator -multicast on]=0A= =0A= $ns trace-all [open results/fault4.tr w]=0A= $ns namtrace-all [open results/fault4.nam w]=0A= =0A= =0A= set n0 [$ns node]=0A= set n1 [$ns node]=0A= set n2 [$ns node]=0A= set n3 [$ns node]=0A= set n4 [$ns node]=0A= set n5 [$ns node]=0A= =0A= $ns duplex-link $n0 $n1 1.5Mb 10ms DropTail=0A= $ns duplex-link $n0 $n2 1.5Mb 10ms DropTail=0A= $ns duplex-link $n1 $n3 1.5Mb 10ms DropTail=0A= $ns duplex-link $n1 $n4 1.5Mb 10ms DropTail=0A= $ns duplex-link $n2 $n4 1.5Mb 10ms DropTail=0A= $ns duplex-link $n2 $n5 1.5Mb 10ms DropTail=0A= $ns duplex-link-op $n0 $n1 orient left-down=0A= $ns duplex-link-op $n0 $n2 orient down-right=0A= $ns duplex-link-op $n1 $n3 orient left-down=0A= $ns duplex-link-op $n1 $n4 orient right-down=0A= $ns duplex-link-op $n2 $n4 orient left-down=0A= $ns duplex-link-op $n2 $n5 orient right-down=0A= =0A= ### Start multicast configuration:=0A= source ../src/CBTtimers.tcl=0A= =0A= CBT set Core_([expr 0x8003]) $n0=0A= =0A= CBT set JoinRtxTimeout_ 0.1=0A= CBT set TransTimeout_ 0.1=0A= CBT set EchoTimeout_ 0.15=0A= CBT set DownstreamTimeout_ 0.1=0A= =0A= $ns rtproto Algorithmic=0A= set mproto CBT=0A= set mrthandle [$ns mrtproto $mproto {}]=0A= if {$mrthandle !=3D ""} {=0A= $mrthandle set_c_rp [list $n2]=0A= }=0A= =0A= ### End of multicast configuration=0A= =0A= ### set the colour of packets generated by the constant bit rate = agents=0A= ### and of control messages=0A= =0A= $ns color 30 purple ;#prunes=0A= $ns color 34 red ;#joinreqs=0A= $ns color 35 yellow ;#joinacks=0A= $ns color 36 orange ;#echoreqs=0A= $ns color 37 cyan ;#echoreplys=0A= $ns color 38 green ;#flushtrees=0A= =0A= $n0 color blue ;#Core=0A= $n1 color Navy=0A= $n2 color BlueViolet=0A= =0A= $ns color 101 Navy ;#cbrs =0A= $ns color 102 BlueViolet =0A= =0A= set cbr1 [new Agent/CBR]=0A= #$cbr1 set ttl_ 3=0A= $cbr1 set dst_ 0x8003=0A= $cbr1 set class_ 101 =0A= $cbr1 set interval_ 20ms=0A= $ns attach-agent $n1 $cbr1=0A= =0A= set cbr2 [new Agent/CBR]=0A= #$cbr2 set ttl_ 3=0A= $cbr2 set dst_ 0x8003=0A= $cbr2 set class_ 102=0A= $cbr2 set interval_ 20ms=0A= $ns attach-agent $n2 $cbr2=0A= =0A= set rcvr0 [new Agent/LossMonitor]=0A= set rcvr1 [new Agent/LossMonitor]=0A= set rcvr2 [new Agent/LossMonitor] =0A= set rcvr3 [new Agent/LossMonitor]=0A= set rcvr4 [new Agent/LossMonitor]=0A= set rcvr5 [new Agent/LossMonitor]=0A= $ns attach-agent $n0 $rcvr0=0A= $ns attach-agent $n1 $rcvr1=0A= $ns attach-agent $n2 $rcvr2=0A= $ns attach-agent $n3 $rcvr3=0A= $ns attach-agent $n4 $rcvr4=0A= $ns attach-agent $n5 $rcvr5=0A= =0A= =0A= $ns at 0.2 "$n0 join-group $rcvr0 0x8003"=0A= $ns at 0.2 "$n1 join-group $rcvr1 0x8003"=0A= $ns at 0.3 "$n2 join-group $rcvr2 0x8003"=0A= $ns at 0.2 "$n3 join-group $rcvr3 0x8003"=0A= $ns at 0.2 "$n4 join-group $rcvr4 0x8003"=0A= $ns at 0.3 "$n5 join-group $rcvr5 0x8003"=0A= $ns at 0.6 "$n3 leave-group $rcvr3 0x8003"=0A= $ns at 0.8 "$n2 leave-group $rcvr2 0x8003"=0A= $ns at 1.0 "$n5 leave-group $rcvr5 0x8003"=0A= =0A= set loss_module1 [new SelectErrorModel]=0A= $loss_module1 drop-packet 2 200 1 ;# drop one PT_CBR packet every = 200 packets=0A= #$loss_module1 drop-target [$ns set nullAgent_] ;# <--- modified = here=0A= =0A= set loss_module2 [new SelectErrorModel]=0A= $loss_module2 drop-packet 2 100 1 ;# drop one PT_CBR packet every = 100 packets=0A= $loss_module2 drop-target [$ns set nullAgent_]=0A= =0A= set loss_module3 [new SelectErrorModel]=0A= $loss_module3 drop-packet 2 100 1 ;# drop one PT_CBR packet every = 100 packets=0A= $loss_module3 drop-target [$ns set nullAgent_]=0A= =0A= # insert the loss module; must be done before receivers join groups=0A= $ns lossmodel $loss_module1 $n0 $n1=0A= #$ns create-trace Drop [$ns get-nam-traceall] $n0 $n1 "nam" ;# = <--- modified here=0A= =0A= # the line you suggested=0A= $loss_module1 drop-target[$ns create-trace Drop [$ns get-nam-traceall] = $n0 $n1 "nam"] =0A= =0A= $ns lossmodel $loss_module2 $n1 $n3=0A= $ns lossmodel $loss_module3 $n2 $n5=0A= =0A= $ns at 0.1 "$cbr1 start"=0A= $ns at 0.15 "$cbr2 start"=0A= =0A= $ns at 1.2 "finish"=0A= =0A= proc finish {} {=0A= global rcvr3 rcvr4 rcvr5 n0 rcvr2 rcvr1 rcvr0 ns=0A= $ns flush-trace=0A= puts "rcvr 0 lost [$rcvr0 set nlost_] pkt, rcv [$rcvr0 set = npkts_]"=0A= puts "rcvr 1 lost [$rcvr1 set nlost_] pkt, rcv [$rcvr1 set = npkts_]"=0A= puts "rcvr 2 lost [$rcvr2 set nlost_] pkt, rcv [$rcvr2 set = npkts_]"=0A= puts "rcvr 3 lost [$rcvr3 set nlost_] pkt, rcv [$rcvr3 set npkts= _]"=0A= puts "rcvr 4 lost [$rcvr4 set nlost_] pkt, rcv [$rcvr4 set = npkts_]"=0A= puts "rcvr 5 lost [$rcvr5 set nlost_] pkt, rcv [$rcvr5 set = npkts_]"=0A= exec nam results/fault4.nam &=0A= exit 0=0A= }=0A= =0A= $ns run=0A= =0A= =0A= ------_=_NextPart_000_01BE64E2.8D6F6C4E-- From duan@cs.umn.edu Tue Mar 2 20:36:35 1999 From: duan@cs.umn.edu (Zhenhai Duan) Date: Tue, 2 Mar 1999 14:36:35 -0600 (CST) Subject: about TBF(Token Bucket Filter) Message-ID: I just checked the code of tbf, and I want to add in the Peak Rate contraint. But I am not sure how I should use this value. The way in my mind is this: Whenever I have enough tokens to send one packet, I postpone (scheduling a event) the sending by a delay(packetLength/peakRate), after timeout, I call target_->recv(p). Any comments are appreciated. --Zhenhai -------------------------------------------------------------- Zhenhai Duan duan@cs.umn.edu Computer Science Department http://www.cs.umn.edu/~duan University of Minnesota, TC Phone: (612)626-7526(O) -------------------------------------------------------------- From haoboy@isi.edu Tue Mar 2 21:13:08 1999 From: haoboy@isi.edu (Haobo Yu) Date: Tue, 2 Mar 1999 13:13:08 -0800 (PST) Subject: dropped packet in nam In-Reply-To: <03E3E0690542D211A1490000F80836F43E45BF@zcard00f.ca.nortel.com> Message-ID: There was something wrong with Simulator::lossmodel{} (and other error model installation methods in Link and SimpleLink), that they cannot produce nam trace events in the right order. Following are patches to ns-lib.tcl and ns-link.tcl. (They are against ns-lib.tcl version 1.139 and ns-link version 1.40. If you failed to apply them, you can either try do them manually using the context in them, or download the current snapshot). - Haobo * ns-lib.tcl: --- ns-lib.tcl~ 1999/02/26 23:06:34 +++ ns-lib.tcl 1999/03/02 20:22:00 @@ -1049,11 +1049,7 @@ ### to insert loss module to regular links in detailed Simulator Simulator instproc lossmodel {lossobj from to} { set link [$self link $from $to] - set head [$link head] - # puts "[[$head target] info class]" - $lossobj target [$head target] - $head target $lossobj - # puts "[[$head target] info class]" + $link errormodule $lossobj } Simulator instproc bw_parse { bspec } { * ns-link.tcl: --- ns-link.tcl~ 1998/10/28 19:26:49 +++ ns-link.tcl 1999/03/02 20:22:00 @@ -143,12 +143,6 @@ } } -Link instproc install-error {em} { - $self instvar link_ - $em target [$link_ target] - $link_ target $em -} - Class SimpleLink -superclass Link SimpleLink instproc init { src dst bw delay q {lltype "DelayLink"} } { @@ -464,8 +458,12 @@ # insert an "error module" after the queue # point the em's drop-target to the drophead # +# Must be inserted *RIGHT AFTER* the deqT_ (if present) or queue_, because +# nam can only visualize a packet drop if and only if it is on the link or +# in the queue +# SimpleLink instproc errormodule args { - $self instvar errmodule_ queue_ drophead_ + $self instvar errmodule_ queue_ drophead_ deqT_ if { $args == "" } { return $errmodule_ } @@ -473,7 +471,20 @@ set em [lindex $args 0] set errmodule_ $em - $self add-to-head $em + #$self add-to-head $em + if [info exists deqT_] { + $em target [$deqT_ target] + $deqT_ target $em + } else { + $em target [$queue_ target] + $queue_ target $em + } $em drop-target $drophead_ +} + +# Simply to provide backward compatibility +SimpleLink instproc install-error {em} { + puts "Obsolete interface. Please use errormodule{}" + $self errormodule $em } From hyryu@etri.re.kr Wed Mar 3 08:31:10 1999 From: hyryu@etri.re.kr (hyryu) Date: Wed, 3 Mar 1999 08:31:10 -0000 Subject: ld error Message-ID: <002f01be6550$317b3620$5bc0fe81@pony.etri.re.kr> This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BE6550.313FB3C0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGVsbG8gIQ0KDQoNCltwcmlzbTovdXNyL2xvY2FsL25zLWFsbGlub25lLTIuMWI0YS9ucy0yXSMg bWFrZQ0KYysrICAtbyBucyBcDQogICAgICAgIHRjbEFwcEluaXQubyAgcmFuZG9tLm8gcm5nLm8g cmFudmFyLm8gbWlzYy5vIHRpbWVyLWhhbmRsZXIubyBzY2hlZHVsZXIubyBvYmplY3QubyBwYWNr ZXQubyBpcC5vIHJvdXRlLm8gY29ubmVjdG9yLm8gdHRsLm8gdHJhY2UubyB0cmFjZS1pcC5vIGNs YXNzaWZpZXIubyBjbGFzc2lmaWVyLWFkZHIubyBjbGFzc2lmaWVyLWhhc2gubyBjbGFzc2lmaWVy LXZpcnR1YWwubyBjbGFzc2lmaWVyLW1jYXN0Lm8gY2xhc3NpZmllci1tcGF0aC5vIHJlcGxpY2F0 b3IubyBjbGFzc2lmaWVyLW1hYy5vIGFwcC5vIHRlbG5ldC5vIHRjcGxpYi10ZWxuZXQubyB0cmFm Z2VuLm8gdHJhZmZpY3RyYWNlLm8gcGFyZXRvLm8gZXhwb28ubyBjYnJfdHJhZmZpYy5vIHRiZi5v IHJlc3YubyBzYS5vIHNhYWNrLm8gbWVhc3VyZW1vZC5vIGVzdGltYXRvci5vIGFkYy5vIG1zLWFk Yy5vIHRpbWV3aW5kb3ctZXN0Lm8gYWN0by1hZGMubyBwb2ludHNhbXBsZS1lc3QubyBzYWxpbmsu byBhY3RwLWFkYy5vIGhiLWFkYy5vIGV4cGF2Zy1lc3QubyBwYXJhbS1hZGMubyBudWxsLWVzdGlt YXRvci5vIGFkYXB0aXZlLXJlY2VpdmVyLm8gdmF0cmN2ci5vIGNvbnNyY3ZyLm8gYWdlbnQubyBt ZXNzYWdlLm8gdWRwLm8gc2Vzc2lvbi1ydHAubyBydHAubyBydGNwLm8gaXZzLm8gdGNwLm8gdGNw LXNpbmsubyB0Y3AtcmVuby5vIHRjcC1uZXdyZW5vLm8gdGNwLXZlZ2FzLm8gdGNwLXJicC5vIHRj cC1mdWxsLm8gc2NvcmVib2FyZC5vIHRjcC1zYWNrMS5vIHRjcC1mYWNrLm8gdGNwLWFzeW0ubyB0 Y3AtYXN5bS1zaW5rLm8gdGNwLWZzLm8gdGNwLWFzeW0tZnMubyB0Y3AtaW50Lm8gY2hvc3QubyB0 Y3Atc2Vzc2lvbi5vIG5pbGlzdC5vIGludGVncmF0b3IubyBxdWV1ZS1tb25pdG9yLm8gZmxvd21v bi5vIGxvc3MtbW9uaXRvci5vIHF1ZXVlLm8gZHJvcC10YWlsLm8gc2ltcGxlLWludHNlcnYtc2No ZWQubyByZWQubyBzZW1hbnRpYy1wYWNrZXRxdWV1ZS5vIHNlbWFudGljLXJlZC5vIGFjay1yZWNv bnMubyBzZnEubyBmcS5vIGRyci5vIGNicS5vIGhhY2tsb3NzLm8gZXJybW9kZWwubyBkZWxheS5v IGxsLm8gc25vb3AubyBjaGFubmVsLm8gbWFjLm8gbWFjLWNzbWEubyBtYWMtODAyXzExLm8gbWFj LW11bHRpaG9wLm8gZHluYWxpbmsubyBydFByb3RvRFYubyBuZXQtaW50ZXJmYWNlLm8gY3RyTWNh c3QubyBtY2FzdF9jdHJsLm8gc3JtLm8gc2Vzc2lvbmhlbHBlci5vIGRlbGF5bW9kZWwubyBzcm0t c3NtLm8gc3JtLXRvcG8ubyBhbGxvYy1hZGRyZXNzLm8gYWRkcmVzcy5vIGxpYi9pbnQuVmVjLm8g bGliL2ludC5SVmVjLm8gbGliL2RtYWxsb2Nfc3VwcG9ydC5vIHdlYmNhY2hlL2h0dHAubyB3ZWJj YWNoZS90Y3Atc2ltcGxlLm8gd2ViY2FjaGUvcGFnZXBvb2wubyB3ZWJjYWNoZS9pbnZhbC1hZ2Vu dC5vIHdlYmNhY2hlL3RjcGFwcC5vIHdlYmNhY2hlL2h0dHAtYXV4Lm8gbGFuUm91dGVyLm8gdGZj Yy5vIGZpbHRlci5vIGdlbi92ZXJzaW9uLm8gZ2VuL25zX3RjbC5vICB3aW4zMi5vIC1SLi4vdGNs Y2wgLUwuLi90Y2xjbCAtbHRjbGNsIC1SLi4vb3RjbCAtTC4uL290Y2wgLWxvdGNsIC1SL3Vzci9s b2NhbC9saWIgLUwvdXNyL2xvY2FsL2xpYiAtbHRrOC4wIC1SL3Vzci9sb2NhbC9saWIgLUwvdXNy L2xvY2FsL2xpYiAtbHRjbDguMCAtUi91c3Ivb3Blbndpbi9saWIgLUwvdXNyL29wZW53aW4vbGli IC1sWGV4dCAtbFgxMSAtbHNvY2tldCAtbG5zbCAtbGRsIC1sZGwgLWxtIC1sZGwgDQpVbmRlZmlu ZWQgICAgICAgICAgICAgICAgICAgICAgIGZpcnN0IHJlZmVyZW5jZWQNCiBzeW1ib2wgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGluIGZpbGUNCnNucHJpbnRmICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4uL3RjbGNsL2xpYnRjbGNsLmEoVGNsLm8pDQpsZDogZmF0YWw6IFN5bWJvbCBy ZWZlcmVuY2luZyBlcnJvcnMuIE5vIG91dHB1dCB3cml0dGVuIHRvIG5zDQptYWtlOiAqKiogW25z XSBFcnJvciAxDQoNCkJlc3QgUmVnYXJkcw0KIA0KDQoNCg== ------=_NextPart_000_002C_01BE6550.313FB3C0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5IZWxsbyAhPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5bcHJpc206L3Vz ci9sb2NhbC9ucy1hbGxpbm9uZS0yLjFiNGEvbnMtMl0jIA0KbWFrZTxCUj5jKysmbmJzcDsgLW8g bnMgXDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp0Y2xB cHBJbml0Lm8mbmJzcDsgcmFuZG9tLm8gcm5nLm8gcmFudmFyLm8gbWlzYy5vIHRpbWVyLWhhbmRs ZXIubyBzY2hlZHVsZXIubyANCm9iamVjdC5vIHBhY2tldC5vIGlwLm8gcm91dGUubyBjb25uZWN0 b3IubyB0dGwubyB0cmFjZS5vIHRyYWNlLWlwLm8gY2xhc3NpZmllci5vIA0KY2xhc3NpZmllci1h ZGRyLm8gY2xhc3NpZmllci1oYXNoLm8gY2xhc3NpZmllci12aXJ0dWFsLm8gY2xhc3NpZmllci1t Y2FzdC5vIA0KY2xhc3NpZmllci1tcGF0aC5vIHJlcGxpY2F0b3IubyBjbGFzc2lmaWVyLW1hYy5v IGFwcC5vIHRlbG5ldC5vIHRjcGxpYi10ZWxuZXQubyANCnRyYWZnZW4ubyB0cmFmZmljdHJhY2Uu byBwYXJldG8ubyBleHBvby5vIGNicl90cmFmZmljLm8gdGJmLm8gcmVzdi5vIHNhLm8gDQpzYWFj ay5vIG1lYXN1cmVtb2QubyBlc3RpbWF0b3IubyBhZGMubyBtcy1hZGMubyB0aW1ld2luZG93LWVz dC5vIGFjdG8tYWRjLm8gDQpwb2ludHNhbXBsZS1lc3QubyBzYWxpbmsubyBhY3RwLWFkYy5vIGhi LWFkYy5vIGV4cGF2Zy1lc3QubyBwYXJhbS1hZGMubyANCm51bGwtZXN0aW1hdG9yLm8gYWRhcHRp dmUtcmVjZWl2ZXIubyB2YXRyY3ZyLm8gY29uc3JjdnIubyBhZ2VudC5vIG1lc3NhZ2UubyANCnVk cC5vIHNlc3Npb24tcnRwLm8gcnRwLm8gcnRjcC5vIGl2cy5vIHRjcC5vIHRjcC1zaW5rLm8gdGNw LXJlbm8ubyB0Y3AtbmV3cmVuby5vIA0KdGNwLXZlZ2FzLm8gdGNwLXJicC5vIHRjcC1mdWxsLm8g c2NvcmVib2FyZC5vIHRjcC1zYWNrMS5vIHRjcC1mYWNrLm8gdGNwLWFzeW0ubyANCnRjcC1hc3lt LXNpbmsubyB0Y3AtZnMubyB0Y3AtYXN5bS1mcy5vIHRjcC1pbnQubyBjaG9zdC5vIHRjcC1zZXNz aW9uLm8gbmlsaXN0Lm8gDQppbnRlZ3JhdG9yLm8gcXVldWUtbW9uaXRvci5vIGZsb3dtb24ubyBs b3NzLW1vbml0b3IubyBxdWV1ZS5vIGRyb3AtdGFpbC5vIA0Kc2ltcGxlLWludHNlcnYtc2NoZWQu byByZWQubyBzZW1hbnRpYy1wYWNrZXRxdWV1ZS5vIHNlbWFudGljLXJlZC5vIGFjay1yZWNvbnMu byANCnNmcS5vIGZxLm8gZHJyLm8gY2JxLm8gaGFja2xvc3MubyBlcnJtb2RlbC5vIGRlbGF5Lm8g bGwubyBzbm9vcC5vIGNoYW5uZWwubyANCm1hYy5vIG1hYy1jc21hLm8gbWFjLTgwMl8xMS5vIG1h Yy1tdWx0aWhvcC5vIGR5bmFsaW5rLm8gcnRQcm90b0RWLm8gDQpuZXQtaW50ZXJmYWNlLm8gY3Ry TWNhc3QubyBtY2FzdF9jdHJsLm8gc3JtLm8gc2Vzc2lvbmhlbHBlci5vIGRlbGF5bW9kZWwubyAN CnNybS1zc20ubyBzcm0tdG9wby5vIGFsbG9jLWFkZHJlc3MubyBhZGRyZXNzLm8gbGliL2ludC5W ZWMubyBsaWIvaW50LlJWZWMubyANCmxpYi9kbWFsbG9jX3N1cHBvcnQubyB3ZWJjYWNoZS9odHRw Lm8gd2ViY2FjaGUvdGNwLXNpbXBsZS5vIHdlYmNhY2hlL3BhZ2Vwb29sLm8gDQp3ZWJjYWNoZS9p bnZhbC1hZ2VudC5vIHdlYmNhY2hlL3RjcGFwcC5vIHdlYmNhY2hlL2h0dHAtYXV4Lm8gbGFuUm91 dGVyLm8gdGZjYy5vIA0KZmlsdGVyLm8gZ2VuL3ZlcnNpb24ubyBnZW4vbnNfdGNsLm8mbmJzcDsg d2luMzIubyAtUi4uL3RjbGNsIC1MLi4vdGNsY2wgLWx0Y2xjbCANCi1SLi4vb3RjbCAtTC4uL290 Y2wgLWxvdGNsIC1SL3Vzci9sb2NhbC9saWIgLUwvdXNyL2xvY2FsL2xpYiAtbHRrOC4wIA0KLVIv dXNyL2xvY2FsL2xpYiAtTC91c3IvbG9jYWwvbGliIC1sdGNsOC4wIC1SL3Vzci9vcGVud2luL2xp YiAtTC91c3Ivb3Blbndpbi9saWIgDQotbFhleHQgLWxYMTEgLWxzb2NrZXQgLWxuc2wgLWxkbCAt bGRsIC1sbSAtbGRsIA0KPEJSPjxTVFJPTkc+VW5kZWZpbmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K Zmlyc3QgDQpyZWZlcmVuY2VkPEJSPiZuYnNwO3N5bWJvbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmluIA0KZmlsZTxCUj5zbnByaW50ZiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi4uL3RjbGNs L2xpYnRjbGNsLmEoVGNsLm8pPEJSPmxkOiBmYXRhbDogU3ltYm9sIHJlZmVyZW5jaW5nIGVycm9y cy4gTm8gb3V0cHV0IA0Kd3JpdHRlbiB0byBuczxCUj5tYWtlOiAqKiogW25zXSBFcnJvciAxPEJS PjwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxESVY+QmVzdCBSZWdhcmRzPC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDAwIA0Kc2l6ZT0yPjxTVFJPTkc+PC9TVFJPTkc+PC9GT05UPiZuYnNw OzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_002C_01BE6550.313FB3C0-- From johnh@ISI.EDU Tue Mar 2 23:45:45 1999 From: johnh@ISI.EDU (John Heidemann) Date: Tue, 02 Mar 1999 15:45:45 -0800 Subject: ld error In-Reply-To: <002f01be6550$317b3620$5bc0fe81@pony.etri.re.kr> Message-ID: <199903022345.PAA26452@dash.isi.edu> On Wed, 03 Mar 1999 08:31:10 GMT, "hyryu" wrote: >Hello ! > > >[prism:/usr/local/ns-allinone-2.1b4a/ns-2]# make >c++ -o ns \ >... >Undefined first referenced > symbol in file >snprintf ../tclcl/libtclcl.a(Tcl.o) >ld: fatal: Symbol referencing errors. No output written to ns >make: *** [ns] Error 1 > >Best Regards > > >  -=- MIME -=-  This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BE6550.313FB3C0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGVsbG8gIQ0KDQoNCltwcmlzbTovdXNyL2xvY2FsL25zLWFsbGlub25lLTIuMWI0YS9ucy0yXSMg bWFrZQ0KYysrICAtbyBucyBcDQogICAgICAgIHRjbEFwcEluaXQubyAgcmFuZG9tLm8gcm5nLm8g cmFudmFyLm8gbWlzYy5vIHRpbWVyLWhhbmRsZXIubyBzY2hlZHVsZXIubyBvYmplY3QubyBwYWNr ZXQubyBpcC5vIHJvdXRlLm8gY29ubmVjdG9yLm8gdHRsLm8gdHJhY2UubyB0cmFjZS1pcC5vIGNs YXNzaWZpZXIubyBjbGFzc2lmaWVyLWFkZHIubyBjbGFzc2lmaWVyLWhhc2gubyBjbGFzc2lmaWVy LXZpcnR1YWwubyBjbGFzc2lmaWVyLW1jYXN0Lm8gY2xhc3NpZmllci1tcGF0aC5vIHJlcGxpY2F0 b3IubyBjbGFzc2lmaWVyLW1hYy5vIGFwcC5vIHRlbG5ldC5vIHRjcGxpYi10ZWxuZXQubyB0cmFm Z2VuLm8gdHJhZmZpY3RyYWNlLm8gcGFyZXRvLm8gZXhwb28ubyBjYnJfdHJhZmZpYy5vIHRiZi5v IHJlc3YubyBzYS5vIHNhYWNrLm8gbWVhc3VyZW1vZC5vIGVzdGltYXRvci5vIGFkYy5vIG1zLWFk Yy5vIHRpbWV3aW5kb3ctZXN0Lm8gYWN0by1hZGMubyBwb2ludHNhbXBsZS1lc3QubyBzYWxpbmsu byBhY3RwLWFkYy5vIGhiLWFkYy5vIGV4cGF2Zy1lc3QubyBwYXJhbS1hZGMubyBudWxsLWVzdGlt YXRvci5vIGFkYXB0aXZlLXJlY2VpdmVyLm8gdmF0cmN2ci5vIGNvbnNyY3ZyLm8gYWdlbnQubyBt ZXNzYWdlLm8gdWRwLm8gc2Vzc2lvbi1ydHAubyBydHAubyBydGNwLm8gaXZzLm8gdGNwLm8gdGNw LXNpbmsubyB0Y3AtcmVuby5vIHRjcC1uZXdyZW5vLm8gdGNwLXZlZ2FzLm8gdGNwLXJicC5vIHRj cC1mdWxsLm8gc2NvcmVib2FyZC5vIHRjcC1zYWNrMS5vIHRjcC1mYWNrLm8gdGNwLWFzeW0ubyB0 Y3AtYXN5bS1zaW5rLm8gdGNwLWZzLm8gdGNwLWFzeW0tZnMubyB0Y3AtaW50Lm8gY2hvc3QubyB0 Y3Atc2Vzc2lvbi5vIG5pbGlzdC5vIGludGVncmF0b3IubyBxdWV1ZS1tb25pdG9yLm8gZmxvd21v bi5vIGxvc3MtbW9uaXRvci5vIHF1ZXVlLm8gZHJvcC10YWlsLm8gc2ltcGxlLWludHNlcnYtc2No ZWQubyByZWQubyBzZW1hbnRpYy1wYWNrZXRxdWV1ZS5vIHNlbWFudGljLXJlZC5vIGFjay1yZWNv bnMubyBzZnEubyBmcS5vIGRyci5vIGNicS5vIGhhY2tsb3NzLm8gZXJybW9kZWwubyBkZWxheS5v IGxsLm8gc25vb3AubyBjaGFubmVsLm8gbWFjLm8gbWFjLWNzbWEubyBtYWMtODAyXzExLm8gbWFj LW11bHRpaG9wLm8gZHluYWxpbmsubyBydFByb3RvRFYubyBuZXQtaW50ZXJmYWNlLm8gY3RyTWNh c3QubyBtY2FzdF9jdHJsLm8gc3JtLm8gc2Vzc2lvbmhlbHBlci5vIGRlbGF5bW9kZWwubyBzcm0t c3NtLm8gc3JtLXRvcG8ubyBhbGxvYy1hZGRyZXNzLm8gYWRkcmVzcy5vIGxpYi9pbnQuVmVjLm8g bGliL2ludC5SVmVjLm8gbGliL2RtYWxsb2Nfc3VwcG9ydC5vIHdlYmNhY2hlL2h0dHAubyB3ZWJj YWNoZS90Y3Atc2ltcGxlLm8gd2ViY2FjaGUvcGFnZXBvb2wubyB3ZWJjYWNoZS9pbnZhbC1hZ2Vu dC5vIHdlYmNhY2hlL3RjcGFwcC5vIHdlYmNhY2hlL2h0dHAtYXV4Lm8gbGFuUm91dGVyLm8gdGZj Yy5vIGZpbHRlci5vIGdlbi92ZXJzaW9uLm8gZ2VuL25zX3RjbC5vICB3aW4zMi5vIC1SLi4vdGNs Y2wgLUwuLi90Y2xjbCAtbHRjbGNsIC1SLi4vb3RjbCAtTC4uL290Y2wgLWxvdGNsIC1SL3Vzci9s b2NhbC9saWIgLUwvdXNyL2xvY2FsL2xpYiAtbHRrOC4wIC1SL3Vzci9sb2NhbC9saWIgLUwvdXNy L2xvY2FsL2xpYiAtbHRjbDguMCAtUi91c3Ivb3Blbndpbi9saWIgLUwvdXNyL29wZW53aW4vbGli IC1sWGV4dCAtbFgxMSAtbHNvY2tldCAtbG5zbCAtbGRsIC1sZGwgLWxtIC1sZGwgDQpVbmRlZmlu ZWQgICAgICAgICAgICAgICAgICAgICAgIGZpcnN0IHJlZmVyZW5jZWQNCiBzeW1ib2wgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGluIGZpbGUNCnNucHJpbnRmICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4uL3RjbGNsL2xpYnRjbGNsLmEoVGNsLm8pDQpsZDogZmF0YWw6IFN5bWJvbCBy ZWZlcmVuY2luZyBlcnJvcnMuIE5vIG91dHB1dCB3cml0dGVuIHRvIG5zDQptYWtlOiAqKiogW25z XSBFcnJvciAxDQoNCkJlc3QgUmVnYXJkcw0KIA0KDQoNCg== ------=_NextPart_000_002C_01BE6550.313FB3C0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5IZWxsbyAhPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5bcHJpc206L3Vz ci9sb2NhbC9ucy1hbGxpbm9uZS0yLjFiNGEvbnMtMl0jIA0KbWFrZTxCUj5jKysmbmJzcDsgLW8g bnMgXDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp0Y2xB cHBJbml0Lm8mbmJzcDsgcmFuZG9tLm8gcm5nLm8gcmFudmFyLm8gbWlzYy5vIHRpbWVyLWhhbmRs ZXIubyBzY2hlZHVsZXIubyANCm9iamVjdC5vIHBhY2tldC5vIGlwLm8gcm91dGUubyBjb25uZWN0 b3IubyB0dGwubyB0cmFjZS5vIHRyYWNlLWlwLm8gY2xhc3NpZmllci5vIA0KY2xhc3NpZmllci1h ZGRyLm8gY2xhc3NpZmllci1oYXNoLm8gY2xhc3NpZmllci12aXJ0dWFsLm8gY2xhc3NpZmllci1t Y2FzdC5vIA0KY2xhc3NpZmllci1tcGF0aC5vIHJlcGxpY2F0b3IubyBjbGFzc2lmaWVyLW1hYy5v IGFwcC5vIHRlbG5ldC5vIHRjcGxpYi10ZWxuZXQubyANCnRyYWZnZW4ubyB0cmFmZmljdHJhY2Uu byBwYXJldG8ubyBleHBvby5vIGNicl90cmFmZmljLm8gdGJmLm8gcmVzdi5vIHNhLm8gDQpzYWFj ay5vIG1lYXN1cmVtb2QubyBlc3RpbWF0b3IubyBhZGMubyBtcy1hZGMubyB0aW1ld2luZG93LWVz dC5vIGFjdG8tYWRjLm8gDQpwb2ludHNhbXBsZS1lc3QubyBzYWxpbmsubyBhY3RwLWFkYy5vIGhi LWFkYy5vIGV4cGF2Zy1lc3QubyBwYXJhbS1hZGMubyANCm51bGwtZXN0aW1hdG9yLm8gYWRhcHRp dmUtcmVjZWl2ZXIubyB2YXRyY3ZyLm8gY29uc3JjdnIubyBhZ2VudC5vIG1lc3NhZ2UubyANCnVk cC5vIHNlc3Npb24tcnRwLm8gcnRwLm8gcnRjcC5vIGl2cy5vIHRjcC5vIHRjcC1zaW5rLm8gdGNw LXJlbm8ubyB0Y3AtbmV3cmVuby5vIA0KdGNwLXZlZ2FzLm8gdGNwLXJicC5vIHRjcC1mdWxsLm8g c2NvcmVib2FyZC5vIHRjcC1zYWNrMS5vIHRjcC1mYWNrLm8gdGNwLWFzeW0ubyANCnRjcC1hc3lt LXNpbmsubyB0Y3AtZnMubyB0Y3AtYXN5bS1mcy5vIHRjcC1pbnQubyBjaG9zdC5vIHRjcC1zZXNz aW9uLm8gbmlsaXN0Lm8gDQppbnRlZ3JhdG9yLm8gcXVldWUtbW9uaXRvci5vIGZsb3dtb24ubyBs b3NzLW1vbml0b3IubyBxdWV1ZS5vIGRyb3AtdGFpbC5vIA0Kc2ltcGxlLWludHNlcnYtc2NoZWQu byByZWQubyBzZW1hbnRpYy1wYWNrZXRxdWV1ZS5vIHNlbWFudGljLXJlZC5vIGFjay1yZWNvbnMu byANCnNmcS5vIGZxLm8gZHJyLm8gY2JxLm8gaGFja2xvc3MubyBlcnJtb2RlbC5vIGRlbGF5Lm8g bGwubyBzbm9vcC5vIGNoYW5uZWwubyANCm1hYy5vIG1hYy1jc21hLm8gbWFjLTgwMl8xMS5vIG1h Yy1tdWx0aWhvcC5vIGR5bmFsaW5rLm8gcnRQcm90b0RWLm8gDQpuZXQtaW50ZXJmYWNlLm8gY3Ry TWNhc3QubyBtY2FzdF9jdHJsLm8gc3JtLm8gc2Vzc2lvbmhlbHBlci5vIGRlbGF5bW9kZWwubyAN CnNybS1zc20ubyBzcm0tdG9wby5vIGFsbG9jLWFkZHJlc3MubyBhZGRyZXNzLm8gbGliL2ludC5W ZWMubyBsaWIvaW50LlJWZWMubyANCmxpYi9kbWFsbG9jX3N1cHBvcnQubyB3ZWJjYWNoZS9odHRw Lm8gd2ViY2FjaGUvdGNwLXNpbXBsZS5vIHdlYmNhY2hlL3BhZ2Vwb29sLm8gDQp3ZWJjYWNoZS9p bnZhbC1hZ2VudC5vIHdlYmNhY2hlL3RjcGFwcC5vIHdlYmNhY2hlL2h0dHAtYXV4Lm8gbGFuUm91 dGVyLm8gdGZjYy5vIA0KZmlsdGVyLm8gZ2VuL3ZlcnNpb24ubyBnZW4vbnNfdGNsLm8mbmJzcDsg d2luMzIubyAtUi4uL3RjbGNsIC1MLi4vdGNsY2wgLWx0Y2xjbCANCi1SLi4vb3RjbCAtTC4uL290 Y2wgLWxvdGNsIC1SL3Vzci9sb2NhbC9saWIgLUwvdXNyL2xvY2FsL2xpYiAtbHRrOC4wIA0KLVIv dXNyL2xvY2FsL2xpYiAtTC91c3IvbG9jYWwvbGliIC1sdGNsOC4wIC1SL3Vzci9vcGVud2luL2xp YiAtTC91c3Ivb3Blbndpbi9saWIgDQotbFhleHQgLWxYMTEgLWxzb2NrZXQgLWxuc2wgLWxkbCAt bGRsIC1sbSAtbGRsIA0KPEJSPjxTVFJPTkc+VW5kZWZpbmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K Zmlyc3QgDQpyZWZlcmVuY2VkPEJSPiZuYnNwO3N5bWJvbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmluIA0KZmlsZTxCUj5zbnByaW50ZiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCi4uL3RjbGNs L2xpYnRjbGNsLmEoVGNsLm8pPEJSPmxkOiBmYXRhbDogU3ltYm9sIHJlZmVyZW5jaW5nIGVycm9y cy4gTm8gb3V0cHV0IA0Kd3JpdHRlbiB0byBuczxCUj5tYWtlOiAqKiogW25zXSBFcnJvciAxPEJS PjwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxESVY+QmVzdCBSZWdhcmRzPC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBjb2xvcj0jMDAwMDAwIA0Kc2l6ZT0yPjxTVFJPTkc+PC9TVFJPTkc+PC9GT05UPiZuYnNw OzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_002C_01BE6550.313FB3C0-- Snprintf is needed as the error message says in tclcl. Part of the tclcl configure process should see if your system has it and use the provided definition if not. See the HAVE_SNPRINTF ifdefs. What platform are you running on? Can you look at tclcl's configure script to see why it thought that you had snprintf when you don't? You can work around the problem by setting HAVE_SNPRINTF, but it would be nice to know why configure fails on your system when it work on ours. -John Heidemann From david@melbourneit.com.au Wed Mar 3 04:17:27 1999 From: david@melbourneit.com.au (David Lapsley) Date: Wed, 3 Mar 1999 15:17:27 +1100 Subject: TCP RTT esimates Message-ID: <99030315342004.26124@defiant.melbourneit.com.au> Dear All, I've been looking at the source code for the TCP Agent in tcp.cc and something does not seem right. I would appreciate any help. The lines that confuse me are: if (t_srtt_ != 0) { register short delta; >>>> delta = t_rtt_ - (t_srtt_ >> T_SRTT_BITS); // d = (m - a0) if ((t_srtt_ += delta) <= 0) // a1 = 7/8 a0 + 1/8 m t_srtt_ = 1; Where t_srtt_ is the smoothed(average) round trip time, and t_rtt_ is the current round trip time sample. According to this code, the final value of t_srtt_ is 7/8 of the previous t_srtt_ + the new round trip time sample t_rtt_. It should be 7/8 of the previous t_srtt_ + 1/8 of rtt_. If the marked line above read: >>>> delta = (t_rtt_ - t_srtt_ )>> T_SRTT_BITS; // d = (m - a0) Am I missing something embarassingly obvious? If so, please let me know. I apologize if this has already been discussed, but I have done a (quick) search through the mailing list archives. Thanks in advance, David. -- David Lapsley, Research Engineer Melbourne Information Technologies Australia Pty. Ltd. 3/207 Bouverie Street, Carlton, Vic. 3053, Australia Telephone: +61 3 9344 9386, Facsimile: +61 3 9347 9473 From vishnu@cs.ucr.edu Wed Mar 3 05:02:44 1999 From: vishnu@cs.ucr.edu (Natchu Vishnu Priya) Date: Tue, 2 Mar 1999 21:02:44 -0800 (PST) Subject: TCP RTT esimates In-Reply-To: <99030315342004.26124@defiant.melbourneit.com.au> Message-ID: On Wed, 3 Mar 1999, David Lapsley wrote: > Dear All, > > I've been looking at the source code for the TCP Agent > in tcp.cc and something does not seem right. > I would appreciate any help. > > The lines that confuse me are: > > if (t_srtt_ != 0) { > register short delta; > >>>> delta = t_rtt_ - (t_srtt_ >> T_SRTT_BITS); // d = (m - a0) > if ((t_srtt_ += delta) <= 0) // a1 = 7/8 a0 + 1/8 m > t_srtt_ = 1; > > Where t_srtt_ is the smoothed(average) round trip time, and t_rtt_ is the > current round trip time sample. > > According to this code, the final value of t_srtt_ is 7/8 of the previous > t_srtt_ + the new round trip time sample t_rtt_. It should be 7/8 of the > previous t_srtt_ + 1/8 of rtt_. t_srtt_ is 8 * "smoothed round trip time" its easier to maintain it that way.. a little more presicion and less shifts. vishnu From p.losi@netline.it Wed Mar 3 07:40:25 1999 From: p.losi@netline.it (Paolo Losi) Date: Wed, 03 Mar 1999 07:40:25 +0000 Subject: PGPS code Message-ID: <36DCE769.7C8EE391@netline.it> This is a message for everyone interested in the PGPS code. I'm asking for a permission to distribute the code and building up a web page. I'll send a message to the mailing-list by the end of the week to give some more info. Thanks Paolo Paolo Losi p.losi@netline.it From thlinh@dit.hcmut.edu.vn Wed Mar 3 16:48:55 1999 From: thlinh@dit.hcmut.edu.vn (Truong Hong Linh) Date: Wed, 3 Mar 1999 16:48:55 -0000 Subject: Can not download software Message-ID: <000701be6595$bab7e920$2c0a1cac@thlinh.dit.hcmut.edu.vn> This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BE6595.BA20D940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all ! I am can not download your software from this link : Download source: current release 2.1b4a (released 19-Nov-98)=20 I don't know what happen.Can you help me ? I am looking forward you ! Truong Hong Linh Lecturer , IT Department. HCMC University of Technology, VietNam ------=_NextPart_000_0004_01BE6595.BA20D940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all !
I am can not download your software = from this=20 link :
       =20 Download source: current=20 release 2.1b4a (released 19-Nov-98)
I don't know what happen.Can you = help me=20 ?
 
I am looking forward you = !
 
Truong Hong Linh
Lecturer , IT = Department.
HCMC University of Technology,=20 VietNam
------=_NextPart_000_0004_01BE6595.BA20D940-- From eroesch@iutsud.u-strasbg.fr Wed Mar 3 12:44:32 1999 From: eroesch@iutsud.u-strasbg.fr (eroesch@iutsud.u-strasbg.fr) Date: Wed, 03 Mar 1999 13:44:32 +0100 Subject: [ns] Adding new protocols.. Message-ID: <3.0.1.32.19990303134432.00934e60@iutsud.u-strasbg.fr> Hello ! I am a french national studying in the second year at the University of Technology in Strasbourg, in Computer Sciences, and study ns as part of a final project. I tried to implement new protocols (ie. ping), as described in the tutorial .. but it doesn't work .. :( It compils, but nothing is sent .. i think it is a matter of the inheritance of the classes used by ns .. Has anyone ever tried to implement new protocols ? Ooops, I don't have my sources .. i will send them tomorow ;) Thanks in advance ----- Etienne From maria@cs.columbia.edu Wed Mar 3 15:16:38 1999 From: maria@cs.columbia.edu (Maria Papadopouli) Date: Wed, 3 Mar 1999 10:16:38 -0500 (EST) Subject: Metricom's Ricochet Modem: link delay/bandwidth capabilities ? Message-ID: <199903031516.KAA14194@merlot.cs.columbia.edu> Hello, I would like to do some simulations in which some of the links are Metricom's Ricochet, and I was wondering what would be a reasonable estimation for the link delays and bandwidth capabilities of this modem (and if there are predictions/info for the next generation Ricochet modem). Unfortunately I don't have a Ricochet modem to test it, so I was wondering if you could give me some references. I saw that in the ns-2 simulator, you have the following setup (for the MAC layer) . However, in some other papers, they mention different numbers for link delays and bw for the Ricochet modem, (e.g.,, an "actual" estimation of the roundtrip delay to be around 325ms). I understand that it is difficult to capture the wireless connection, since there are all these different parameters and conditions that could affect the performance, but if we simulate the connection of a Ricochet user as a link, would it be reasonable to use for bandwidth=100Kb and link delay 100ms ? Thanks for your consideration, Maria From sva0392@tntech.edu Wed Mar 3 15:27:46 1999 From: sva0392@tntech.edu (Syamsundar V Appala) Date: Wed, 03 Mar 1999 09:27:46 -0600 (CST) Subject: Packet losses in SRM ? Message-ID: Hi Everybody, How can you monitor the packets received or lost by a SRM receiver. The log file and trace files of SRM doesn't provide that information . Please let me.I'll appreciate the help. Thanks Sincerely, SYam Appala ----------------------------------------------------------------------------- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. -- E. B. White ----------------------------------------------------------------------------- Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. THAT's relativity." -- Albert Einstein ----------------------------------------------------------------------------- ..::''''::.. .;'' ``;. :: :: :: :: :: :: :: :: :: .:' :: :: `:. :: :: : : :: :: `:. .:' :: `;..``::::''..;' ``::,,,,::'' From yuri@who.isi.edu Wed Mar 3 17:21:37 1999 From: yuri@who.isi.edu (Yuri Pryadkin) Date: 03 Mar 1999 09:21:37 -0800 Subject: TCP RTT esimates In-Reply-To: Natchu Vishnu Priya's message of "Tue, 2 Mar 1999 21:02:44 -0800 (PST)" References: Message-ID: > > if (t_srtt_ != 0) { > > register short delta; > > >>>> delta = t_rtt_ - (t_srtt_ >> T_SRTT_BITS); // d = (m - a0) > > if ((t_srtt_ += delta) <= 0) // a1 = 7/8 a0 + 1/8 m > > t_srtt_ = 1; > > > > Where t_srtt_ is the smoothed(average) round trip time, and t_rtt_ is the > > current round trip time sample. > > > > According to this code, the final value of t_srtt_ is 7/8 of the previous > > t_srtt_ + the new round trip time sample t_rtt_. It should be 7/8 of the > > previous t_srtt_ + 1/8 of rtt_. > > t_srtt_ is 8 * "smoothed round trip time" > its easier to maintain it that way.. a little more presicion and less > shifts. BTW, it doesn't seem necessary to check if (t_srtt_+= delta) <= 0. From Dah Ming Chiu - Sun Microsystems Wed Mar 3 18:03:59 1999 From: Dah Ming Chiu - Sun Microsystems (Dah Ming Chiu - Sun Microsystems) Date: Wed, 3 Mar 1999 13:03:59 -0500 (EST) Subject: "message too big" error Message-ID: <199903031803.NAA11942@bridge.East.Sun.COM> I got a "message too big" error. My agent inherits from Agent/Message, so this must be caused by some default packet (header) size in Agent/Message. Can someone explain how I should fix this problem? Thanks Dah Ming Chiu ps error message attached: -------------------------------------------- ns: _o1407 send-next: message too big (_o1407 cmd line 1) invoked from within "_o1407 cmd send {hello 513 245 26 63 22 63 27 63 23 63 28 63 24 63 20 63 29 63 21 63}" invoked from within "catch "$self cmd $args" ret" (procedure "_o1407" line 2) (SplitObject unknown line 2) invoked from within ... From chris@cs.vu.nl Wed Mar 3 18:39:45 1999 From: chris@cs.vu.nl (Christoph Haenle) Date: Wed, 03 Mar 1999 19:39:45 +0100 Subject: Packet losses in SRM ? In-Reply-To: Your message of "Tue, 02 Mar 1999 12:34:31 MET." Message-ID: Hi Syam, you can perform the following patch: Edit srm.cc and look for the passage: void SRMAgent::recv_data(int sender, int msgid, u_char*) { Tcl& tcl = Tcl::instance(); SRMinfo* sp = get_state(sender); if (msgid > sp->ldata_) { (void) request(sp, msgid - 1); sp->setReceived(msgid); sp->ldata_ = msgid; } else { tcl.evalf("%s recv data %d %d", name_, sender, msgid); } } This is where an SRM participant receives data packets. As you can see from the tcl.evalf statement, the tcl-function "recv-data" is only called for data packets which were previously detected as lost and for which consequently a request-timer was already scheduled; the timer is cancelled in the tcl function). This can have two reasons: 1.): The data packet arrives out-of-order wrt. other data packets 2.): The data packet was delayed so much that some request or repair packet with equal or higher sequence number than the data packet was received. If you want to detect lost data packets, you should comment out the else-statement and log the reception of the data packet in recv-data (see srm.tcl file). Later, figure out from the logfile what data packets were received and the missing ones are your losses. -Chris. From maria@cs.columbia.edu Wed Mar 3 18:49:09 1999 From: maria@cs.columbia.edu (Maria Papadopouli) Date: Wed, 3 Mar 1999 13:49:09 -0500 (EST) Subject: Metricom's Ricochet Modem: link delay/bandwidth capabilities ? Message-ID: <199903031849.NAA14908@merlot.cs.columbia.edu> Hello, I would like to do some simulations in which some of the links are Metricom's Ricochet, and I was wondering what would be a reasonable estimation for the link delays and bandwidth capabilities of this modem (and if there are predictions/info for the next generation Ricochet modem). Unfortunately I don't have a Ricochet modem to test it, so I was wondering if you could give me some references. I saw that in the ns-2 simulator, you have the following setup (for the MAC layer) . However, in some other papers, they mention different numbers for link delays and bw for the Ricochet modem, (e.g.,, an "actual" estimation of the roundtrip delay to be around 325ms). I understand that it is difficult to capture the wireless connection, since there are all these different parameters and conditions that could affect the performance, but if we simulate the connection of a Ricochet user as a *point-to-point link*, would it be reasonable to use for bandwidth=100Kb and link delay 100ms ? Thanks for your consideration, Maria From haoboy@isi.edu Wed Mar 3 18:49:52 1999 From: haoboy@isi.edu (Haobo Yu) Date: Wed, 3 Mar 1999 10:49:52 -0800 (PST) Subject: "message too big" error In-Reply-To: <199903031803.NAA11942@bridge.East.Sun.COM> Message-ID: The maximum message size in Agent/Message is defined in ~ns/message.h, which is 64 bytes. If you want bigger message size, you can either implement your own agent to include your own data inside the userdata area of a packet, or to modify message.h to increase the maximum message size. - Haobo On Wed, 3 Mar 1999, Dah Ming Chiu - Sun Microsystems wrote: > I got a "message too big" error. My agent inherits from Agent/Message, so > this must be caused by some default packet (header) size in Agent/Message. > Can someone explain how I should fix this problem? > > Thanks > > Dah Ming Chiu > > ps error message attached: > -------------------------------------------- > ns: _o1407 send-next: message too big > (_o1407 cmd line 1) > invoked from within > "_o1407 cmd send {hello 513 245 26 63 22 63 27 63 23 63 28 63 24 63 20 63 29 63 > 21 63}" > invoked from within > "catch "$self cmd $args" ret" > (procedure "_o1407" line 2) > (SplitObject unknown line 2) > invoked from within > ... > > From rli@bachman.cs.ou.edu Wed Mar 3 21:14:43 1999 From: rli@bachman.cs.ou.edu (Rui Li) Date: Wed, 3 Mar 1999 15:14:43 -0600 (CST) Subject: Problem Message-ID: Hi, I have just installed a current ns release 2.1b4a into my computer(under Sun 4.0). It has passed the validation. But when I run some examples downloaded from Marc Greis's tutorial web pages, nothing happens but just enters the ns environment. There is even no error message or other prompt. Do you have the same experience? Can you do me a favor to tell me the solution? Thanks. Sincerely, Rui From johnh@ISI.EDU Wed Mar 3 21:27:00 1999 From: johnh@ISI.EDU (John Heidemann) Date: Wed, 03 Mar 1999 13:27:00 -0800 Subject: Problem In-Reply-To: Message-ID: <199903032127.NAA30028@dash.isi.edu> On Wed, 03 Mar 1999 15:14:43 CST, Rui Li wrote: >Hi, > >I have just installed a current ns release 2.1b4a into my >computer(under Sun 4.0). It has passed the validation. But when I run some >examples downloaded from Marc Greis's tutorial web pages, nothing happens >but just enters the ns environment. There is even no error message or >other prompt. Do you have the same experience? Can you do me a favor to >tell me the solution? Thanks. I believe there were some problems with his examples in the last release, but don't remember the specifics (you might try looking in the mailing list archives). The upcoming release (and current snapshots) contains a test suite that includes Marc's sample problems so divergence between the samples and the implementation should be automatically caught. (And either fixed or documented.) -John Heidemann From mallman@lerc.nasa.gov Wed Mar 3 21:42:20 1999 From: mallman@lerc.nasa.gov (Mark Allman) Date: Wed, 03 Mar 1999 16:42:20 -0500 Subject: icmp messages Message-ID: <199903032142.QAA03723@guns.lerc.nasa.gov> Folks- I am stumped. I want to generate an ICMP-like source quesnch message in ns, somehow. But, I want there to be some sort of interaction with a queue. Basically, what I want is when a bunch of conditions happen in the queueing routines I generate an SQ in the opposite direction (back to the sender). However, from poking at the code for awhile, it would seem that it is very difficult to generate a new segment that is going in the opposite direction in the queueing routines. Is that true? Am I missing something? Does anyone have a suggestion for a way to do this? Any help/pointers would be appreciated. allman --- http://roland.grc.nasa.gov/~mallman/ From johnh@ISI.EDU Wed Mar 3 21:53:24 1999 From: johnh@ISI.EDU (John Heidemann) Date: Wed, 03 Mar 1999 13:53:24 -0800 Subject: Can not download software In-Reply-To: <000701be6595$bab7e920$2c0a1cac@thlinh.dit.hcmut.edu.vn> Message-ID: <199903032153.NAA30472@dash.isi.edu> On Wed, 03 Mar 1999 16:48:55 GMT, "Truong Hong Linh" wrote: >Hi all ! >I am can not download your software from this link : > Download source: current release 2.1b4a (released 19-Nov-98) >I don't know what happen.Can you help me ? > >I am looking forward you ! We can't really help you if you're so vague about the problem. BUT... please see the 2nd (!) entry on ns installation problems and bug fixes web page for some suggestions to this FAQ. -John Heidemann From greis@cs.uni-bonn.de Wed Mar 3 22:49:20 1999 From: greis@cs.uni-bonn.de (Marc Greis) Date: Wed, 3 Mar 1999 23:49:20 +0100 (MET) Subject: Problem In-Reply-To: <199903032127.NAA30028@dash.isi.edu> from "John Heidemann" at Mar 3, 99 01:27:00 pm Message-ID: <199903032249.XAA02362@zeus.informatik.uni-bonn.de> John Heidemann wrote: > On Wed, 03 Mar 1999 15:14:43 CST, Rui Li wrote: > >Hi, > > > >I have just installed a current ns release 2.1b4a into my > >computer(under Sun 4.0). It has passed the validation. But when I run some > >examples downloaded from Marc Greis's tutorial web pages, nothing happens > >but just enters the ns environment. There is even no error message or > >other prompt. Do you have the same experience? Can you do me a favor to > >tell me the solution? Thanks. Hm... I don't think I really understand what you (Rui Li) mean with "enters the ns environment" here. > I believe there were some problems with his examples in the last > release, but don't remember the specifics (you might try looking in > the mailing list archives). I have to admit that I am somewhat behind with checking my examples with the newer releases, especially since I am still using my "hacked" 2.1b3 version. ;) But the only "problem" that I have heard of so far was that ns had to use the backward compatibility mode, so I assumed that there weren't any serious problems. > The upcoming release (and current snapshots) contains a test suite > that includes Marc's sample problems so divergence between the samples > and the implementation should be automatically caught. (And either > fixed or documented.) That would be a great help! Another note: Usually, when there's a problem with the examples from the tutorial, it's probably best to contact just me instead of the whole mailing list, unless it seems to be a problem with ns itself. Marc -- Marc Greis greis@cs.uni-bonn.de From softrel9@nortelnetworks.com Wed Mar 3 23:09:03 1999 From: softrel9@nortelnetworks.com (Sarah Liu) Date: Wed, 3 Mar 1999 18:09:03 -0500 Subject: dropped packet in nam Message-ID: <03E3E0690542D211A1490000F80836F43E45C7@zcard00f.ca.nortel.com> Hi, Haobo: Following your suggetion, I modified the ns-lib.tcl and ns-link.tcl, then rebulit the ns. Now the visualization of dropped packet is working. Thanks a lot. Sarah ---------------------------------------------------------------------------- -------------------------------- Sarah Xiaohui Liu, 613-765-3203 o__ o~__ Email: softrel9@nortelnetworks.com _,>/_ _,>/_ u1452573@csi.uottawa.ca (*) (*) (*) (*) Mail Stop: 0C32, Nortel Networks Corp. ---------------------------------------------------------------------------- -------------------------------- From anandr@cs.ucsb.edu Wed Mar 3 23:23:04 1999 From: anandr@cs.ucsb.edu (Anand P. Rangarajan) Date: Wed, 3 Mar 1999 15:23:04 -0800 (PST) Subject: icmp messages In-Reply-To: <199903032142.QAA03723@guns.lerc.nasa.gov> from "Mark Allman" at Mar 3, 99 04:42:20 pm Message-ID: <199903032323.PAA27394@ease.cs.ucsb.edu> hi mark, i had to implement the same. my requirement was to send an icmp source quench message to source A whenever a router drops a packet from source A. the way i did it is like this: * define an ICMP agent * each node has an ICMP agent residing on port 0. this is done whenever you create the node. * the queueing mechanism in the router has a pointer to the icmp agent in the router( you can just derive a class from whatever queueing mechanism you like and add the pointer field) this is done when a simplex-link from the router is created * when the queue drops a packet, it calls the sendSourceQuench(pkt) method in the icmp agent using the pointer to the icmp agent. * since the icmp agent always resides in port 0, it is easy to find the destination agent for the icmp source quench pkt from the src field in "pkt" * use the send function to send the packet. hope it helps. -Anand -- Anand P. Rangarajan Email: anandr@cs.ucsb.edu Graduate Student, Comp. Science URL : http://www.cs.ucsb.edu/~anandr UCSB, CA - 93117, USA Phone: (805) 562 8703(H),805 893 5731(O) > > > Folks- > > I am stumped. I want to generate an ICMP-like source quesnch > message in ns, somehow. But, I want there to be some sort of > interaction with a queue. Basically, what I want is when a bunch of > conditions happen in the queueing routines I generate an SQ in the > opposite direction (back to the sender). However, from poking at > the code for awhile, it would seem that it is very difficult to > generate a new segment that is going in the opposite direction in > the queueing routines. Is that true? Am I missing something? Does > anyone have a suggestion for a way to do this? > > Any help/pointers would be appreciated. > > allman > > > --- > http://roland.grc.nasa.gov/~mallman/ > From Lloyd Wood Thu Mar 4 00:06:03 1999 From: Lloyd Wood (Lloyd Wood) Date: Thu, 4 Mar 1999 00:06:03 +0000 (GMT) Subject: third-party ns stuff I turned up Message-ID: Having just realised that the berkeley ns contributed-code web pages only stretch to stuff that they've been contacted about by authors of said stuff, I went searching to see if there was any other stuff out there; here's some useful-looking stuff I hadn't seen/mentioned before (ignoring results pertaining to berkeley/isi stuff)... Code: http://www.infres.enst.fr/~dax/guides/ns-nam/ http://www-stud.enst.fr/~vinot/ns-nam/accueil.htm tutorial, presentation, project report in French. (is there anything Phillippe doesn't stretch to?) http://www-stud.enst.fr/~michon/realisations.html http://www-stud.enst.fr/~michon/opus/hach.tgz provides rest of stuff, including scripts, behind report. http://klamath.stanford.edu/~aaa/tcp-bfa/ TCP buffer fill avoidance stuff. http://wwwcip.rus.uni-stuttgart.de/~inf13425/projects/virtualclock/ virtual clock scheduler for QoS enforcement via timestamps. http://www.eecs.umich.edu/~wuchang/red/ (probably completely obsolete) RED for ns v1. Tutorials: http://www.okada.ecip.nagoya-u.ac.jp/~susumu/sim/ns/ getting started in Japanese. http://www.fukt.hk-r.se/projekt/netSim/ getting started comprehensively in Swedish. http://www.docs.uu.se/~perg/course/datakom2/it98/tcpsims_lab.html comparing tcp variants. http://ucsub.colorado.edu/~la/otcl/tutorial.html yet another mirror of that OTcl tutorial. ...and then there's RFC2415 in particular. didn't bother scanning stuff in drafts. Of course, I haven't used this stuff in any depth. Caveat surfer said stuff. There's probably more stuff out there, but I got tired of wading through stuff from search engines, and I have other stuff to do. cheers, L. www.google.com gets my vote; if there was a ballot, I'd stuff the box. PGP From hyryu@etri.re.kr Thu Mar 4 09:08:50 1999 From: hyryu@etri.re.kr (hyryu) Date: Thu, 4 Mar 1999 09:08:50 -0000 Subject: ld error Message-ID: <005201be661e$a0591fc0$5bc0fe81@pony.etri.re.kr> This is a multi-part message in MIME format. ------=_NextPart_000_004F_01BE661E.9E586DC0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNCm1ha2UgZXJyb3IgbWVzc2FnZSBhcyBiZWxvdw0KDQpVbmRlZmluZWQgICAgICAgICAg ICAgICAgICAgICAgIGZpcnN0IHJlZmVyZW5jZWQNCiBzeW1ib2wgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGluIGZpbGUNCnNucHJpbnRmICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4u L3RjbGNsL2xpYnRjbGNsLmEoVGNsLm8pDQpsZDogZmF0YWw6IFN5bWJvbCByZWZlcmVuY2luZyBl cnJvcnMuIE5vIG91dHB1dCB3cml0dGVuIHRvIG5zDQptYWtlOiAqKiogW25zXSBFcnJvciAxDQoN Ckkgd2lzaCB0aGUgcHJvYmxlbSB0byBiZSBzZXR0bGVkIHNvb24NCg0KUGxlYXNlLCBZb3UgZ2l2 ZSBhIGZ1bGwgZGV0YWlsIG9mIHRoZSBwcm9ibGVtIHRvIG1lLg0KDQpCZXN0IFJlZ2FyZHMgDQoN CkhveW9uZyBSeXUuDQoNCg== ------=_NextPart_000_004F_01BE661E.9E586DC0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48U1RST05HPjxVPjwvVT48L1NUUk9O Rz5IaSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPm1ha2UgZXJyb3IgbWVzc2FnZSBhcyBi ZWxvdzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMw MDAwMDAgDQpzaXplPTI+PFNUUk9ORz48VT5VbmRlZmluZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpm aXJzdCANCnJlZmVyZW5jZWQ8QlI+Jm5ic3A7c3ltYm9sJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaW4gDQpmaWxlPEJSPnNucHJpbnRmJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KLi4vdGNsY2wv bGlidGNsY2wuYShUY2wubyk8QlI+bGQ6IGZhdGFsOiBTeW1ib2wgcmVmZXJlbmNpbmcgZXJyb3Jz LiBObyBvdXRwdXQgDQp3cml0dGVuIHRvIG5zPEJSPm1ha2U6ICoqKiBbbnNdIEVycm9yIDE8L1U+ PC9TVFJPTkc+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48 U1RST05HPjxVPjwvVT48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwMDAgc2l6ZT0yPkkgd2lzaCB0aGUgcHJvYmxlbSB0byBiZSBzZXR0bGVkIA0Kc29v bjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5QbGVhc2UsIFlvdSBn aXZlIGEgZnVsbCBkZXRhaWwgb2YgdGhlIHByb2JsZW0gdG8gDQptZS48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkJlc3QgUmVnYXJkcyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Ib3lvbmcgUnl1LjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_004F_01BE661E.9E586DC0-- From Jeff_Donahoo@baylor.edu Thu Mar 4 00:26:24 1999 From: Jeff_Donahoo@baylor.edu (Jeff Donahoo) Date: Wed, 03 Mar 1999 18:26:24 -0600 Subject: Make depend problems w/ NS Message-ID: <004701be65d5$a2794ad0$0f943e81@lisa.baylor.edu> Hi! I have downloaded and compiled the all in one (2.1b4a) package on a Linux (RH 5.1/Kernel 2.0.34) machine. The install and validate went without a hitch. I am able to run NS on the tcl/ex tcl files without a problem. When I try a "make depend" on ns, I get the following: emulate/net-pcap.cc:60: pcap.h: No such file or directory In file included from emulate/arp.cc:59: emulate/ether.h:4: warning: `ETHER_ADDR_LEN' redefined /usr/include/net/ethernet.h:52: warning: this is the location of the previous de finition emulate/ether.h:7: warning: `ETHER_HDR_LEN' redefined /usr/include/net/ethernet.h:55: warning: this is the location of the previous de finition emulate/ether.h:8: warning: `ETHER_MIN_LEN' redefined /usr/include/net/ethernet.h:56: warning: this is the location of the previous de finition emulate/ether.h:9: warning: `ETHER_MAX_LEN' redefined /usr/include/net/ethernet.h:57: warning: this is the location of the previous de finition Is the "No such file or directory" for pcap.h a problem? Thanks, Jeff From duan@cs.umn.edu Thu Mar 4 01:07:50 1999 From: duan@cs.umn.edu (Zhenhai Duan) Date: Wed, 3 Mar 1999 19:07:50 -0600 (CST) Subject: Shared Agent? Message-ID: Is it possible to let different agents on different nodes to share one common agent simultanuously? The shared agent needs to reply recved message back to the corresponding agent who sent the message. Thanks. --Zhenhai -------------------------------------------------------------- Zhenhai Duan duan@cs.umn.edu Computer Science Department http://www.cs.umn.edu/~duan University of Minnesota, TC Phone: (612)626-7526(O) -------------------------------------------------------------- From pantong@public1.ptt.js.cn Thu Mar 4 04:35:55 1999 From: pantong@public1.ptt.js.cn (YangMing) Date: Thu, 4 Mar 1999 12:35:55 +0800 Subject: A problem in building TclCL Message-ID: <01be65f8$7e75d9a0$b44166ca@http.www.jlonline.com> This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BE663B.8C9919A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I wanted to build ns from source in Windows=A1=AF95. Having built = Tcl8.0, TK8.0 and Otcl successfully, I met the problem in building = TclCL. I found the length of three files of embedded-tcl.cc, = embedded-tk.cc and embeddded-tclobj.cc was 0 byte. I checked the file of = makefile.win and made sure other pathnames of Tcl/TK and Otcl correct. = Now I can=A1=AFt go on for this problem, so I expect you can help me to = overcome this problem. Thanks! ------=_NextPart_000_0004_01BE663B.8C9919A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I wanted to build ns from source in=20 Windows’95. Having built Tcl8.0, TK8.0 and Otcl successfully, I = met the=20 problem in building TclCL. I found the length of three files of = embedded-tcl.cc,=20 embedded-tk.cc and embeddded-tclobj.cc was 0 byte. I checked the file of = makefile.win and made sure other pathnames of Tcl/TK and Otcl correct. = Now I=20 can’t go on for this problem, so I expect you can help me to = overcome this=20 problem.
 
Thanks!
 
------=_NextPart_000_0004_01BE663B.8C9919A0-- From dpwu@fla.fujitsu.com Thu Mar 4 06:53:12 1999 From: dpwu@fla.fujitsu.com (Dapeng Wu) Date: Wed, 03 Mar 1999 22:53:12 -0800 Subject: a problem in building ns-2.1b4 Message-ID: <36DE2DD8.3471@fla.fujitsu.com> Dear all, I had a problem in building ns-2.1b4 on Sun Ultra 30, Solaris 2.6. First I downloaded all-in-once *.tar.gz file and unpacked them under my home directory. Then I successfully "make" under TclCL directory. I also successfully "configure" under ns directory. But "make" (ns) failed. The last part of the message is as follows: --------------------------------------------------------- webcache/tcpapp.o webcache/http-aux.o lanRouter.o tfcc.o filter.o gen/version.o gen/ns_tcl.o win32.o -R../tclcl -L../tclcl -ltclcl -R/usr/local/lib -L/usr/local/lib -lotcl -R/usr/local/lib -L/usr/local/lib -ltk -R/usr/local/lib -L/usr/local/lib -ltcl -lXext -lX11 -lsocket -lnsl -ldl -ldl -lm -ldl Undefined first referenced symbol in file Tcl_DeleteCommandFromToken /usr/local/lib/libotcl.so Tcl_CreateNamespace /usr/local/lib/libotcl.so Tcl_GetStringFromObj /usr/local/lib/libotcl.so Tcl_AddObjErrorInfo /usr/local/lib/libotcl.so Tcl_GetStringResult replicator.o TclFreeObj /usr/local/lib/libotcl.so Tcl_ProcObjCmd /usr/local/lib/libotcl.so Tcl_FindCommand /usr/local/lib/libotcl.so Tcl_NewStringObj /usr/local/lib/libotcl.so ld: fatal: Symbol referencing errors. No output written to ns make: *** [ns] Error 1 ----------------------------------------------------------- I could not find solution from the mailing list. Your help is highly appreciated. Dapeng From anurag@cs.ust.hk Thu Mar 4 07:40:56 1999 From: anurag@cs.ust.hk (Anurag) Date: Thu, 4 Mar 1999 15:40:56 +0800 (HKT) Subject: Problem In-Reply-To: <199903032249.XAA02362@zeus.informatik.uni-bonn.de> Message-ID: Hi I had loaded the same ns ver. i.e 2.1b4a few weeks back, under SUN OS 4.1.4 and all the examples worked fine. with Regards Anurag, On Wed, 3 Mar 1999, Marc Greis wrote: > John Heidemann wrote: > > On Wed, 03 Mar 1999 15:14:43 CST, Rui Li wrote: > > >Hi, > > > > > >I have just installed a current ns release 2.1b4a into my > > >computer(under Sun 4.0). It has passed the validation. But when I run some > > >examples downloaded from Marc Greis's tutorial web pages, nothing happens > > >but just enters the ns environment. There is even no error message or > > >other prompt. Do you have the same experience? Can you do me a favor to > > >tell me the solution? Thanks. > > Hm... I don't think I really understand what you (Rui Li) mean with > "enters the ns environment" here. > > > I believe there were some problems with his examples in the last > > release, but don't remember the specifics (you might try looking in > > the mailing list archives). > > I have to admit that I am somewhat behind with checking my examples > with the newer releases, especially since I am still using my "hacked" > 2.1b3 version. ;) But the only "problem" that I have heard of so far > was that ns had to use the backward compatibility mode, so I assumed > that there weren't any serious problems. > > > The upcoming release (and current snapshots) contains a test suite > > that includes Marc's sample problems so divergence between the samples > > and the implementation should be automatically caught. (And either > > fixed or documented.) > > That would be a great help! > > Another note: Usually, when there's a problem with the examples from > the tutorial, it's probably best to contact just me instead of the > whole mailing list, unless it seems to be a problem with ns itself. > > Marc > > -- > Marc Greis greis@cs.uni-bonn.de > From eroesch@iutsud.u-strasbg.fr Thu Mar 4 12:37:06 1999 From: eroesch@iutsud.u-strasbg.fr (eroesch@iutsud.u-strasbg.fr) Date: Thu, 04 Mar 1999 13:37:06 +0100 Subject: [ns] Adding new protocols ... In-Reply-To: <03E3E0690542D211A1490000F80836F43E45C7@zcard00f.ca.nortel. com> Message-ID: <3.0.1.32.19990304133706.00933a80@iutsud.u-strasbg.fr> --=====================_920547426==_ Content-Type: text/plain; charset="us-ascii" Hello all ! As said yesterday in my mail, I tried to implement new protocols, as described in the tutorial. The compilation does work, but nothing happens during the simulation .. Here are the sources latest modified .. i think it is a matter of inheritance .. Thanks in advance ----- Etienne --=====================_920547426==_ Content-Type: application/octet-stream; name="ping.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ping.zip" UEswMFBLAwQUAAIACAAnu2Mm9EeEUI8CAAAGBgAABwAAAFBJTkcuQ0OdVE1v4jAQPZNfYaVqZSM+ d29BIFU9bFe7apHgVlWRcSbgbUgiO7DSVvz3nbEDCdDuYaUcnDcz9vObN77Rucp2CbCw1Pl6sAmD 4fCmwaR6g+oSlWvIr0Bd2MqA3BIe6Lxic9zvnjKjSBXbrcwTTrA0a9VjaiNNt0s/exG8Bx2dcgrM voigg7/0j9upbUnw/mX82mOhhTzRVSim0xFmubTO3BHssvKtYlMms6xQuORiQsFNYmK6VZfhCsP8 BAgq6M+kUmAtL9LUwfGprD8zQBuOGoBOjyu9BYQXagPJLgMTRTq3lcwVcDFQePhbfTRlczyjx0Ye wP12Jmd8+fAzfv7hseGwRvtj+j8E9B0TL6Tzsjm9sPgQBPtCJ22NDag9b8nRY49Yhxy7zClMd9el k0KXRzEQuJZCl06I/1HPNbLRDwWs+5kUu1UGzNYCnitKl/fMoyg1ACScaEB3Hd+P8wafMfQJFyQR /KTLvuLY53Ebanfaen5B01FMqZuKzYLMgr8gGZoVu+plPBq90m62NGj3lCOG3r21jBrEbhN2+3Uw TsMey+UWXdMjI3RcU/Bko2I2m7H7JDFI+cxdT0UCi41Oq5imwVXxf/qwfy5yF4mNhLv7UmV3rFIZ 3g+X7VqKYmAAe5kRc/FZaw5kQayqtGIqk9Y6Kz6CTMA8uP+IldhyDPvyVojc6GNR0Lko4wILryp4 2IaGVIMCWv0HivTUcSHY+wR5eT4OwtDkA5oXBFGDj3k1jI4pPHTT5hn480jN59UvUOhThQ9gBfTM 4QtXoKr+nXNLNCT55DjeOfxuppeLWtMWdyTemu5WKtLxq/kynn9/+uame6XRnfVzvUBdYtTnjgRy bvfR0wBQrD0Nh+AvUEsDBBQAAgAIACe7YyaPFmj91gAAAFYBAAAGAAAAUElORy5IXY+9bsQgEIRr 71Oszo2DTrnerlLl0kR+A0RgsVexAQF2E+XdA7aUv27nY3Z2aNk6QxalHF9en+Ud2qLY0Q+Alp1e NkN4URO5/DhffqGg9Dv9Yxz+amVMpJQqhJsACOwmAHEDSDluOuNsojzgBzR6VhEj5QEa47e3hTCR MzLzSgN8DgB6USnhWOxPtQ72GIqNNR6yRpy6h+bb1D2UOC5m7ddVOdPVWcVJX7HeE6KKvZp2z6ac 13s3Hj8TV7yXhYWiqM8h+kw6k+nPPG/t0Vye3aAtXdnCF1BLAwQKAAAAAAAnu2MmAAAAAAAAAAAA AAAACAAAAFBJTkcuTkFNUEsDBBQAAgAIACe7YyY6hRxRbAEAAOwCAAAIAAAAUElORy5UQ0yNksFq wzAMhs/xU4g0sFPSpGMPMLbroNDeShmuo6Rmjh1iu+0offfJ8bakh8Fykv5In34ZLfL4gRiQO2k0 1A9egzb+hArQ9lwg1Ahu4CcuFbPoQFvYaTzDRnZecWeGPWOLH44ybahXHGz8HZi98QNo3o3tDexM jyRK3RYkwnnPMmJSSFME5lwpyJoZc/KGsCJv6GsbnZSwG1tNjfuoVHNlZkvSRNRuIGtoJ0qorX2v 8JIrqT8gI2RGkKe3A6w6C6+D6bdh8QnFnePiiB3RoiHeUmjHfUYPY76mrIzv9BzyZRDiohGQj2Vx 4NRxD6j+BahmgIqNBCf6eev2ZU2dQQw/heLWvkP1hxkqixAbHuSesiHpLw+hnLHZLjRM19Kx73p4 LEpID5+Ysn4wAiiC6w2uLGmVOXAV7qphSShulLfHfLwGlghlLIaDSHpPz5wqrsXv64f7KYoiZQle UECxJKGgMOTSQclucfzgNfsCUEsDBBQAAgAIADS7YyYrRx9uSwgAAJURAAAHAAAAQUdFTlQuSLVX bXPiyBH+DL+i6/bqDrNg1r63PbuSigyyrSoMRBL2ulIpTkiDmVqh0WkGvGRr89vz9EgYgXeTT/EH I/V0P/3ePeq1qdvuNu5UIi76b99eUtydR1rGXbVYaGEu3l+SiebdZ5mYJb/ILBGZ6YKmuysWMixP 7V6z125Sm/oq3xbyaWmoFZ/Q2e+//9TFv9/IF0+Q06QWZJaCppnciEJLs2VKP0rlQhWZjE4Zw0lT shiaCqFFsREJ0/nIF4nUppDztZEqoyhLaK0FrCKt1kUsLGUus6jYEhBXukPP0ixJFfZXrQ2jwHC5 kHHEGB2KCkG5KFbSGJFQXqiNTPBglpGxti5UmqpnmT1RrLJEspBmFJZbIUT8fHZ6ZJr1tLIpRpxo tdYG7pgItjJqNFcbPqrCxSD4y5SRseiAQ2pKgccwe7XWvUOboDROI7kShY3d+WtDoLAWkZ0h8DNZ w7j/jy1UelkhJSper5D+aJe0HvKhcF7QKjKikFGq94G3CWPguhvWuZ9ObW1ECWrHSM0q9/KsAIxM XIjIrFE6nHYuD1t0cEKrhXlG2iqzbCSgJE+j7ZEnUfwxU8+pSJ4E43KOGyFDlGEz8C9O14nYY1Ii NiJVORyYl2h9tcrXsI6CrTZixTXTcLMnmQlYDB03hVrnhCIbRs+FyJCLK1F8FKnYgjJXRWRUsbV+ /3xKIyFtvBg4i1biK42UcVBL6l4eAdrSXHAYkspto0hkiSo4MAU7tFJG7BzT8KMAZEILHByGrd5C +NO5iLmNICq5vwpuoKxsJa2rnDFveOsFFIyvwwfHdwnPE3987w3cAV094tAl371xR2FAzmhA/fEo 9L2raTj2A/rjDyeAwI8/8pEdDaNHcj9MfDcIaOyTdzcZesABsO+MQs8NOuSN+sPpwBvddAgoNBqH NPTuvBBs4bjD+hjotSSNr+nO9fu3eHWuvKEXPlqDrr1wxOquoc+hieOHXn86dHyaTP3JOLBo7NfA C/pDx7tzB6cEI6CY3Hu4RcGtMxwe+AmkAzevXJjoXA0tltUDNwee7/ZD9mf/1EfUYN2wQ8HE7Xv8 4H5w4YrjP3Yq2MD9+xRMOGS0gXPn3MC51v8IC1LSn/ruHRuMQATTqyD0wmno0s14PAgYCvCB6997 fTe4pOE4sBGbBm4HSkLHqgcKwoVjPF9NA88GzhuFru9PJ6E3Hp0w0O34AZGBsQ6kBzbI45H1GUEa +4+My/GwOejQw60Lus8xtVFzOBYBotcPGa3GCa2IZ1hzlkbuzdBD1Psun44Z6MEL3BOkzAuYwSs1 PziP1sepdZ+TBdvKx1rxdmxKybsmZ3DvsfEVMwoh8KqiGV8zUjDt31bR3/XB31pvTuj7WxGhxS6o t9ZFTxdxbxXpZQ8DWaGL0bG9jcxML9Pd817EO/N02dlgv5yf8TZ933v3vnd+Tu/OL35+d/HLL7SM 1Fxtyf2U0/fUGl4NOcK9ZvONXGBTLyjTM4syWzbf4B3Dp04CWznH6DsM9kzEMOB0+V2NnGMSCnNI Mzzhu0vM8VRY9hfoEOXvz7zB0KV3R8SJO7IJOWvipkAcjhGPnXLLMqC2CxVTl+QqT+3YFbzdeVQe avwcx53ll8rPnRKUhXvv+LM758O9M5y6Q3d0E97S2fn7ZhNLSWty8jytlv5lE1b0SMNdDME0oU2U rsuZWkSx4PdCM8ezKj6SylK7Oym0h/dREcZpE7uJF8E4BYGFPzcbL+fUBsDsstmIl3gB+Owf3zDw n2A6Rmpn4pOB9JfLF9M5X3RB+XoOF7BZqlxBaUW7aDYsUwvFQ/lHE25zcQLsjSzMOkrp3+WpJSmZ 4AIQb1oTm9x2h27LyLZfjjU2xO6Y8j0DLU/oM26ExZMws+5fLQqOlyeX9GWvzEJwzrAsrEEmU4A+ YmAdK/1kGbL51ghc1lCF2Mk2au1FGj1p+gu9q/uxt24vxibtwCrKa3OYwahvKGuTVdZBb0RJUsxw LdDmldqqRVr/nSlVWrRekfn+JLLX9MiYKF6iNFu18sTdMs/rrLD6B9LyXwCGr7hFrovMvs+sozJL y8Yu7fqB+LfOaullTMpYmBlqxKBGdvXCzza1+J0h6BWJZZp8NzBwXCQXrAshU6tVVKUApRAfhNI+ 8u34aQMXMIeobNGkFfaH/eEMSxKzchSEaIaTo2gkAlexGW6ryUxm0syiNG0dxaHOw3e3yMTLVr1s 0HkjXJAOaylVcZQymU1CJcAqTKHXBtmZcmgT1/gVF4x1tyqvIx6J5rCG7loGhqsYMUQSrBmXDQwT S6S3HH7CzS8TzxzmrwhBUV1OW3dwD6bnXhKZCI+LhSiqZHKgWKhCORAsFS2kSBP7HRBZhc3GSwWX hdFoWPPwLLR+uS3bJVHjRbXvWHHxNfikKK/zlRgPSKCjk9RzWSZlgZYSC/mJP66sjfagZLHlVrHw M19OcR2P7Sddxb20C7PkX8jkBRH6vMnmV6sQGSjdLNn4RvqKj4l1JtvydS7xCXdXubLfqS0tYEN+ ujwpmVHDxqR7/xfROoX5JrWSmHNPihcVAqDt8rW7Vxn8VLEQf2bWJJRdvC4KsaNxxZVNxZN+x2Gn /jdjwTJlFTd5eyAPsW2NtUzijDeHBcQX/EzmM5672FezPtZnJlJuCP592U5tu/K4N6zyXvl5wd8L tmLs5rEsutnYryhVPQ0lVwVBR21+URvzq0LLTcGORLVTjhjaMZ3Dp+Nus5pa9UX6spPQ+MIIu8fs +X6ZoQRr5HrfZ2XLl2wrfB1iaR4h7HxqU6rUx3W+e/+6ETLT+Pb8Ks/hxLE3Cohx2W3wkXpRASzS tV46kDjG521fJfU/UEsDBBQAAgAIADm7YyZoAnSK8AoAANAZAAAIAAAAUEFDS0VULki1WFt328YR fgZ/xVTOsUmFEnWxE1tqfEqRkIWUIlgAlOOT+qggsBQRgwADLCirjv97v9kFSEBU3L5UL1jOzszO 5ZudWfX26WD/wLhOQ3E2+P77cwoOZn4eBQfpfJ4Lefb6nKQ/O7iPQrngH1ESikQegJYfLFlIsjzt 91q9/Rbt0yBdPWTR3UJSO+jQ8Zs3P5Ij7iCSUzonuRA0TaK1yPJIPjBl4MfRPM2SyD9k8X4ckxLP KRO5yNYiZDpvOSKMcplFs0JGaUJ+ElKRCxhEeVpkgVCUWZT42QNB4zLv0n0kF5Rm6psWkrXA5mge BT7r6JKfCVqJbBlJKUJaZek6CrGQC18qW+dpHKf3UXJHQZqEEQvlrIXllogOr48PH5mmPC1tChAi Wha5hDvSh62s1Z+la94qI8VK8JekMgpEFxxRTjH0sZrtscq9pk04NIj9aCkyFbuTXUNwYC0ilSHw Myxg3P/HFtJelprCNCiWSL9fJa2HfKTYz2jpS5FFfpxvA68SxorrbijnTg8VNvwQ2JFRzkdu5fkA MDJxLnxZADqcdoaHAh2cyNO5vEfaSrNUJHDIKvYfHnniB5+S9D4W4Z1gvZxjw2MVOmwS/gVxEYqt TgrFWsTpCg7MtLZBulwVsI7ch1yKJWPGMJO7KBGwGGe8y9JiRQDZyL/PRIJcXIjsk4jFAyizNPNl mj0ov18e0lhEKl6sOPGX4olCSjiomrqVR4AeaCY4DGHptkxJJGGacWAydmiZSlE5lsOPDCpDmmOj GbZ6CeEvX4mAywiiEddXxgWU6FLK8zJnzOtdWS659qX3vu+YhPXEsW+soTmkiw/YNMkx35ljz6X+ eEgDe+w51sXUsx2X/vWvvguBFy94S10N4w9k/jJxTNcl2yHrejKyoAeKnf7Ys0y3S9Z4MJoOrfG7 LkELjW2PRta15YHNs7t8HivalST7kq5NZ3CFn/0La2R5H5RBl5Y35uMucV6fJn3HswbTUd+hydSZ 2K7Sxn4NLXcw6lvX5vCQYAQOJvMGbpF71R+NGn5CU8PNCxMm9i9GSpc6B24OLccceOzPdjVA1GDd qEvuxBxYvDB/MeFK3/nQLdW65j+mYMImaxv2r/vv4Fz7v4QFKRlMHfOaDUYg3OmF61ne1DPpnW0P XVYF9a7p3FgD0z2nke2qiE1ds4tDvL46HloQLmxjfTF1LRU4a+yZjjOdeJY97rCiK/s9IgNj+5Ae qiDbY+UzgmQ7H1gvx0PloEvvr0zQHY6pilqfY+EiegOPtdU4cSri6dWcpbH5bmQh6gOTd21W9N5y zQ5SZrnMYOmT3/c/KB+nyn1OFmzTyxp4uyqlZF1Sf3hjsfElM4DgWiVo7EvW5E4HV2X0qzr4W/tZ h767Ej5K7Ix6RZ718izoLf180cOFnKKKUbG9dZTIXpIfnPRWuIaEPFx012gwp6+5k77uHR/1jl/S 0fHZyfHZ6St6KLLogczPK/qO2qOLEUe412o9i+Zo0nNK8lut5XbRegYCbp8GDYz6JqM9XO3z6O5w sVej5cFChEWM5gLyRsHEu50gdoZxVCd5g4lhnJ7WSdMhSMd1yuDCMYyTOqWPRNlGQ4wvB9t42eAa /N0wXtUprodSNH5okmyc92PDTmc6No3XddI7p3/pGW92SDiCrzU6bnj1sw2EVH/HDV/6LurBq7Ya Tl0D+Mi8cdzwy1EhOn7ZpDHp1SOSY3v27fDGOG74N5DZdeDn8tZMAn9Fxz8+uTkUarPhs+tc45Q3 mM8oj5arWOBzl/hxrHqoyHP/Dr0MwKmbwReJ6xknR81EDMwJiM2s2uNLC0ecNILgmX1naL8fGyeb KBggj6wbExh4aRi9Hmkg6mYTo+9QIuR9mn1qGvIz7j/j5FWrqX00NkH9QenBsAJRgfnhjKSIoUV1 fgS8LnPJwT5pAgRl7dnGSSNcaDHga0DEGt/0R8ZpIxZXHus7bYRi7H2YmMbpSavX2ykXFEeDtQ+Y 0N4EOdjr0l4RrvgTzDL++EUYpbzgoUgtECl8/tky9nLpZ5JJuUyVzCorEsGLu8yfy82iryT2fkuj RCnIMUxjd69MONMyGaz0d1Uqz+QkS2U6vGFyE3ENioIZU4Ctyi7/NhO/4wAs/CAQK6nXfLPolRR+ Fqb3yhxOt3KCpX4TgSy16PTxzlxq7zB7SBUC8VkRFlKurGTtx9UP/rIj2/Dal5eu6bXlwwoT7DwS cdgx2m3crB163lZk2u8cdQ7e6r1WC4NrntNEw/GMVsUsxmhjrjH90ZcWRpw1Js2zllEkXDmYj4KF n+1jspb57TkjcKHudUXY4Qp96WuutY9pdabq79+CZsV8DhnM5fSCeV7UJGGrkotFokWxuOOnzPxJ JTARY1yAJwyMzHnUDkpv9lFdQmgdm3ITQo30Le0nRCreRHyW4GVmNuv3QhSiNutvBKsz2MxFmCkr Ky3tDiKoItM+6nQ3XqgfSj9W9IW+7sQJQMFIzpJtZkDaiyyhtlLVOWeBykx+rIBHCZzvOIyLLQ3a nT/bYBhgL0pihso6jUK9wYZWm6Wg2mSv26WKmuAj4xnxec7yyNG8tA3YMYxoTm2Q6K901MFPg6dz qcwzKhefKx9/BddHpn/99iHK0M0JVZw0ymgrW4PQ09wqaxD4et5qtfDY4pcNknkbLBM2HPLGimul BESJHlU97VyUD8eOZmQslnxoMUXsq9e0luA9zVVEYclUJBHARVGoN0SWpVm5pdY0j/27lhGmQKgw VJXxnsTzErlZrs40Pg9Cwc+3pfBzPPn4sab1RXM/qOzJRCCiNbc67IiMd6gd+zMRl7ZnYo5Lqkik rhKFcob76hPaCJ6VMaldfjodtRrQ1/8h0WJ6rcxS7yZ9I2yysZV6XrLWQV4pqqWvFCgTsgFYheVV R4GrQlDF1qHVwduStVSqEdUy0P3xOjtQVx4itpzx3VMkgX7Po/vXgPOcVOYbdaix0HkEsecqvQ1G hYVdPiS/wcZg2OVS2a/zldCo8WlQPN+CoaF2c1nUtSo8NNg0QnY5N2BocG8h0tlUTL1n6LF+oCib 9uEFsaZ8aVzPOxJtXZvlJcgUfuN3q8uVw8k5XEeZLPxYkZcCb/FQ3TZ+dhd0qaZCLfkfVHdrJabu ME76bYm7+nFqY3uc5nh8Pc6iZCMMrn19w32pUEs/8aoeSSW1K1Dya3bFve0eqlSfcX+bPUj0nCfq SOvRBfeNits0tSpgGx/a9TAqKkYKXMalb7naR9bsGQ8kyEUmcI/9L1FWgCidrypUf8/OynbU+rLt XyuETLfllmoPK/rLT7o7KCp2UcW6F7cMEWOU5VpnqUTcl4q5f4BLdY5yo9Etfi0j+/G87EEQxyH0 xx+0FfvpcU/q9ZRW1Uyg9ahBYXWayC1qcy+w/y1+XChPETHyq6tf/TfPTyhRWVVdpxp7+J36zYhx 2JOdsG2bO/uU0Ft4QDoU2y6e8P637HvSItzv2BCfMeBwtyhdqNmpINMwspoZSkNrQUrO9c+nc5N8 LB0oWco8bNLABj91aH0WQQto6TbNlcC3P59VNoKzs6pUWsamhQQLMGxbRaNTKHk+WZkVLA7e1m9C ZaAGYQnMGoK3oN1AbYsXLWWgTwspfv1IFbg0sB5hzXgKaoy1r7Spgh3T6DHlgI4VQr/+KcDq8+Of Aww9MgBfWS1tjK+qarrVndWp5XDratOBzZzVavi6i4iKUZXr9mQloIfo2+0s3XmyAp+JJIzmrf8A UEsDBBQAAgAIAEW7YyYzXLl2mQ8AADInAAAIAAAATUFLRUZJTEWdWn132sbS/9v6FHtjzrFpLQhO cp+WXucEA455grEP4MR96pYs0gK61lt3Bdht73d/frMrCQmw03N7GrSanfedmZ1d+ZB9FKGQPBEu 48skCnjiOdz3n9hMRgG74g9i5vmi5oVs+sScKJx586UUNeuQsXYUP0lvvkjYsVNljR9/fHtCv+/0 7z+BcTBeCDYUcxEmikUzluD1NvRWQioveSJIm/veLJKhx2uMtXyfaX6KSaGEXAkXckjSULieSqQ3 XSZeFDIeumypBINSKlpKR2jI1Au5hN6RDNQJW3vJgkVSP6NlQlyCyPVmsI54nDAuBYuFDLyEbI9l tPJcDJIFT5rsuFHNWDuRK1hRvCJeUiQc4skiPo1WhJY5I4zgQqNSsvAUi7nkc8njBenrwTi4wwP9 0wk7Pq0SsxJ3YDn+0vXCeWaR1sBAxTckEreXhbJUazdylgGA2hvkqAhQybD+Qnrc10bmTtHO1FQF TU+0icdvqgzxwriLZU08RXrnTBhJACqAxG8meILgUSSO1k+HBJRV0SxZ03qAfezzJy1qFvl+tCZ2 3HkIo7Uv3Lkgfk1i9fXrWJspI3fpJJl3iqzESvhRDOWnTy8G3gmx6/O1FCF8eC7kg/DFEyDTCGkR wf9kJrkQ0W+Mj6SqHR2xgfC0z4h7yAOyx/i/JCyMNhg6C7ZZwV1PbCrII4iYCCvlAiqIFUhhYRAl IrNUwTAJ3q7Jz7L70lhnKhYORTqIvEgSo7WkMA9NwCuFJdEZPL7sjdjo+mL8pTXsMoxvhtefe51u B/5tjQCAla1Bh33pjS+vb8cY/8y6dzfD7mjEroesd3XT73U7xAkMhq3BuNcdnbDeoN2/7fQGH09y wn7vqjdujXvXgxMI7WaUBTJ2fUF8rrrD9iUgrfNevzf+WUu/6I0HJPECIlvspjUc99q3/daQ3dwO b65HXVMkPhwfVlnlUnA4qMnqSyXrSjr1gKtFXYo4wmJgMesrL0zqobJP64XadrJijVrjzSkVrh/q jdf1xlt2+rr55m2z8SOLIyqH3ceYVdhx/7xftbS8zxzOXaq8JvKpj1XiyUKxY4lADaYUGlhO10uK dfSE0jUHIP/Bjo2jmPkUsWzhoRpLZ/FkxRIYjwdnxhY/QlkG5g0kpMGGdJHC0SEKOV6oEkpEijVT OKzz3qDTHY1LLOqY+7tsAo6I4XNhXbX2MMKsZZ33W4NPgB8C+QEliE19Hj4gArkjUNI712xwPUZx wO4SPiFakc4QosPW90KhbS8l+9qDcGSDFC7MDxHoyxAryr54SIs1fKuEQFgNsFi+dvkUab6uWu02 tJg7jtW+ucHI+f57q9/TqlWOAapaV586XZqp1WnF6sGDK2Jr3O6PLgFMHF8tfqi9JsApcarV6oA5 Pv2eErPWEFAumXTAUFuNOEDs9nvnmJA89L2p1RuMxq1+P/MTXF3P/Gk7Vn+ACT+0xsaViVCJNbwi 6oDZM+umOyRKpKhvWbDn+oaw7Dmzv4CBNaL8IdWsfuei3/o40qYZaBUwpBmhRwX1Ot2L3qBL0M7g ejL+hCfsa/cn7X5rNCJlPyOLaLbTPb/9iMHtqDsZXV5hdNn63J10zj9OLrMXWKqpG5PX5/+TAQ2/ Is71WKO03mQwApS5fPph8jpn8GlbQnFSU5KGo3GnPbnstjrd4eiskc2PxkOUmcnlBqIpNq85xwLG p22ET6X5610WuUklOfskpd7ZgLUHN68fu+Ph7aj1sVuw4Xz4CW+WZcomKuEZu7cO7B7SRz91KGXb P8BpZJphlGSj5GEaPe7gFWGWZYKVuPY3bPz02c/Z+ebRz7kitgnvARnCMtIC3PFpwvDV2t41GsN/ prN34jGhR6NBCBiFikS4vsb3A2Ydgqzyp3gUzsTUvP9o0nskwSbQdT6gwB+boKYiTDXZ9xwvQXk2 xQLFOIg93/Q0culTQ+DRtj5ahtcj9vZImTLlRkKFRwlKEF5QNGgzbPkqOqEXPauLNMo4NVpUCmsR Cg0aBipV8oEK1RFXR2gzF56zYA4KJWoWBxvs06hKAfNm7ClaghfJidam6aKKz7DrawLak4WphmJT g2tWbXR7cdG7646arOY4B4ewOQfBbMBqUdM6+KCrBqt8sA5MhUOJIT9pl5Gjsniq6qLwgVW+AynR 7yFv71Cnbn6GDwrUx+5g0ulRVUR/X6fQSl+xdnVrQKuGVnkwutODR4y6eqRrvi7gTZR2LBj1dFsd H20NZjMykZs3NHr1sALscxs1+ZD9I8P4lynq2TYLLu+h4/X5/07abZNQKNFuFGAdZTinXx6uuMQA /RA8whIvENJeAMkXBAaFchbCXZrXaPpvrI+BY297EDT2YmKEjkvgCQVCvYTELPENaiJpHwSAnrbG B9TxOXqwmac5b15sbJNbkAW6lzJk5clkyf1tRnbgcJWUUQPqRkhDQWnCjWpbVNwxMB6TbonwQ21Z 4oBkaufvxpQZVtoYM8NiZLbhqCGSCAPxGEf0dKZykuKkpNOZVkOt8FBc/8CHZjIQXC0p01xiobAO qabcJfJA2WZAC7TWTYAttKUczk7n7i2W/hdH6O8UD2JfpGgKnX74YPDjFH8xTQdQma/mBlOvrORB OhUufd8u6kNecnmcoPu2kayCOnyAVzyRzkqaCFDpkHDp2EsGCKUwxmjpko+V0P23LRMdPemvQw9v pVKH6Vf82sroTkMcUKJ0GIp1+maQ7ZWYc5XhTTPiGUzIQhmlaxpx6WZ84f9GhpavBb1x9RSkEzQs ajBTxYnZRlnb06Y6i0glmQBjJjnS8z2VBhHwxFymDv19KZbCDnA8NO8zZH+gSfxIqcIECDUuhq6M YhtHb7JLeXqZacGFXNk6XXWcuanRAi0qTsa2SdiMRQ42iJij5cTapVSz30mX37UwvazT383MAqik GcWNlAhYkXoXA/5EamutwijK8hzlJNRIJs/wazsq4Onwh9enk0YjfQmWfuItMkr3KczCViY3Mkqi zmdypUjIXCFnJvVIRiKv0tTXJWACgFZDBpkX9EIshB/reNXKZsoDy1Yqw8RLEsVpWKHnjBxdkoQ2 eTO6py0jrfdVWvnPgqwrw4YGWMJ1A810opZxHMk0JNZi6nAsXX2R6FzI30340xIXoXQeQZnxt4g9 VHPfznKuyMNUtpIUmy8fDT0OK0Oq37poz2hnpT1av1M58GiroP1qveAJW3PFcN4XWSfgUZewpgsV gdXjiaibDYedpTvP9dVNa8yoe6FX9H66hUERe3MKtod3d3e6YeFJXcMedQ3R78lDGwEZkemG16B1 ZbYxHNrqPKSiZLIrBeGfTblRhtCVSRkSYuHLkHw3K8CyVCmAsmqfgmJuUj59xRknKcwCOVR0EVfg IZKVJ9YlQBqFxsLuFc70426+X2c+1TGf2lWAlQEJ38IQdDOzQ2THzjaiTqcdfrTyE4R7HNHhszzH 5TYLJ9jWjyc7ZpWt8rRIg4JOSgdJ2lFV9c2RXtwNLFQTtNlEMRqC1YEJqXazFp3VnGoaYe30PQcg anKIzsSSRmXijf+LJBDaiuMeKjEgLHnYvGjdN5psdKjm8T7IgToT0Ly2+93W4KLX16ecUFFjiH81 lDuDWVB8V699NlRZQcO03GQ++47Rrqd/apXjARrYfHhXGNNZQk83Mx1KLLObGlPIcK6mQtfJ+2R9 8K6iLYbogxJhbhDKH0RkfJrFyyD04QK7JntVvGinuiLW+mIRx4R85lWO/DMOFqEwt4USzcgyLNzM A23GfWqzjXH7rdr17bZj/1t7Cf5t7iz1C06ClJNG2buCsg/bulJI/C2dHvYsQSGmzGqYoNvrm71C zNHnW2t8czvsXfxMlzhL6c2ecKaiPcfG4e6sngQxpNqYEc+KNfSG33+lwGCkb0DwYsoNcOksTRee Zmep0cm+PIGjM0fzsWcm73J2p/DYC0XLsgvWm84umK46n5lKN6XdCbMz7cLNx5p9snmwB2p2s124 aSB24enhcS976mb2sUr7pd2ZtGEtzuAYUC8eDEpTc6KjjjDwHLVnSp9A7Zi6xD2z3J9H9i5KdmAi zLyl1NrNNq4pIunukhDMSfM5BN2M3jwjyKB0ropqGphL39N84eZzu2SpB17AiL1gH29qhfcB7ew4 t3+W+uKdCX1NsAvWVl+lB5Zd9dCTG7fV21m7/neQ2kjZbyEOb57BgjPoH6LNS16YTo+nUr2EM3Ne mpUv8cfRaiVfmFdCd1jPI6y8WTno/YD+7QHZYQkxzafsuS+r9dVNAZ73b6h9Zlii4qEucjzcB/X3 AOnYV4BuHUK2a015Wn8Al8/P66Geps1zq090HNpjNruB3jn1x44qfRyi+1ub7j5CV3PYU9j/Yprg FFu1SCZgS1ey7+m+0NrtVCHtc3c46l0PSM6Q9tkPWxLpu3E4PzX+SOkmBsj+lVGnAqz0o0mTrvoc 3XmlX1awDwbs3bt3tB2CK30doQc6SbqxHI1Jqcpx+t2rmjPCQoTPMHv79u0Os1qjxC79+lWlL14N y3J8AW65ocebnhYC6QP5Cwh5N5c2bDW9itmLH82zIR2olkrfmOO/ebh0agsWqbSELywr4XPVPEhN cuiN2evEZXTJi58FfcEaY1n1ez4G4RjtRE4oNOE3abL4KNEe627EcbPo+Slt/dJFBz3+3xNspSCb SxGzo98ODw9ZGa2JU/bcC4+Aw9cP7OjPGKGSsErl3X+O2HvCmJAflZFq7LApN+dnYRQKZkt2VP/t F3af/PodnObo0ff3x7/8ZgbV+n2jfsS+OjjYb7h9LbPjcYzytIcv+LTs//s1Z5Zxp3gjafd/6d/q jlQDgOxm8/7Nc/IpjgRJpiTGeU9nr/5+WX3mhj9Fs5REKEi63nfW7tnXeO1+ZT/Rx4Wzr1OOUktf fCsVx4DT4CLgGRZFq5Il4l8skQwmMm7/UcAFc0KFmBL61xomavM/Noh05Xf26tUGQJf2Ht2VaDqd DVq1KEWtVOgJ5UideqXivdKzocg56LNPOn51nH6+qEDwTwxBWKsB30cSoxRUYHDKqVpQgf1tIvaM 0IwE9MyZLQwn9osfmb9v0kv4a1nkNonNjKVVCv4/vJi+u7xPGe2XCqWRSEYzaL1AS66rlqYhWbmw FzEtS+dtE9ksVJJnca2+4r7nYquje662FBix/DvKytEL94Wup7I/qdHfa6ZP+rMCd1C/6Q9yXhW+ xdRqtVfswH7PDl6VYFaBbfOgdArG0ac77JudAtuivXIItxb72BuKR+P3RdWsw5zOjgU7UvXfDtnx fSYTGZ4N69HRy4yyP1TodPvdcdf8XQyOYF2kPtN/KUB/naMYOinr/wFQSwECFAAUAAIACAAnu2Mm 9EeEUI8CAAAGBgAABwAAAAAAAAABACAAtoEEAAAAUElORy5DQ1BLAQIUABQAAgAIACe7YyaPFmj9 1gAAAFYBAAAGAAAAAAAAAAEAIAC2gbgCAABQSU5HLkhQSwECFAAKAAAAAAAnu2MmAAAAAAAAAAAA AAAACAAAAAAAAAAAACAAtoGyAwAAUElORy5OQU1QSwECFAAUAAIACAAnu2MmOoUcUWwBAADsAgAA CAAAAAAAAAABACAAtoHYAwAAUElORy5UQ0xQSwECFAAUAAIACAA0u2MmK0cfbksIAACVEQAABwAA AAAAAAABACAAtoFqBQAAQUdFTlQuSFBLAQIUABQAAgAIADm7YyZoAnSK8AoAANAZAAAIAAAAAAAA AAEAIAC2gdoNAABQQUNLRVQuSFBLAQIUABQAAgAIAEW7YyYzXLl2mQ8AADInAAAIAAAAAAAAAAEA IAC2gfAYAABNQUtFRklMRVBLBQYAAAAABwAHAHYBAACvKAAAAAA= --=====================_920547426==_ Content-Type: text/plain; charset="us-ascii" --=====================_920547426==_-- From g.stimson@dcs.shef.ac.uk Thu Mar 4 13:59:36 1999 From: g.stimson@dcs.shef.ac.uk (Gary Stimson) Date: Thu, 04 Mar 1999 13:59:36 +0000 Subject: System documentation for ns? Message-ID: <3.0.1.32.19990304135936.0098a6f0@ridingwood.shef.ac.uk> Hi I am interested in writing my own scheduler for ns. At the moment I have the "ns Notes and Documentation" document. This is good at explaining how to construct a simulation but does not really describe the design of the simulator. Is any documentation available that describes the construction of the simulator, its classes, attributes, methods, etc? Also, is there a repository for ns modelling components? Apologies if these are FAQs - I am new to ns but have been lurking on the mailing list for a while and have not seen similar questions come up. Regards, Gary -- Gary Stimson Department of Computer Science gary@dcs.shef.ac.uk University of Sheffield Tel: 0114 222 1858 211 Portobello Street Fax: 0114 222 1810 Sheffield S1 4DP, UK From johnh@ISI.EDU Thu Mar 4 16:16:04 1999 From: johnh@ISI.EDU (John Heidemann) Date: Thu, 04 Mar 1999 08:16:04 -0800 Subject: System documentation for ns? In-Reply-To: <3.0.1.32.19990304135936.0098a6f0@ridingwood.shef.ac.uk> Message-ID: <199903041616.IAA02024@dash.isi.edu> On Thu, 04 Mar 1999 13:59:36 GMT, Gary Stimson wrote: >Hi > >I am interested in writing my own scheduler for ns. At the moment I have >the "ns Notes and Documentation" document. This is good at explaining how >to construct a simulation but does not really describe the design of the >simulator. Is any documentation available that describes the construction >of the simulator, its classes, attributes, methods, etc? All the internal documentation is in "ns Notes and Documentation". If you're planning on adding a scheduler you'll need to study the source code. >Also, is there a repository for ns modelling components? In addition to what's in the distribution, there's a contributed code web page. -John Heidemann From johnh@ISI.EDU Thu Mar 4 16:20:05 1999 From: johnh@ISI.EDU (John Heidemann) Date: Thu, 04 Mar 1999 08:20:05 -0800 Subject: a problem in building ns-2.1b4 In-Reply-To: <36DE2DD8.3471@fla.fujitsu.com> Message-ID: <199903041620.IAA02056@dash.isi.edu> On Wed, 03 Mar 1999 22:53:12 PST, Dapeng Wu wrote: >Dear all, > >I had a problem in building ns-2.1b4 on Sun Ultra 30, Solaris 2.6. > >First I downloaded all-in-once *.tar.gz file and unpacked them under my >home directory. Then I successfully "make" under TclCL directory. I >also successfully "configure" under ns directory. But "make" (ns) >failed. > >The last part of the message is as follows: > >--------------------------------------------------------- > webcache/tcpapp.o webcache/http-aux.o lanRouter.o tfcc.o filter.o >gen/version.o gen/ns_tcl.o win32.o -R../tclcl -L../tclcl -ltclcl >-R/usr/local/lib -L/usr/local/lib -lotcl -R/usr/local/lib >-L/usr/local/lib -ltk -R/usr/local/lib -L/usr/local/lib -ltcl -lXext >-lX11 -lsocket -lnsl -ldl -ldl -lm -ldl >Undefined first referenced > symbol in file >Tcl_DeleteCommandFromToken /usr/local/lib/libotcl.so >Tcl_CreateNamespace /usr/local/lib/libotcl.so >Tcl_GetStringFromObj /usr/local/lib/libotcl.so >Tcl_AddObjErrorInfo /usr/local/lib/libotcl.so >Tcl_GetStringResult replicator.o >TclFreeObj /usr/local/lib/libotcl.so >Tcl_ProcObjCmd /usr/local/lib/libotcl.so >Tcl_FindCommand /usr/local/lib/libotcl.so >Tcl_NewStringObj /usr/local/lib/libotcl.so >ld: fatal: Symbol referencing errors. No output written to ns >make: *** [ns] Error 1 >----------------------------------------------------------- There is a problem with your tcl library (the Tcl_* is the hint). Rebuild it and watch for errors (out of disk space?). -John Heidemann From johnh@ISI.EDU Thu Mar 4 16:28:55 1999 From: johnh@ISI.EDU (John Heidemann) Date: Thu, 04 Mar 1999 08:28:55 -0800 Subject: A problem in building TclCL In-Reply-To: <01be65f8$7e75d9a0$b44166ca@http.www.jlonline.com> Message-ID: <199903041628.IAA02158@dash.isi.edu> On Thu, 04 Mar 1999 12:35:55 +0800, "YangMing" wrote: >I wanted to build ns from source in Windows¡¯95. Having built Tcl8.0, TK8.0 and Otcl successfully, I met the problem in building TclCL. I found the length of three files of embedded-tcl.cc, embedded-tk.cc and embeddded-tclobj.cc was 0 byte. I checked the file of makefile.win and made sure other pathnames of Tcl/TK and Otcl correct. Now I can¡¯t go on for this problem, so I expect you can help me to overcome this problem. > >Thanks! Those files are automatically generated. See the Makefile for details of how. (This should be reflected in the Windows Makefile, too.) -John Heidemann From Steven.Russert@PSS.Boeing.com Thu Mar 4 17:09:46 1999 From: Steven.Russert@PSS.Boeing.com (Russert, Steven W) Date: Thu, 4 Mar 1999 09:09:46 -0800 Subject: nam - no display Message-ID: <618FD3AF120DD111A27900805F19D9C4039DCF92@xch-blv-03.ca.boeing.com> Thanks to Christian Joensson for the suggestion to use STRACE nam to find out what is holding up the works. The problem on the surface is, indeed, "too many open files". It looks like something might be in a loop, though. Here is the kind of entry I see in the trace output by STRACE. ... socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5 fcntl(5,F_SETFD, FD_CLOEXEC) =0 getsockopt(5, SOL_SOCKET, SO_SNDBUF, [65535], [4]) = 0 getsockopt(5, SOL_SOCKET, SO_RCVBUF, [65535], [4]) = 0 getsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], [4]) = 0 bind(5, {sin_family=AF_INET, sin_port=htons(24445), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 listen(5,128) socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 fcntl(6,F_SETFD, FD_CLOEXEC) =0 getsockopt(6, SOL_SOCKET, SO_SNDBUF, [65535], [4]) = 0 getsockopt(6, SOL_SOCKET, SO_RCVBUF, [65535], [4]) = 0 getsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], [4]) = 0 bind(6, {sin_family=AF_INET, sin_port=htons(24446), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 listen(6,128) socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 FCNTL(7,F_SETFD, FD_CLOEXEC) =0 getsockopt(7, SOL_SOCKET, SO_SNDBUF, [65535], [4]) = 0 getsockopt(7, SOL_SOCKET, SO_RCVBUF, [65535], [4]) = 0 getsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], [4]) = 0 bind(7, {sin_family=AF_INET, sin_port=htons(24447), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 listen(7,128) ... This continues with incrementing numbers until it hits 255, then I get socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = -1 EMFILE (Too many open files) ... repeatedly, until the process is killed. Any pointers on where I should look for the source of this problem? Thanks, Steven W. Russert Boeing Phantom Works M&CT steven.w.russert@boeing.com 425-865-3588 From haoboy@isi.edu Thu Mar 4 19:12:58 1999 From: haoboy@isi.edu (Haobo Yu) Date: Thu, 4 Mar 1999 11:12:58 -0800 (PST) Subject: nam - no display In-Reply-To: <618FD3AF120DD111A27900805F19D9C4039DCF92@xch-blv-03.ca.boeing.com> Message-ID: When nam starts up, it tries to listen on a socket. In order to find a suitable port address, it does a linear search starting from 24443. If it fails to allocate a socket on an address, it assumes that Tcl will automatically close the socket so it doesn't close it. It turns out that this assumption is wrong; when Tcl's socket returns error, nam still needs to explicitly close it. Here is the patch, please let me know if it doesn't help. Thanks. - Haobo -------------------------------------- --- anim-ctrl.tcl 1999/02/18 18:31:04 1.18 +++ anim-ctrl.tcl 1999/03/04 18:48:14 @@ -79,6 +79,14 @@ incr NAM_PORT_ set ret [catch {set NAM_SOCK_ \ [socket -server ::AnimCtrlOnRemoteRequest $NAM_PORT_]}] + if {$ret} { + # Failed, delete the socket + close $NAM_SOCK_ + if {$NAM_PORT_ - $INIT_PORT > 254} { + error "Nam failed to create a socket ranging \ +from $INIT_PORT_ to $NAM_PORT_." + } + } } # Write that to a lock file, which resides under home directory -------------------------------- On Thu, 4 Mar 1999, Russert, Steven W wrote: > Thanks to Christian Joensson for the suggestion to use STRACE nam to find out what is holding up the works. The problem on the surface is, indeed, "too many open files". It looks like something might be in a loop, though. Here is the kind of entry I see in the trace output by STRACE. > ... > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5 > fcntl(5,F_SETFD, FD_CLOEXEC) =0 > getsockopt(5, SOL_SOCKET, SO_SNDBUF, [65535], [4]) = 0 > getsockopt(5, SOL_SOCKET, SO_RCVBUF, [65535], [4]) = 0 > getsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], [4]) = 0 > bind(5, {sin_family=AF_INET, sin_port=htons(24445), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > listen(5,128) > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 > fcntl(6,F_SETFD, FD_CLOEXEC) =0 > getsockopt(6, SOL_SOCKET, SO_SNDBUF, [65535], [4]) = 0 > getsockopt(6, SOL_SOCKET, SO_RCVBUF, [65535], [4]) = 0 > getsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], [4]) = 0 > bind(6, {sin_family=AF_INET, sin_port=htons(24446), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > listen(6,128) > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 > FCNTL(7,F_SETFD, FD_CLOEXEC) =0 > getsockopt(7, SOL_SOCKET, SO_SNDBUF, [65535], [4]) = 0 > getsockopt(7, SOL_SOCKET, SO_RCVBUF, [65535], [4]) = 0 > getsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], [4]) = 0 > bind(7, {sin_family=AF_INET, sin_port=htons(24447), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > listen(7,128) > ... > This continues with incrementing numbers until it hits 255, then I get > > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = -1 EMFILE (Too many open files) > ... > repeatedly, until the process is killed. > > Any pointers on where I should look for the source of this problem? > > > Thanks, > > Steven W. Russert > Boeing Phantom Works M&CT > steven.w.russert@boeing.com > 425-865-3588 > > > > From mallman@lerc.nasa.gov Thu Mar 4 20:55:23 1999 From: mallman@lerc.nasa.gov (Mark Allman) Date: Thu, 04 Mar 1999 15:55:23 -0500 Subject: icmp messages Message-ID: <199903042055.PAA19301@guns.lerc.nasa.gov> > i had to implement the same. my requirement was to > send an icmp source quench message to source A > whenever a router drops a packet from source A. > > the way i did it is like this: > > [...] Your method worked great. I am not sure if my implementation is the cleanest, but it does seem to be working OK. I still have a few more minor things to do, but the hard part is done. Thanks for the suggestion. It was a big help! allman From yangh@usc.edu Fri Mar 5 03:01:31 1999 From: yangh@usc.edu (yangh) Date: Thu, 4 Mar 1999 19:01:31 -0800 (PST) Subject: Nam display Message-ID: Hi, I tried to run the "tcp-many.tcl" under ns-2/tcl/ex. It seems ok. But the problem is that there is no nam window pop out when the program is running. If I would like to use nam to display, how could I do it? Thank you for your help and time. Yang From hussein@maxwell.ee.washington.edu Fri Mar 5 06:49:07 1999 From: hussein@maxwell.ee.washington.edu (AL-HUSSEIN ABOU-ZEID) Date: Thu, 04 Mar 1999 22:49:07 PST Subject: Two State Markov Model in ns-v2.1b4a Message-ID: <199903050649.WAA12912@maxwell.ee.washington.edu> I've been trying to use the ErrorModel/TwoStateMarkov or ErrorModel/TwoState with no success in either. I've been using the following script: #Create and attach a loss model to the link set myrates [list 40ms 0.4ms] set mytrans [list 1.0 1.0] set myeu time set em [new ErrorModel/TwoStateMarkov $myrates $myeu $mytrans] #<--- set tr [$ns create-trace Loss $f $n0 $n1] $em drop-target $tr $ns lossmodel $em $n0 $n1 I'm not sure if there is some novice error there in the script, since I am infact a novice with ns and its scripting language, but I don't think there is. In fact, I noticed that the parameters passed in the transition vector are not used by ns. Also, using ErrorModel/TwoState creates a segmentation fault. (for example: set em [new ErrorModel/TwoState 0.8 0.2] instead of the above line). Will appreciate if anyone knows how to use multiple state models in ns to give me a hint. Thanks in Advance. ------------------------ Al-hussein A. Abou-zeid University of Washington, Seattle EE Dept. From muellert@ifn.et.tu-dresden.de Fri Mar 5 11:42:02 1999 From: muellert@ifn.et.tu-dresden.de (Torsten Mueller) Date: Fri, 5 Mar 1999 12:42:02 +0100 Subject: Users and Programmers Manual Message-ID: <199903051142.MAA00458@entcw7.et.tu-dresden.de> Hallo, there has been a question about references how to program ns modules. I have seen a users and programmers manual on the web. It covers an extension to ns, but maybe it is also useful. (I havent checked that) Torsten *********************************************************************** * Torsten Mueller * Tel.: +49 351 463-4621 , 3942 * * Dresden University of Technology * Fax: +49 351 463-7163 * * Communications Laboratory * Email: * * D-01062 Dresden, Germany * muellert@ifn.et.tu-dresden.de * * http://www.ifn.et.tu-dresden.de/~muellert * *********************************************************************** From pantong@public1.ptt.js.cn Fri Mar 5 13:38:08 1999 From: pantong@public1.ptt.js.cn (YangMing) Date: Fri, 5 Mar 1999 21:38:08 +0800 Subject: A TclCL problem Message-ID: <01be670d$68013d20$4b4166ca@http.www.jlonline.com> This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BE6750.76247D20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable problem: A string code[] is defined in embedded-tcl.cc,its length is = greater than maximum string length(2048 bytes)allowed in microsoft C,so = a build error is reported. -Yang Ming ------=_NextPart_000_0004_01BE6750.76247D20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
problem: A string code[] is defined in = embedded-tcl.cc,its=20 length is greater than maximum string length(2048 bytes)allowed in = microsoft=20 C,so a build error is reported.
 
-Yang Ming
------=_NextPart_000_0004_01BE6750.76247D20-- From eroesch@iutsud.u-strasbg.fr Fri Mar 5 14:56:08 1999 From: eroesch@iutsud.u-strasbg.fr (eroesch@iutsud.u-strasbg.fr) Date: Fri, 05 Mar 1999 15:56:08 +0100 Subject: Users and Programmers Manual In-Reply-To: <199903051142.MAA00458@entcw7.et.tu-dresden.de> Message-ID: <3.0.1.32.19990305155608.00937cd0@iutsud.u-strasbg.fr> >there has been a question about references how to program ns modules. >I have seen a users and programmers manual on the web. >It covers an extension to ns, but maybe it is also useful. >(I havent checked that) Can you give the URL ? :) I got a tutorial about ns .. but couldn't find a kind of "programmer manuel" .. ----- Etienne From Lloyd Wood Fri Mar 5 15:10:25 1999 From: Lloyd Wood (Lloyd Wood) Date: Fri, 5 Mar 1999 15:10:25 +0000 (GMT) Subject: Users and Programmers Manual In-Reply-To: <3.0.1.32.19990305155608.00937cd0@iutsud.u-strasbg.fr> Message-ID: On Fri, 5 Mar 1999 eroesch@iutsud.u-strasbg.fr wrote: > >there has been a question about references how to program ns modules. > >I have seen a users and programmers manual on the web. > >It covers an extension to ns, but maybe it is also useful. > >(I havent checked that) > > Can you give the URL ? :) > I got a tutorial about ns .. but couldn't find a kind of "programmer > manuel" .. You couldn't find: http://www-mash.cs.berkeley.edu/ns/ns-documentation.html ? (and nsDoc.ps was last updated March 3, I see. would be good if the postscript file was copied to under /dist so we'd be mirroring that too - and it might increase chances of people finding the thing.) Cheers, L. PGP From softrel9@nortelnetworks.com Fri Mar 5 16:27:15 1999 From: softrel9@nortelnetworks.com (Sarah Liu) Date: Fri, 5 Mar 1999 11:27:15 -0500 Subject: nam no-display Message-ID: <03E3E0690542D211A1490000F80836F43E45D0@zcard00f.ca.nortel.com> Hi, Haobo and Steven: I saw the emails that concerns nam no-display, but I can't find the original problem describing email that Steven sent. I just wonder what the problem is like and what may cause the nam no-display. Because right now, I met a similar problem in my machine. Yesterday, before I left the office, the nam was working fine. Today, I logged in the computer and tried to run some test-suites, the ns is working fine. But when I ran the nam file, nothing showed up. It seems strange. Since all the test suites that work fine and can pop up the nam window with the packet flowing. Right now, I haven't find the cause of it. I don't know if it caused by the network connection or it caused by the modification that I made into {ns-lib, ns-link}.tcl to make the dropped packet visible in nam? If you have any clue of cause and how to solve it, please send me an email. Thanks a lot for your help. cheers, Sarah ---------------------------------------------------------------------------- -------------------------------- Sarah Xiaohui Liu, 613-765-3203 o__ o~__ Email: softrel9@nortelnetworks.com _,>/_ _,>/_ u1452573@csi.uottawa.ca (*) (*) (*) (*) Mail Stop: 0C32, Nortel Networks Corp. ---------------------------------------------------------------------------- -------------------------------- From kwang@cs.umd.edu Fri Mar 5 17:10:41 1999 From: kwang@cs.umd.edu (Kuang-Yeh Wang) Date: Fri, 5 Mar 1999 12:10:41 -0500 (EST) Subject: Two State Markov Model in ns-v2.1b4a In-Reply-To: <199903050649.WAA12912@maxwell.ee.washington.edu> Message-ID: On Thu, 4 Mar 1999, AL-HUSSEIN ABOU-ZEID wrote: > > I've been trying to use the ErrorModel/TwoStateMarkov or > ErrorModel/TwoState with no success in either. > > I've been using the following script: > > #Create and attach a loss model to the link > set myrates [list 40ms 0.4ms] > set mytrans [list 1.0 1.0] > set myeu time > set em [new ErrorModel/TwoStateMarkov $myrates $myeu $mytrans] #<--- > set tr [$ns create-trace Loss $f $n0 $n1] > $em drop-target $tr > $ns lossmodel $em $n0 $n1 > > I'm not sure if there is some novice error there in the script, since I am > infact a novice with ns and its scripting language, but I don't think > there is. In fact, I noticed that the parameters passed in the transition > vector are not used by ns. A quick look at the file "tcl/lib/ns-errmodel.tcl" tells why the transition vector is ignored: the relevant lines in ErrorModel/TwoStateMarkov instproc init are commented out. > Also, using ErrorModel/TwoState creates a segmentation fault. (for > example: set em [new ErrorModel/TwoState 0.8 0.2] instead of the above > line). The two parameters following the class name should be random variables (RandomVariable) that determine the lengths of "error free" and "error" states. See ns Notes and Documentation, chapter 14. > Will appreciate if anyone knows how to use multiple state models in ns to > give me a hint. > > Thanks in Advance. > > ------------------------ > Al-hussein A. Abou-zeid > University of Washington, Seattle > EE Dept. > Now here is my question about TwoStateErrorModel: If I use "time" as the unit, the length of a state counts only the time when the link is actually transmitting data, i.e., idle time is not included. Is this observation correct? I brought this up because I think this feature (if my understanding of it is right) may or may not fit the scenarios people want to simulate. ======================================== Kuang-Yeh Wang kwang@cs.umd.edu University of Maryland at College Park Department of Computer Science ======================================== From haoboy@isi.edu Fri Mar 5 18:05:52 1999 From: haoboy@isi.edu (Haobo Yu) Date: Fri, 5 Mar 1999 10:05:52 -0800 (PST) Subject: nam no-display In-Reply-To: <03E3E0690542D211A1490000F80836F43E45D0@zcard00f.ca.nortel.com> Message-ID: The original Steven's message is at: http://www-mash.cs.berkeley.edu/dist/archive/ns-users/9903/0008.html. A more detailed strace output of the problem after Christian's suggestion is at: http://www-mash.cs.berkeley.edu/dist/archive/ns-users/9903/0056.html The final solution is at: http://www-mash.cs.berkeley.edu/dist/archive/ns-users/9903/0057.html - Haobo On Fri, 5 Mar 1999, Sarah Liu wrote: > Hi, Haobo and Steven: > > I saw the emails that concerns nam no-display, but I can't find the original > problem describing email that Steven sent. I just wonder what the problem is > like and what may cause the nam no-display. Because right now, I met a > similar problem in my machine. Yesterday, before I left the office, the nam > was working fine. Today, I logged in the computer and tried to run some > test-suites, the ns is working fine. But when I ran the nam file, nothing > showed up. It seems strange. Since all the test suites that work fine and > can pop up the nam window with the packet flowing. Right now, I haven't find > the cause of it. I don't know if it caused by the network connection or it > caused by the modification that I made into {ns-lib, ns-link}.tcl to make > the dropped packet visible in nam? If you have any clue of cause and how to > solve it, please send me an email. Thanks a lot for your help. > > cheers, > > Sarah From softrel9@nortelnetworks.com Fri Mar 5 18:59:14 1999 From: softrel9@nortelnetworks.com (Sarah Liu) Date: Fri, 5 Mar 1999 12:59:14 -0600 Subject: nam no-display Message-ID: <03E3E0690542D211A1490000F80836F43E45D1@zcard00f.ca.nortel.com> Hi, Haobo: Thanks for the email. I have already found what causes the problem. My colleague put too many kernel process running in the server, so that nam can't find any port address to run the file. After we killed all the processes, nam is working now. Also, following your suggestion, I modified the file anim-ctrl.tcl to fix the bug. Now it's working fine. Thanks for help. Have a nice weekend. Sarah ---------------------------------------------------------------------------- -------------------------------- Sarah Xiaohui Liu, 613-765-3203 o__ o~__ Email: softrel9@nortelnetworks.com _,>/_ _,>/_ u1452573@csi.uottawa.ca (*) (*) (*) (*) Mail Stop: 0C32, Nortel Networks Corp. ---------------------------------------------------------------------------- -------------------------------- From SVA0392@tntech.edu Fri Mar 5 21:10:07 1999 From: SVA0392@tntech.edu (SVA0392) Date: Fri, 05 Mar 1999 15:10:07 -0600 Subject: Need Help --- Error while executing ns Message-ID: <000101be674c$8c0cd820$15059595@bn207-21.pclab.tntech.edu> Hi, I installed ns and when I tried to execute the file srm.tcl in /tcl/ex directory, I got the following error: ------------------------------------------------ $ ./ns ./tcl/ex/srm-adapt-req.tcl ns: _o4 run-mcast: invalid command name "0" while executing "[$link set ifacein_] set intf_label_" (procedure "_o51" line 3) (Node get-oif line 3) invoked from within "$self get-oif $link" (procedure "_o51" line 5) (Node init-outLink line 5) invoked from within "$node init-outLink" (procedure "_o4" line 5) (Simulator run-mcast line 5) invoked from within "_o4 run-mcast" ------------------------------------------------------- Please help me Sincerely, Syam Appala From johnh@ISI.EDU Fri Mar 5 21:43:48 1999 From: johnh@ISI.EDU (John Heidemann) Date: Fri, 05 Mar 1999 13:43:48 -0800 Subject: A TclCL problem In-Reply-To: <01be670d$68013d20$4b4166ca@http.www.jlonline.com> Message-ID: <199903052143.NAA06775@dash.isi.edu> On Fri, 05 Mar 1999 21:38:08 +0800, "YangMing" wrote: >problem: A string code[] is defined in embedded-tcl.cc,its length is greater than maximum string length(2048 bytes)allowed in microsoft C,so a build error is reported. tcl2c++.c has code at the beginning to work around this problem (see TCL2C_INT). Can you look at this and figure out why this define is not being used on yo