From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 3 03:32:31 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 03 Mar 2008 06:32:31 -0500
Subject: [Ns-bugs] [Bug 145] New: waypoint list mobility model
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=145
Summary: waypoint list mobility model
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: node module
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
I made a new "waypoint list" mobility model, to help a student working with
NS-3. It's similar to the random waypoint model, but in this case the
waypoints are deterministic and taken from a list given by the programmer. Let
me know if there is interest in including this model in ns-3-dev.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 3 03:32:53 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 03 Mar 2008 06:32:53 -0500
Subject: [Ns-bugs] [Bug 145] waypoint list mobility model
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=145
------- Comment #1 from gjcarneiro at gmail.com 2008-03-03 06:32 -------
Created an attachment (id=113)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=113&action=view)
patch
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 3 03:33:21 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 03 Mar 2008 06:33:21 -0500
Subject: [Ns-bugs] [Bug 145] waypoint list mobility model
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=145
gjcarneiro at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 3 03:39:51 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 03 Mar 2008 06:39:51 -0500
Subject: [Ns-bugs] [Bug 145] waypoint list mobility model
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=145
gjcarneiro at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #113 is|0 |1
obsolete| |
------- Comment #2 from gjcarneiro at gmail.com 2008-03-03 06:39 -------
Created an attachment (id=114)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=114&action=view)
patch v2 (fixes bad copy-paste of copyright)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 6 14:58:30 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 06 Mar 2008 17:58:30 -0500
Subject: [Ns-bugs] [Bug 138] Point-to-point netdevice queues aren't
configurable from higher layers
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=138
------- Comment #2 from tomh at tomh.org 2008-03-06 17:58 -------
Gustavo,
I think you raise an interesting question-- whether GetObject () should be used
for cases where dynamic_cast<> can be used. When we were considering more
fully COM-like approaches, the answer seemed to be that we would use
QueryInterface for such downcasts. We could choose between two policies in our
code base:
- avoid dynamic_cast, use GetObject
- use dynamic_cast where you want a subclass pointer, and GetObject for when an
entirely different object needs to be fetched
Other opinions?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 6 17:25:53 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 06 Mar 2008 20:25:53 -0500
Subject: [Ns-bugs] [Bug 138] Point-to-point netdevice queues aren't
configurable from higher layers
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=138
------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-03-06 20:25 -------
(In reply to comment #2)
> - avoid dynamic_cast, use GetObject
> - use dynamic_cast where you want a subclass pointer, and GetObject for when an
> entirely different object needs to be fetched
The former is definitely the easiest to use. dynamic_cast would require the
user to call PeekPointer which is definitely something we would like to avoid.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 6 18:56:41 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 06 Mar 2008 21:56:41 -0500
Subject: [Ns-bugs] [Bug 138] Point-to-point netdevice queues aren't
configurable from higher layers
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=138
------- Comment #4 from craigdo at ee.washington.edu 2008-03-06 21:56 -------
I prefer using GetObject.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 7 03:01:50 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 07 Mar 2008 06:01:50 -0500
Subject: [Ns-bugs] [Bug 138] Point-to-point netdevice queues aren't
configurable from higher layers
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=138
------- Comment #5 from gjcarneiro at gmail.com 2008-03-07 06:01 -------
(In reply to comment #4)
> I prefer using GetObject.
>
But keep in mind that:
1- GetObject does some completely redundant work that dynamic_cast doesn't
have to do. In particular now that types have parent types and all, I have
seen GetObject and TypeId::GetParent starting to appear in performance
profiling.
2- Having a GetQueue () explicit method makes the code easier to use than
GetObject (). GetObject makes some things rather hidden from the
programmer; you can't tell there is a certain object aggregated by looking at
the header file alone.
3- The main point of GetObject is to gain modularity and decoupling of
orthogonal aspects. If netdevices always need to have queues, then we are not
getting anything.
So we potentially lose performance (1), readability (2), and do not gain
anything in return (3). There's only one argument in favor of GetObject, here,
which is that it is easier to use. But if we want easy to use, we might as
well redesign the GetQueue method like this:
template
Ptr GetQueue (void) const
{
return dynamic_cast (PeekPointer (DoGetQueue ()));
}
Problem solved. Or add my DynamicCast function.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 7 14:46:09 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 07 Mar 2008 17:46:09 -0500
Subject: [Ns-bugs] [Bug 138] Point-to-point netdevice queues aren't
configurable from higher layers
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=138
------- Comment #6 from tomh at tomh.org 2008-03-07 17:46 -------
an additional technique may be to use an attribute. I'd like to suggest that
we try to support this particular case with by setting an attribute, once that
system is finalized, before deciding on trying to support it otherwise.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 14 10:09:39 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 14 Mar 2008 13:09:39 -0400
Subject: [Ns-bugs] [Bug 142] ns-3.0.11 fails to build with gcc 3.4
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=142
mathieu.lacage at sophia.inria.fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #6 from mathieu.lacage at sophia.inria.fr 2008-03-14 13:09 -------
Bug fixed on ns-3-param branch to be merged soon.
tested on ubuntu 7.10 64 bit g++ 3.4
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 05:58:51 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 08:58:51 -0400
Subject: [Ns-bugs] [Bug 146] New: Ipv4Address API cleanup
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=146
Summary: Ipv4Address API cleanup
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: node module
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
This patch proposes to remove the "HostOrder" postfix of the name of getters
and setters in Ipv4Address. Instead, all Getters and Setters are host order;
if we introduce network order getters and setters, we could perhaps qualify
those with the "NetworkOrder" postfix such as "SetNetworkOrder" (but presently
there are no such methods).
It also does a bit of API cleanup/doxygen and removes redundant methods.
(suggested by George and extended by Tom)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 05:59:42 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 08:59:42 -0400
Subject: [Ns-bugs] [Bug 146] Ipv4Address API cleanup
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=146
------- Comment #1 from tomh at tomh.org 2008-03-17 08:59 -------
Created an attachment (id=115)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=115&action=view)
the proposed API changes and source code alignment
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 06:07:00 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 09:07:00 -0400
Subject: [Ns-bugs] [Bug 147] New: base class for reference counted objects
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=147
Summary: base class for reference counted objects
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
As discussed in November, a base class for providing implementations of
Ref/Unref for classes that do not derive from ns3::Object.
Written by George, with proposed rename by Tom from "SmartPointer" to
"RefCountBase".
We need to decide which classes use this base class. Should any of the below
be specifically excluded from this class?:
AttributeAccessor
AttributeChecker
Packet
Object
TraceSourceAccessor
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 06:07:33 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 09:07:33 -0400
Subject: [Ns-bugs] [Bug 147] base class for reference counted objects
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=147
------- Comment #1 from tomh at tomh.org 2008-03-17 09:07 -------
Created an attachment (id=116)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=116&action=view)
class RefCountBase
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 07:48:10 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 10:48:10 -0400
Subject: [Ns-bugs] [Bug 146] Ipv4Address API cleanup
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=146
------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-03-17 10:48 -------
(In reply to comment #0)
> This patch proposes to remove the "HostOrder" postfix of the name of getters
> and setters in Ipv4Address. Instead, all Getters and Setters are host order;
> if we introduce network order getters and setters, we could perhaps qualify
> those with the "NetworkOrder" postfix such as "SetNetworkOrder" (but presently
> there are no such methods).
I think that the long method name is actually nice and descriptive so, I find
it weird to make the method names less descriptive.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 07:51:10 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 10:51:10 -0400
Subject: [Ns-bugs] [Bug 147] base class for reference counted objects
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=147
------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-03-17 10:51 -------
(In reply to comment #0)
> As discussed in November, a base class for providing implementations of
> Ref/Unref for classes that do not derive from ns3::Object.
>
> Written by George, with proposed rename by Tom from "SmartPointer" to
> "RefCountBase".
>
> We need to decide which classes use this base class. Should any of the below
> be specifically excluded from this class?:
> AttributeAccessor
> AttributeChecker
> Packet
> Object
> TraceSourceAccessor
Object should not because the implementation is very different/incompatible.
All the others could but they already derive from the ObjectBase class so doing
what you suggest now would require some multiple inheritance which I would
rather avoid.
Since I plan to remove eventually the ObjectBase class from their inheritance
tree, could we defer using RefCountBase in the classes which derive from
ObjectBase until I have done that removal ?
Other than that, looks good to me.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 09:43:01 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 12:43:01 -0400
Subject: [Ns-bugs] [Bug 147] base class for reference counted objects
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=147
------- Comment #3 from raj.b at gatech.edu 2008-03-17 12:43 -------
(In reply to comment #2)
> Object should not because the implementation is very different/incompatible.
> All the others could but they already derive from the ObjectBase class so doing
> what you suggest now would require some multiple inheritance which I would
> rather avoid.
>
> Since I plan to remove eventually the ObjectBase class from their inheritance
> tree, could we defer using RefCountBase in the classes which derive from
> ObjectBase until I have done that removal ?
>
> Other than that, looks good to me.
>
Instead, we could add Ref and Unref into ObjectBase, and then eventually
renaming ObjectBase to RefCountedBase? There is no problem with Object
inheriting from this class too (as it does now), because it would just
reimplement Ref and Unref with its own implementation, provided we make the
ObjectBase::Ref and Unref methods virtual.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 09:58:32 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 12:58:32 -0400
Subject: [Ns-bugs] [Bug 147] base class for reference counted objects
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=147
------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-03-17 12:58 -------
(In reply to comment #3)
> (In reply to comment #2)
> > Object should not because the implementation is very different/incompatible.
> > All the others could but they already derive from the ObjectBase class so doing
> > what you suggest now would require some multiple inheritance which I would
> > rather avoid.
> >
> > Since I plan to remove eventually the ObjectBase class from their inheritance
> > tree, could we defer using RefCountBase in the classes which derive from
> > ObjectBase until I have done that removal ?
> >
> > Other than that, looks good to me.
> >
>
> Instead, we could add Ref and Unref into ObjectBase, and then eventually
> renaming ObjectBase to RefCountedBase? There is no problem with Object
The plan is to move the attribute system to ObjectBase, not the reference
counting to allow classes which do not want to be refcounted to get the
attributes anyway.
The only reason why they inherit from ObjectBase now is that I needed to do
this as a temporary hack to get the attributes working a few weeks ago and
never removed it since then because no one reminded me of the merge of
RefCountedBase.
> inheriting from this class too (as it does now), because it would just
> reimplement Ref and Unref with its own implementation, provided we make the
> ObjectBase::Ref and Unref methods virtual.
We cannot make these virtual for performance reasons.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 17 19:40:28 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 17 Mar 2008 22:40:28 -0400
Subject: [Ns-bugs] [Bug 146] Ipv4Address API cleanup
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=146
------- Comment #3 from tomh at tomh.org 2008-03-17 22:40 -------
(In reply to comment #2)
> (In reply to comment #0)
> > This patch proposes to remove the "HostOrder" postfix of the name of getters
> > and setters in Ipv4Address. Instead, all Getters and Setters are host order;
> > if we introduce network order getters and setters, we could perhaps qualify
> > those with the "NetworkOrder" postfix such as "SetNetworkOrder" (but presently
> > there are no such methods).
>
> I think that the long method name is actually nice and descriptive so, I find
> it weird to make the method names less descriptive.
>
Yes, it is more descriptive, but longer to type, and e.g. the constructor
assumes host order without such a qualifier. All of the getters and setters
are host order; we have network byte order methods but they are called
Serialize and Deserialize and operate on a byte array.
I could live with GetHostOrder and SetHostOrder if we removed redundant Set()
methods already there, and removed the warnings around their usage, but it
seems simpler to me to just say Set() and Get().
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Mar 18 08:13:50 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Tue, 18 Mar 2008 11:13:50 -0400
Subject: [Ns-bugs] [Bug 146] Ipv4Address API cleanup
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=146
------- Comment #4 from mathieu.lacage at sophia.inria.fr 2008-03-18 11:13 -------
> > > This patch proposes to remove the "HostOrder" postfix of the name of getters
> > > and setters in Ipv4Address. Instead, all Getters and Setters are host order;
> > > if we introduce network order getters and setters, we could perhaps qualify
> > > those with the "NetworkOrder" postfix such as "SetNetworkOrder" (but presently
> > > there are no such methods).
> >
> > I think that the long method name is actually nice and descriptive so, I find
> > it weird to make the method names less descriptive.
> >
>
> Yes, it is more descriptive, but longer to type, and e.g. the constructor
> assumes host order without such a qualifier. All of the getters and setters
> are host order; we have network byte order methods but they are called
> Serialize and Deserialize and operate on a byte array.
ok. That is a good point.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 20 10:54:23 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 20 Mar 2008 13:54:23 -0400
Subject: [Ns-bugs] [Bug 148] New: Replace "std::string context" parameter
with a more useful Config::Path parameter
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=148
Summary: Replace "std::string context" parameter with a more
useful Config::Path parameter
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
My proposed Config::Path has more useful component retrieval and parsing
methods, for when you want to extract node index numbers etc. from the context.
It also makes it very clear it is just a path; one less thing to learn.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 20 10:55:11 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 20 Mar 2008 13:55:11 -0400
Subject: [Ns-bugs] [Bug 148] Replace "std::string context" parameter with a
more useful Config::Path parameter
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=148
------- Comment #1 from gjcarneiro at gmail.com 2008-03-20 13:55 -------
Created an attachment (id=117)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=117&action=view)
patch
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 21 09:58:15 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 21 Mar 2008 12:58:15 -0400
Subject: [Ns-bugs] [Bug 149] New: Wifi Headers
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=149
Summary: Wifi Headers
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: build system
AssignedTo: ns-bugs at isi.edu
ReportedBy: tjkopena at cs.drexel.edu
Seems like src/devices/wifi/wscript should include supported-rates.h in both
ns-3-dev and mathieu/ns-3-param repositories. It gets included by the module
helper files, which works in the normal build, but then is not there if you're
compiling externally against ns-3.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 21 10:03:21 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 21 Mar 2008 13:03:21 -0400
Subject: [Ns-bugs] [Bug 149] Wifi Headers
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=149
mathieu.lacage at sophia.inria.fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-03-21 13:03 -------
thanks.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Mar 22 10:36:34 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Sat, 22 Mar 2008 13:36:34 -0400
Subject: [Ns-bugs] [Bug 150] New: CommandLine::Parse argc parameter should
not be a reference
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=150
Summary: CommandLine::Parse argc parameter should not be a
reference
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P3
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
Something I found out while working on python bindings:
/**
* \param argc the 'argc' variable: number of arguments (including the
* main program name as first element).
* \param argv the 'argv' variable: a null-terminated array of strings,
* each of which identifies a command-line argument.
*
* Obviously, this method will parse the input command-line arguments and
* will attempt to handle them all.
*/
void Parse (int &argc, char *argv[]) const;
This is wrong; the only explanation for argc being a reference would be that it
is inout or out argument. However, when I looked at the sources I was
surprised to discover that it was neither. In this case the & is misleading
and unnecessary.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Mar 22 10:58:39 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Sat, 22 Mar 2008 13:58:39 -0400
Subject: [Ns-bugs] [Bug 150] CommandLine::Parse argc parameter should not be
a reference
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=150
------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-03-22 13:58 -------
(In reply to comment #0)
> Something I found out while working on python bindings:
>
> /**
> * \param argc the 'argc' variable: number of arguments (including the
> * main program name as first element).
> * \param argv the 'argv' variable: a null-terminated array of strings,
> * each of which identifies a command-line argument.
> *
> * Obviously, this method will parse the input command-line arguments and
> * will attempt to handle them all.
> */
> void Parse (int &argc, char *argv[]) const;
>
> This is wrong; the only explanation for argc being a reference would be that it
> is inout or out argument. However, when I looked at the sources I was
> surprised to discover that it was neither. In this case the & is misleading
> and unnecessary.
>
You are right.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Tue Mar 25 15:39:41 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Tue, 25 Mar 2008 18:39:41 -0400
Subject: [Ns-bugs] [Bug 151] New: TcpHeader::Print not implemented
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=151
Summary: TcpHeader::Print not implemented
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: internet-node
AssignedTo: ns-bugs at isi.edu
ReportedBy: mathieu.lacage at sophia.inria.fr
the title says it all. This makes Ascii trace output slightly suboptimal.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Mar 26 06:06:54 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Wed, 26 Mar 2008 09:06:54 -0400
Subject: [Ns-bugs] [Bug 152] New: Typo in csma-channel.cc causes stack
overflow
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=152
Summary: Typo in csma-channel.cc causes stack overflow
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: gvubrugier at gmail.com
Already fixed for point-to-point-channel.
--
diff -r 177a8a3f3c65 src/devices/csma/csma-channel.cc
--- a/src/devices/csma/csma-channel.cc Tue Mar 25 17:14:33 2008 -0700
+++ b/src/devices/csma/csma-channel.cc Wed Mar 26 15:04:22 2008 +0100
@@ -358,7 +358,7 @@ Ptr
Ptr
CsmaChannel::GetDevice (uint32_t i) const
{
- return GetDevice (i);
+ return GetCsmaDevice (i);
}
} // namespace ns3
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Mar 26 06:08:40 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Wed, 26 Mar 2008 09:08:40 -0400
Subject: [Ns-bugs] [Bug 152] Typo in csma-channel.cc causes stack overflow
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=152
------- Comment #1 from gvubrugier at gmail.com 2008-03-26 09:08 -------
Created an attachment (id=118)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=118&action=view)
bugfix
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Mar 26 07:15:29 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Wed, 26 Mar 2008 10:15:29 -0400
Subject: [Ns-bugs] [Bug 152] Typo in csma-channel.cc causes stack overflow
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=152
raj.b at gatech.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #2 from raj.b at gatech.edu 2008-03-26 10:15 -------
Thanks for the patch. Pushed in ns-3-dev :
2747:4796695f60fb
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Mar 26 07:33:54 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Wed, 26 Mar 2008 10:33:54 -0400
Subject: [Ns-bugs] [Bug 148] Replace "std::string context" parameter with a
more useful Config::Path parameter
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=148
------- Comment #2 from mathieu.lacage at sophia.inria.fr 2008-03-26 10:33 -------
I discussed this at length with gustavo on irc: while I do understand why he
wants to do this, I would personally go another route:
1) keep the current std::string context string in callback signatures
2) provide a Config::Path class which can be constructed from a string (cannot
be converted back to a string) and which performs the string parsing for you to
allow you to call simple methods such as GetElementAsString (1) or
GetElementAsUint32 (2)
Basically, I would take gustavo's proposed code but I would not use it as the
default context in callback signatures.
So, to summarize, I think that gustavo's code is useful. The only question is
how we want to integrate it and although I disagree with gustavo on how it
should be integrated, I don't think it is that important so, if anyone agrees
with gustavo, feel free to apply the patch as-is.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Wed Mar 26 13:53:57 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Wed, 26 Mar 2008 16:53:57 -0400
Subject: [Ns-bugs] [Bug 153] New: PointToPointNetDevice::Add* methods should
be Set methods
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=153
Summary: PointToPointNetDevice::Add* methods should be Set
methods
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: mathieu.lacage at sophia.inria.fr
These are setters, really, so, why should we use the verb Add ?
AddQueue -> SetTransmitQueue (not the addition of the Transmit adjective to
match the naming chosen for the error model)
AddReceiveErrorModel -> SetReceiveErrorModel
The same holds for CsmaNetDevice.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 07:35:48 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 10:35:48 -0400
Subject: [Ns-bugs] [Bug 110] IntEmpiricalVariable is not documented
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=110
raj.b at gatech.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #1 from raj.b at gatech.edu 2008-03-27 10:35 -------
Fixed in ns-3-dev:
2761:f56860663c54
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 07:45:44 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 10:45:44 -0400
Subject: [Ns-bugs] [Bug 132] TCP server sockets do not fork on new
connections
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=132
raj.b at gatech.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #11 from raj.b at gatech.edu 2008-03-27 10:45 -------
Fixed in ns-3-dev, changesets 2362-2368.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 08:21:11 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 11:21:11 -0400
Subject: [Ns-bugs] [Bug 151] TcpHeader::Print not implemented
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=151
raj.b at gatech.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #1 from raj.b at gatech.edu 2008-03-27 11:21 -------
Fixed in ns-3-dev:
2762:3e77772d7cdd
The implementation prints the source and destination ports, any flags which are
set, the sequence and acknowledgment numbers, and the advertised window size.
This is mostly in line with how wireshark displays pcap traces.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 08:27:06 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 11:27:06 -0400
Subject: [Ns-bugs] [Bug 151] TcpHeader::Print not implemented
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=151
------- Comment #2 from raj.b at gatech.edu 2008-03-27 11:27 -------
Oops, wrong revision number. The correct one is:
2762:05982d1a9286
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 09:18:19 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 12:18:19 -0400
Subject: [Ns-bugs] [Bug 154] New: Attach sockets to nodes
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
Summary: Attach sockets to nodes
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: node module
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
I just spent about an hour debugging a problem in a student's NS-3 program.
And the student spent probably a day :-) But I think this problem can be
easily prevented...
The student's code had roughly this structure:
using namespace ns3;
class Test
{
public:
void ReceivePacket (Ptr socket, Ptr packet, const Address
&from);
bool run(void);
};
void Test::ReceivePacket (Ptr socket, Ptr packet, const Address
&from)
{
NS_LOG_INFO("receive packet");
[...]
}
bool
Test::run(void)
{
[...] creates nodes [...]
NS_LOG_INFO ("create socket receive");
Ptr socketFactory= rxNode->GetObject ();
Ptr rxSocket= socketFactory->CreateSocket();
rxSocket=->Bind (InetSocketAddress (Ipv4Address ("10.1.4.2"), 1234));
rxSocket=->SetRecvCallback (MakeCallback (&Test::ReceivePacket, this));
NS_LOG_INFO("send socket ");
Ptr n0SocketFactory = n0->GetObject ();
Ptr n0socket = n0SocketFactory->CreateSocket ();
Ptr packet=Create ();
NS_LOG_INFO("....");
n0socket->SendTo (InetSocketAddress (Ipv4Address("10.1.4.2"),
1234),packet);
return true;
}
int
main (int argc, char *argv[])
{
Test teste;
teste.run();
[...]
NS_LOG_INFO ("Run Simulation.");
Simulator::StopAt (Seconds (3.0));
Simulator::Run ();
Simulator::Destroy ();
NS_LOG_INFO ("Done.");
}
This code does not work because "Ptr rxSocket" inside Test.run() goes
out of scope before the simulation even begins, and so the socket is destroyed.
I would propose that nodes would keep a list of pointers to sockets. They
would release those references when the socket is Close()ed, or when the node
is disposed. This is more or less what is done with Applications already...
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 09:26:56 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 12:26:56 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-03-27 12:26 -------
The expectation is that sockets are held by Applications which are held by
Nodes. So, if you want to avoid these problems, the best way to do so is by
providing new subclasses of the Application base class which hold your sockets.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 09:37:33 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 12:37:33 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #2 from gjcarneiro at gmail.com 2008-03-27 12:37 -------
Holding sockets in some class, be it Application or otherwise, is more work
than needed. NS-3 can save the programmer work by doing this work by itself,
with little cost.
Actually the cost here is _discovering_ the problem. It wasn't at all obvious,
even for me, and only through debugging with NS_LOG was I able to track it
down. The solution to problem is easy; diagnosing the problem was hard.
Eliminating nasty surprises in the simulator is part of our job. So I strongly
recommend either make it work (preferably) or detect the problem automatically
and give an error message. I only know how to make it work, not detect.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 09:55:37 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 12:55:37 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-03-27 12:55 -------
(In reply to comment #2)
> Holding sockets in some class, be it Application or otherwise, is more work
> than needed. NS-3 can save the programmer work by doing this work by itself,
I understand you feel pretty strongly that this is a user bug which can be
avoided but,
> with little cost.
The memory cost is not "little" so, I am very uneasy about this proposal,
especially since there is another fix, as outlined in my previous comment. I am
also pretty uneasy about this proposed change because I really think that it is
a bug to create a socket, release it, and expect it to stay around while you
run the simulation.
Furthermore, I have a very hard time to see how your proposal would gracefully
deal with appearing and disappearing sockets: how can you (user) make sure that
a socket is really released ? Do you have to go into the array attached to the
node and remove it from there ? _that_ sounds really bad.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 10:13:23 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 13:13:23 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #4 from gjcarneiro at gmail.com 2008-03-27 13:13 -------
(In reply to comment #3)
> (In reply to comment #2)
> > Holding sockets in some class, be it Application or otherwise, is more work
> > than needed. NS-3 can save the programmer work by doing this work by itself,
>
> I understand you feel pretty strongly that this is a user bug which can be
> avoided but,
>
> > with little cost.
>
> The memory cost is not "little" so, I am very uneasy about this proposal,
> especially since there is another fix, as outlined in my previous comment. I am
> also pretty uneasy about this proposed change because I really think that it is
> a bug to create a socket, release it, and expect it to stay around while you
> run the simulation.
The memory cost is one pointer per socket. Surely that is negligible. Same
problem as keeping a list of applications in the Node.
>
> Furthermore, I have a very hard time to see how your proposal would gracefully
> deal with appearing and disappearing sockets: how can you (user) make sure that
> a socket is really released ? Do you have to go into the array attached to the
> node and remove it from there ? _that_ sounds really bad.
Like I said, I would envision socket->Close() to take care of it. Or even if a
socket is closed from the remote side, the Node could then release its
reference to it (since a closed socket cannot be used for communication
anymore).
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 11:38:27 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 14:38:27 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #5 from tomh at tomh.org 2008-03-27 14:38 -------
I agree that it is not really intuitive the way the code now works, as
exemplified by this test case. I as a user would expect that if I used a
socket and passed data to it, I could delete my local reference to the socket
afterwards, just as I could lose reference to the descriptor in real code
without destroying the underlying packet.
I would suggest trying to fix this somehow such that the provided test case
works; not by suggesting that users subclass from Application, because
otherwise it is bound to reoccur since I have now seen three ns-3 users write
code like this that avoids the use of base class Application.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 12:22:24 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 15:22:24 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #6 from raj.b at gatech.edu 2008-03-27 15:22 -------
The bottom line is that SOMEONE has to retain a reference to the socket
throughout its lifetime. So far we have two alternatives, one being that the
node retains references to its sockets (Gustavo's suggestion), the other being
that the user of sockets (Applications or end-users) keeps a reference (current
expectation).
An approach we took in Tcp for a similar problem was simply to count the
references to the socket that live in the Ipv4Endpoint demux:
http://code.nsnam.org/ns-3-dev/rev/4956586bd798
In UdpSocket::FinishBind, Note that "this" effectively copied into into the
endpoint by passing the callback. It is never Ref'd however. Our fix was to
pass a smart pointer into the callback, Ref'ing it in the process.
This way, when the endpoint is deallocated, the smart pointer goes out of scope
and Unrefs the socket. The assures that the lifetime of the socket is tied to
the lifetime of its entry in the demux, which seems more correct to me.
So a change similar to what we did in TcpSocket should do the trick.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 13:46:21 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 16:46:21 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #7 from mathieu.lacage at sophia.inria.fr 2008-03-27 16:46 -------
(In reply to comment #6)
> The bottom line is that SOMEONE has to retain a reference to the socket
> throughout its lifetime. So far we have two alternatives, one being that the
> node retains references to its sockets (Gustavo's suggestion), the other being
> that the user of sockets (Applications or end-users) keeps a reference (current
> expectation).
>
> An approach we took in Tcp for a similar problem was simply to count the
> references to the socket that live in the Ipv4Endpoint demux:
> http://code.nsnam.org/ns-3-dev/rev/4956586bd798
>
> In UdpSocket::FinishBind, Note that "this" effectively copied into into the
> endpoint by passing the callback. It is never Ref'd however. Our fix was to
> pass a smart pointer into the callback, Ref'ing it in the process.
>
> This way, when the endpoint is deallocated, the smart pointer goes out of scope
> and Unrefs the socket. The assures that the lifetime of the socket is tied to
> the lifetime of its entry in the demux, which seems more correct to me.
What happens if a user releases the reference to the socket and he never calls
Close ?
>
> So a change similar to what we did in TcpSocket should do the trick.
>
(In reply to comment #6)
> The bottom line is that SOMEONE has to retain a reference to the socket
> throughout its lifetime. So far we have two alternatives, one being that the
> node retains references to its sockets (Gustavo's suggestion), the other being
> that the user of sockets (Applications or end-users) keeps a reference (current
> expectation).
>
> An approach we took in Tcp for a similar problem was simply to count the
> references to the socket that live in the Ipv4Endpoint demux:
> http://code.nsnam.org/ns-3-dev/rev/4956586bd798
>
> In UdpSocket::FinishBind, Note that "this" effectively copied into into the
> endpoint by passing the callback. It is never Ref'd however. Our fix was to
> pass a smart pointer into the callback, Ref'ing it in the process.
>
> This way, when the endpoint is deallocated, the smart pointer goes out of scope
> and Unrefs the socket. The assures that the lifetime of the socket is tied to
> the lifetime of its entry in the demux, which seems more correct to me.
>
> So a change similar to what we did in TcpSocket should do the trick.
I was thinking along similar lines but, for UDP, the lifetime of the socket is
much more problematic: i.e., it is not bound to an underlying stream which can
be closed or not by the remote side. So, if the user forgets to call Close, the
socket will live forever, even though it has data to send and cannot forward
its incoming data to anyone.
I might be worried about a non-issue though.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 13:52:17 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 16:52:17 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #8 from mathieu.lacage at sophia.inria.fr 2008-03-27 16:52 -------
(In reply to comment #5)
> I agree that it is not really intuitive the way the code now works, as
> exemplified by this test case. I as a user would expect that if I used a
> socket and passed data to it, I could delete my local reference to the socket
> afterwards, just as I could lose reference to the descriptor in real code
> without destroying the underlying packet.
Sure, however, what is happening in the real world is that it is your
application which keeps track of open file descriptors and the kernel frees
them when the application dies. The problem here, is that you have associate
your socket to a user context to be able to destroy it when the user context
disapears and the user context in ns3 is the Application class.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 14:26:00 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 17:26:00 -0400
Subject: [Ns-bugs] [Bug 147] base class for reference counted objects
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=147
mathieu.lacage at sophia.inria.fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-03-27 17:26 -------
Since there were no comments on this bug for a while, and since tom's patch
seems ok and since the ObjectBase code was merged earlier last week, I pushed
out tom's patch (modulo a few things to make it build).
Final patch: changeset 03a23eb5f1e8
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 16:36:57 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 19:36:57 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #9 from raj.b at gatech.edu 2008-03-27 19:36 -------
(In reply to comment #7)
[snip]
> What happens if a user releases the reference to the socket and he never calls
> Close ?
>
> I was thinking along similar lines but, for UDP, the lifetime of the socket is
> much more problematic: i.e., it is not bound to an underlying stream which can
> be closed or not by the remote side. So, if the user forgets to call Close, the
> socket will live forever, even though it has data to send and cannot forward
> its incoming data to anyone.
>
> I might be worried about a non-issue though.
I think that the situation you are describing would become an error on the
user's part under my proposal. In the real world, if you don't call close on a
socket, doesn't it persist indefinitely? From this perspective, this is the
correct behavior.
The Socket WILL continue to deliver data up to the application however via the
callback mechanism. The Socket persists and has a pointer to the application
upcall.
And luckily for us, Simulator::Destroy will eventually lead to
UdpL4Protocol::DoDispose, which will delete it's demux, the destructor of which
will delete each endpoint, the destructor of which will release the last
reference to the Socket (the ones that live in the endpoint destroy and rx
callbacks). So this is shouldn't leak memory from a valgrind perspective
either.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 16:49:57 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 19:49:57 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #10 from gjcarneiro at gmail.com 2008-03-27 19:49 -------
(In reply to comment #9)
> (In reply to comment #7)
> [snip]
> > What happens if a user releases the reference to the socket and he never calls
> > Close ?
> >
> > I was thinking along similar lines but, for UDP, the lifetime of the socket is
> > much more problematic: i.e., it is not bound to an underlying stream which can
> > be closed or not by the remote side. So, if the user forgets to call Close, the
> > socket will live forever, even though it has data to send and cannot forward
> > its incoming data to anyone.
> >
> > I might be worried about a non-issue though.
>
> I think that the situation you are describing would become an error on the
> user's part under my proposal.
Hey, your proposal is the same as mine :-)
I just did not understand the implementation very well...
> In the real world, if you don't call close on a
> socket, doesn't it persist indefinitely? From this perspective, this is the
> correct behavior.
Agreed, a socket should live until told to die. A smart pointer going out of
scope should not be enough to make a socket die.
>
> The Socket WILL continue to deliver data up to the application however via the
> callback mechanism. The Socket persists and has a pointer to the application
> upcall.
>
> And luckily for us, Simulator::Destroy will eventually lead to
> UdpL4Protocol::DoDispose, which will delete it's demux, the destructor of which
> will delete each endpoint, the destructor of which will release the last
> reference to the Socket (the ones that live in the endpoint destroy and rx
> callbacks). So this is shouldn't leak memory from a valgrind perspective
> either.
Indeed.
IMHO a socket, once created, should remain under custodian of its factory. The
factory should remove its reference to the socket when either:
1. the factory dies (and the factory dies when the node is disposed, at the
end of the simulation)
2. it is explicitly closed, by calling Socket::Close ()
3. the remote end point closes the connection, for connection oriented
sockets.
I don't think this costs much in terms of memory (at most 16 bytes per socket;
that's less than 1.6 MiB for 10^5 sockets). And like Raj said, having to
close() sockets is already what happens in the real world.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 17:48:21 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 20:48:21 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #11 from raj.b at gatech.edu 2008-03-27 20:48 -------
Created an attachment (id=119)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=119&action=view)
This is gustavo
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 17:49:50 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 20:49:50 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #12 from raj.b at gatech.edu 2008-03-27 20:49 -------
(In reply to comment #11)
> Created an attachment (id=119)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=119&action=view) [edit]
> This is gustavo
>
Should read "This is Gustavo's test case worked out in full"
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 17:49:08 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 20:49:08 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
raj.b at gatech.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #119|This is gustavo |This is Gustavo's test case
description| |worked out in full.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 17:58:21 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Thu, 27 Mar 2008 20:58:21 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #13 from raj.b at gatech.edu 2008-03-27 20:58 -------
Created an attachment (id=120)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=120&action=view)
Proposed solution
To clarify to Gustavo:
The implementation is as follows: Instead of having the creator of the
UdpSocket (what you call the factory) maintain a reference to it and consuming
an extra amount of memory, this approach effectively Ref's the socket one more
time to account for the pointer that exists to the socket in the endpoint
callbacks (Ipv4EndPoint::m_rxCallback and m_destroyCallback). From a reference
counting perspective, I contend this is the right thing to do anyway.
This fix, while somewhat orthogonal to the issue at hand, also happens to solve
the problem.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Thu Mar 27 21:12:15 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 28 Mar 2008 00:12:15 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #14 from tomh at tomh.org 2008-03-28 00:12 -------
> IMHO a socket, once created, should remain under custodian of its factory. The
> factory should remove its reference to the socket when either:
> 1. the factory dies (and the factory dies when the node is disposed, at the
> end of the simulation)
> 2. it is explicitly closed, by calling Socket::Close ()
> 3. the remote end point closes the connection, for connection oriented
> sockets.
>
> I don't think this costs much in terms of memory (at most 16 bytes per socket;
> that's less than 1.6 MiB for 10^5 sockets). And like Raj said, having to
> close() sockets is already what happens in the real world.
>
Yes, but I think it is not completely clear cut. We are debating the issue of
what happens if the user forgets to close the socket. In your proposal, we
could leak sockets (descriptors) in such a case. As presently implemented, we
would delete the socket instead of closing it. Neither really captures what
happens in real code, in which close() is called when the process goes away
before the user closed it.
Your and Raj's proposal would err on the side of keeping sockets around, and I
would be fine with that, because I think it would be less intuitive to a user
to have sockets disappear without even an implicit close() ever having
occurred. This is probably more relevant to consider with TCP but might be a
problem with UDP if we ever model the case where the UDP socket didn't
immediately send the datagram for some reason.
there is the separate issue of whether ns-3 should do something when methods
like Test::Run() are called before Simulation::Run() is called. Clearly, it
will provide undefined behavior to use parts of the API outside of a running
simulation context. Do we want to try to guard against this misuse somehow?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 28 03:15:01 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 28 Mar 2008 06:15:01 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #15 from gjcarneiro at gmail.com 2008-03-28 06:15 -------
(In reply to comment #13)
> Created an attachment (id=120)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=120&action=view) [edit]
> Proposed solution
>
> To clarify to Gustavo:
>
> The implementation is as follows: Instead of having the creator of the
> UdpSocket (what you call the factory) maintain a reference to it and consuming
> an extra amount of memory, this approach effectively Ref's the socket one more
> time to account for the pointer that exists to the socket in the endpoint
> callbacks (Ipv4EndPoint::m_rxCallback and m_destroyCallback). From a reference
> counting perspective, I contend this is the right thing to do anyway.
>
> This fix, while somewhat orthogonal to the issue at hand, also happens to solve
> the problem.
That sounds like a good solution as well, although it has slightly different
semantics from what I proposed. Under your solution, a reference is kept to
the socket as long as there is a (rx,tx,destroy) callback associated with the
socket. That makes sense. A socket with no callbacks and which goes out of
scope should just be freed, as it will not prevent anything from working.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 28 03:34:47 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 28 Mar 2008 06:34:47 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
------- Comment #16 from gjcarneiro at gmail.com 2008-03-28 06:34 -------
(In reply to comment #14)
> Yes, but I think it is not completely clear cut. We are debating the issue of
> what happens if the user forgets to close the socket. In your proposal, we
> could leak sockets (descriptors) in such a case. As presently implemented, we
> would delete the socket instead of closing it. Neither really captures what
> happens in real code, in which close() is called when the process goes away
> before the user closed it.
If you wanted to capture what _really_ happens in the real world, then sockets
would always have to belong to applications, and be conceptually attached to
applications:
Ptr SocketFactory::CreateSocket (Ptr application);
Since in the real world sockets are created by _processes_ making a system call
into the kernel. The kernel would implicitly receive the process ID as
"parameter" and would associate the newly created socket with the process.
In NS-3, because users do not want to have to write new application classes
(ugh!), we would need a 'generic' application.
Ptr Node::CreateApplication ();
Applications would then be release their own sockets when they are destroyed.
I think the above model would mimick best what happens in real world. However,
if applications are only destroyed when a node is destroyed, or when the
programmer explicitly destroys them, their sockets will consequently also only
be destroyed when the application is explicitly destroyed or when the node is
destroyed. And so this ultimately reallistic API turns is reduced to my
proposed solution where sockets are destroyed explicitly or when the Node is
destroyed.
I am in favour of making the Application "middle man" optional (personally I
tend to never use it), and just allow sockets to be used directly.
>
> Your and Raj's proposal would err on the side of keeping sockets around, and I
> would be fine with that, because I think it would be less intuitive to a user
> to have sockets disappear without even an implicit close() ever having
> occurred. This is probably more relevant to consider with TCP but might be a
> problem with UDP if we ever model the case where the UDP socket didn't
> immediately send the datagram for some reason.
What if I create a OnOff application and forget to dispose it? It will keep on
sending traffic forever... same problem.
>
> there is the separate issue of whether ns-3 should do something when methods
> like Test::Run() are called before Simulation::Run() is called. Clearly, it
> will provide undefined behavior to use parts of the API outside of a running
> simulation context. Do we want to try to guard against this misuse somehow?
>
The logical solution would be:
1. Most APIs, like socket creation, fail an assertion when called and the
simulator not running;
2. It would force programmers to do the simulation initialization stuff in a
callback, scheduled with Simulator::ScheduleNow;
But I don't think that would help. The Simulation initialization function
would still create a local variable smart pointer, create the socket, and it
would still go out of scope and destroy the socket before time.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Fri Mar 28 09:00:17 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Fri, 28 Mar 2008 12:00:17 -0400
Subject: [Ns-bugs] [Bug 154] Attach sockets to nodes
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=154
raj.b at gatech.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #119|application/octet-stream |text/plain
mime type| |
Attachment #119 is|0 |1
patch| |
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Sat Mar 29 15:21:48 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Sat, 29 Mar 2008 18:21:48 -0400
Subject: [Ns-bugs] [Bug 155] New: "std::ostream & os" parameters not Python
friendly
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=155
Summary: "std::ostream & os" parameters not Python friendly
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P3
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
In the Python bindings I'm working on
(http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/), I am getting errors
like:
/home/gjc/projects/ns-3/ns-3-pybindgen-notracing/build/debug/ns3/csma-helper.h:68:
Warning: Parameter '::std::ostream & os' error (used in static void
ns3::CsmaHelper::EnableAscii(std::ostream & os, uint32_t nodeid, uint32_t
deviceid) [member function]): TypeLookupError('std::ostream &',)
So, std::ostream is not being wrapped, but the problem is that I am not
comfortable wrapping ostream in any form. The main problem is passing as
reference and lack of reference counting.
Conceptually, I could create my own PyOStream C++ subclass of ostream, which
would redirect writes to a python file-like object. But passing as reference
or pointer is dangerous because there is no guarantee that python object will
be kept alive for long. Python users should not have to worry about life cycle
issues that much, and they are not used to it.
If these NS-3 APIs operated on a reference counted object instead (e.g.
Ptr) things would be vastly safer to Python bindings... this
Ptr could have "std::ostream& GetStdOStream ()" method. That would be
fine as long as the std::ostream object life cycle management responsibility
shifts away from the Python bindings into the NS-3 core itself.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Mar 30 09:29:44 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Sun, 30 Mar 2008 12:29:44 -0400
Subject: [Ns-bugs] [Bug 155] "std::ostream & os" parameters not Python
friendly
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=155
------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-03-30 12:29 -------
(In reply to comment #0)
> In the Python bindings I'm working on
> (http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/), I am getting errors
> like:
>
> /home/gjc/projects/ns-3/ns-3-pybindgen-notracing/build/debug/ns3/csma-helper.h:68:
> Warning: Parameter '::std::ostream & os' error (used in static void
> ns3::CsmaHelper::EnableAscii(std::ostream & os, uint32_t nodeid, uint32_t
> deviceid) [member function]): TypeLookupError('std::ostream &',)
>
> So, std::ostream is not being wrapped, but the problem is that I am not
> comfortable wrapping ostream in any form. The main problem is passing as
> reference and lack of reference counting.
>
> Conceptually, I could create my own PyOStream C++ subclass of ostream, which
> would redirect writes to a python file-like object. But passing as reference
> or pointer is dangerous because there is no guarantee that python object will
> be kept alive for long. Python users should not have to worry about life cycle
> issues that much, and they are not used to it.
>
> If these NS-3 APIs operated on a reference counted object instead (e.g.
> Ptr) things would be vastly safer to Python bindings... this
> Ptr could have "std::ostream& GetStdOStream ()" method. That would be
> fine as long as the std::ostream object life cycle management responsibility
> shifts away from the Python bindings into the NS-3 core itself.
Adding such a Ptr class in the public API looks horribly painful from
c++ and would kill the whole purpose of these helper methods which is to make
life easy to c++ programmers, so, I would be really annoyed to have to do this.
It would be nice to find a good solution for python though: how does python
handle formatted io to stdout and files ? Can you point me to a not-too-painful
introduction ? How does boost::python handle this case ?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Mar 30 10:02:55 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Sun, 30 Mar 2008 13:02:55 -0400
Subject: [Ns-bugs] [Bug 155] "std::ostream & os" parameters not Python
friendly
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=155
------- Comment #2 from gjcarneiro at gmail.com 2008-03-30 13:02 -------
(In reply to comment #1)
[...]
> > If these NS-3 APIs operated on a reference counted object instead (e.g.
> > Ptr) things would be vastly safer to Python bindings... this
> > Ptr could have "std::ostream& GetStdOStream ()" method. That would be
> > fine as long as the std::ostream object life cycle management responsibility
> > shifts away from the Python bindings into the NS-3 core itself.
>
> Adding such a Ptr class in the public API looks horribly painful from
> c++ and would kill the whole purpose of these helper methods which is to make
> life easy to c++ programmers, so, I would be really annoyed to have to do this.
True, it would be kind of ugly for C++. But if the API is an additional API,
beside the existing one, with documentation stating it is only used for
language bindings, it should be ok.
>
> It would be nice to find a good solution for python though: how does python
> handle formatted io to stdout and files ? Can you point me to a not-too-painful
> introduction ? How does boost::python handle this case ?
In Python, formatted output (the print statement) works with file-like (using
the so called "duck typing") objects:
http://docs.python.org/lib/bltin-file-objects.html
It's not so much about formatted output; the issue is more about stream output
here. I could provide a std::ostream subclass to ns-3, which used
std::ostringstream internally, and then flushed the string on every newline to
the a python file-like object, and things would work fine (though not very
efficient). The thing I'm worried about is safe life cycle management.
I think a reasonable compromise would be to provide an API that received a file
name and created a file itself. It would not support stdin/stdout tracing, but
other than that would be pretty good, and would not have to go through any
python code, so would be more efficient.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Sun Mar 30 12:14:51 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Sun, 30 Mar 2008 15:14:51 -0400
Subject: [Ns-bugs] [Bug 156] New: Rename string.h header to nsstring.h to
ease gccxml parsing
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
Summary: Rename string.h header to nsstring.h to ease gccxml
parsing
Product: ns-3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P3
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
In the gjc/ns-3-pybindgen-notracing branch I had to enable a workaround:
http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/rev/1431a85ce21b
to avoid the following GCC-XML bug:
http://www.gccxml.org/Bug/view.php?id=6682
The bug is due to string.h being the same name as a standard include. The
workaround involves forcing GCC-XML to parse this include before all others.
It seems to work, though it's kind of ugly. Maybe it's better to rename
string.h to nsstring.h, like we have nstime.h instead of time.h?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 31 13:03:38 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 31 Mar 2008 16:03:38 -0400
Subject: [Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease
gccxml parsing
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
------- Comment #1 from mathieu.lacage at sophia.inria.fr 2008-03-31 16:03 -------
(In reply to comment #0)
> In the gjc/ns-3-pybindgen-notracing branch I had to enable a workaround:
>
> http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/rev/1431a85ce21b
>
> to avoid the following GCC-XML bug:
>
> http://www.gccxml.org/Bug/view.php?id=6682
>
> The bug is due to string.h being the same name as a standard include. The
> workaround involves forcing GCC-XML to parse this include before all others.
>
> It seems to work, though it's kind of ugly. Maybe it's better to rename
> string.h to nsstring.h, like we have nstime.h instead of time.h?
Well, I would much rather have nstime.h renamed to time.h since I don't think
there are any technical reasons for this nstime.h name. I mean, next time, it
will be socket.h or some other header: the race to make sure that we do not
have similarly-named headers (as system headers) is sure to be lost one day or
another.
Could it be that a "simpler" fix would be to simply use the ns3/foo.h notation
for every public header ? I know that this will trigger much more fallout but
it might be a good change from the point of view of the user, if only because
they won't have to try to understand the difference between #include "foo.h"
and #include "ns3/foo.h".
If we did that, renaming nstime.h to time.h would be the way to go I think.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 31 14:24:25 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 31 Mar 2008 17:24:25 -0400
Subject: [Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease
gccxml parsing
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
------- Comment #2 from gjcarneiro at gmail.com 2008-03-31 17:24 -------
(In reply to comment #1)
> (In reply to comment #0)
> > In the gjc/ns-3-pybindgen-notracing branch I had to enable a workaround:
> >
> > http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/rev/1431a85ce21b
> >
> > to avoid the following GCC-XML bug:
> >
> > http://www.gccxml.org/Bug/view.php?id=6682
> >
> > The bug is due to string.h being the same name as a standard include. The
> > workaround involves forcing GCC-XML to parse this include before all others.
> >
> > It seems to work, though it's kind of ugly. Maybe it's better to rename
> > string.h to nsstring.h, like we have nstime.h instead of time.h?
>
> Well, I would much rather have nstime.h renamed to time.h since I don't think
> there are any technical reasons for this nstime.h name. I mean, next time, it
> will be socket.h or some other header: the race to make sure that we do not
> have similarly-named headers (as system headers) is sure to be lost one day or
> another.
>
> Could it be that a "simpler" fix would be to simply use the ns3/foo.h notation
> for every public header ?
Yes, it's possible it will fix. I myself am generating a 'everything.h' header
file for feeding into GCC-XML that includes all headers, and I already changed
it to use #include "ns3/foo.h" instead of #include "foo.h". Unfortunately that
alone wasn't enough because some other ns3 header was being included first
which included "string.h" which got GCC-XML confused. But maybe if _all_ ns3
headers use the ns3/ things may get fixed without forcing a certain order of
inclusion.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 31 14:30:36 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 31 Mar 2008 17:30:36 -0400
Subject: [Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease
gccxml parsing
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
------- Comment #3 from mathieu.lacage at sophia.inria.fr 2008-03-31 17:30 -------
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > In the gjc/ns-3-pybindgen-notracing branch I had to enable a workaround:
> > >
> > > http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/rev/1431a85ce21b
> > >
> > > to avoid the following GCC-XML bug:
> > >
> > > http://www.gccxml.org/Bug/view.php?id=6682
> > >
> > > The bug is due to string.h being the same name as a standard include. The
> > > workaround involves forcing GCC-XML to parse this include before all others.
> > >
> > > It seems to work, though it's kind of ugly. Maybe it's better to rename
> > > string.h to nsstring.h, like we have nstime.h instead of time.h?
> >
> > Well, I would much rather have nstime.h renamed to time.h since I don't think
> > there are any technical reasons for this nstime.h name. I mean, next time, it
> > will be socket.h or some other header: the race to make sure that we do not
> > have similarly-named headers (as system headers) is sure to be lost one day or
> > another.
> >
> > Could it be that a "simpler" fix would be to simply use the ns3/foo.h notation
> > for every public header ?
>
> Yes, it's possible it will fix. I myself am generating a 'everything.h' header
> file for feeding into GCC-XML that includes all headers, and I already changed
> it to use #include "ns3/foo.h" instead of #include "foo.h". Unfortunately that
> alone wasn't enough because some other ns3 header was being included first
> which included "string.h" which got GCC-XML confused. But maybe if _all_ ns3
> headers use the ns3/ things may get fixed without forcing a certain order of
> inclusion.
>
I am not sure that my suggestion would be so much better from the POV of the
user so, if you could try pre-processing all these headers to do the
above-mentioned replacement just for gccxml, that might be really cool. I know
that I am pushing more pain on you here.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 31 14:51:10 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 31 Mar 2008 17:51:10 -0400
Subject: [Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease
gccxml parsing
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
------- Comment #4 from gjcarneiro at gmail.com 2008-03-31 17:51 -------
(In reply to comment #3)
[...]
> I am not sure that my suggestion would be so much better from the POV of the
> user so, if you could try pre-processing all these headers to do the
> above-mentioned replacement just for gccxml, that might be really cool. I know
> that I am pushing more pain on you here.
Preprocessing is a hack. I was probing for an elegant solution. I already
have my own hack and it's working, so...
Just close the bug if you think it's not worth to fix. Python bindings will be
fine, I guess.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 31 14:58:02 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 31 Mar 2008 17:58:02 -0400
Subject: [Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease
gccxml parsing
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
mathieu.lacage at sophia.inria.fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
From bugzilla-daemon at nsnam-www.ece.gatech.edu Mon Mar 31 14:57:50 2008
From: bugzilla-daemon at nsnam-www.ece.gatech.edu (bugzilla-daemon@nsnam-www.ece.gatech.edu)
Date: Mon, 31 Mar 2008 17:57:50 -0400
Subject: [Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease
gccxml parsing
In-Reply-To:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=156
------- Comment #5 from mathieu.lacage at sophia.inria.fr 2008-03-31 17:57 -------
(In reply to comment #4)
> (In reply to comment #3)
> [...]
> > I am not sure that my suggestion would be so much better from the POV of the
> > user so, if you could try pre-processing all these headers to do the
> > above-mentioned replacement just for gccxml, that might be really cool. I know
> > that I am pushing more pain on you here.
>
> Preprocessing is a hack. I was probing for an elegant solution. I already
> have my own hack and it's working, so...
If it is working for you, then, let's ignore the issue.
thanks !
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.