Bugzilla – Bug 458
socket attributes not hooked into the config namespace
Last modified: 2009-03-23 14:41:48 EDT
You need to log in before you can comment on or make changes to this bug.
There seems to be no way to access socket attributes from the config namespace. Example usecase: --- a/examples/tcp-large-transfer.cc Sat Dec 27 13:58:12 2008 -0800 +++ b/examples/tcp-large-transfer.cc Fri Jan 02 09:36:00 2009 -0800 @@ -46,6 +46,11 @@ using namespace ns3; NS_LOG_COMPONENT_DEFINE ("TcpLargeTransfer"); +static void CwndTracer (uint32_t oldval, uint32_t newval) +{ + std::cout << "Moving cwnd from " << oldval << " to " << newval << std::endl; +} + // The number of bytes to send in this simulation. static uint32_t txBytes = 2000000; @@ -143,6 +148,7 @@ int main (int argc, char *argv[]) Ptr<Socket> localSocket = Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ()); localSocket->Bind (); + Config::ConnectWithoutContext ("/NodeList/0/$ns3::TcpL4Protocol/SocketList/0/CongestionWindow", MakeCallback (&CwndTracer)); // ...and schedule the sending "Application"; This is similar to what an // ns3::Application subclass would do internally.
Created an attachment (id=345) [details] initial patch to add support for TcpSocketImpl sockets This patch is an initial stab at solving this issue. It does not exit cleanly due to object disposal issues that need further work, but provides code that will cause the use case outlined in the previous comment to print out tracing output. it relies on the same strategy used in NodeList and DeviceList to use an ObjectVector to index the sockets in the config namespace. However, there needs to be a place to insert this vector into the existing objects. TcpL4Protocol seems like the natural choice, but it is not aggregated to the Node. So, the attached patch aggregates it (which may be the root of the simulation not freeing memory cleanly at the end). So, I think we need to converge on the right general approach for this (are we adding to TcpL4Protocol or some other object), clean up the memory management issue, and then replicate across Nsc and Udp sockets as well.
(In reply to comment #1) > Created an attachment (id=345) [details] [details] > initial patch to add support for TcpSocketImpl sockets > > This patch is an initial stab at solving this issue. It does not exit cleanly > due to object disposal issues that need further work, but provides code that > will cause the use case outlined in the previous comment to print out tracing > output. > > it relies on the same strategy used in NodeList and DeviceList to use an > ObjectVector to index the sockets in the config namespace. However, there > needs to be a place to insert this vector into the existing objects. > TcpL4Protocol seems like the natural choice, but it is not aggregated to the > Node. So, the attached patch aggregates it (which may be the root of the > simulation not freeing memory cleanly at the end). yes, this is the cause of the problem: you have a cyclic dependency and you need to break it by editing carefully the ::DoDispose methods of various objects. It is going to be tricky and this is why the tcp object was not there in the first place. > > So, I think we need to converge on the right general approach for this (are we > adding to TcpL4Protocol or some other object), clean up the memory management > issue, and then replicate across Nsc and Udp sockets as well. >
Created an attachment (id=399) [details] Working patch to make Tcp, NscTcp, Udp, Icmp Attributes accessible
(In reply to comment #3) > Created an attachment (id=399) [details] [details] > Working patch to make Tcp, NscTcp, Udp, Icmp Attributes accessible > I assume that you have verified that all the Dispose methods are still called when needed so, this patch looks good to me. I am impressed that it looks that simple :) yay !
5854cddf4493