the socket callback function dose not work

[Hardwood Bao]

Hey, everyone.

I have met a problem that i set the socket close callback to function ConnectionClosed().

But it doesn't invoke this function when the socket is closed.

m_socket->Close ();

I don't know how to solve it and where am i wrong? I am really appreciate your help.

m_socket->Bind ();

m_sockStart(m_socket);

m_socket->Connect (peer);

m_socket->ShutdownRecv ();

m_socket->SetConnectCallback (

    MakeCallback (&BulkSendApplication::ConnectionSucceeded, this),

    MakeCallback (&BulkSendApplication::ConnectionFailed, this));

m_socket->SetCloseCallbacks (

    MakeCallback (&BulkSendApplication::ConnectionClosed, this),

    MakeCallback (&BulkSendApplication::ConnectionClosed, this));

m_socket->SetSendCallback (

    MakeCallback (&tBulkSendApplication::DataSend, this));

[Tommaso Pecorella]

Hi,

I'm assuming that you're using TCP (ConnectionClosed wouldn't make sense for UDP).

The receiving socket should re-connect the callbacks after the connection is established. The socket starting the connection should be fine as you did.

I'm puzzled... are you sure you're using TCP ?

T.

[Hardwood Bao]

Hey, Tommaso

This is the modified bulk-send application. when the application finished. The sink applicant will involve the HandlePeerClose(Ptr<Socket> socket).

but the bulk-send application will not invoke the ConnectionClosed() function when it run m_socket->Close ();

The protocol is "ns3::TcpSocketFactory".

I am not sure where i am wrong. 

在 2016年5月18日星期三 UTC+8上午7:09:18，Tommaso Pecorella写道：

[Nat P]

Before closing the socket all the data should be transmitted (it can take a while). It has a corollary: if you set to 0 the maxBytes, the connection will never close.

Nat

[Hardwood Bao]

Hey, natale.

i have given a maxBytes.  As what you mean, the m_socket->Close () should not been executed. as the data will be transmitted for some time.

 int actual = m_socket->Send (packet);

  // Check if time to close (all sent)

  if (m_totBytes == m_maxBytes && m_connected)

    {

      m_socket->Close ();

      NS_LOG_LOGIC("close the socket");

      m_connected = false;

    }

the code is in the default bulk-send application.cc. 

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/Vr6ScPOyhtQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Hardwood Bao]

Hey, all

this is the trace output file. is there any problem here?

[Nat P]

Maybe I was not clear in my first instance. Even if you call socket->Close, the callback associated to the close event is not called shortly after, or at the same time: the data in the Tcp buffer should be (i) sent (ii) acknowledged. Only if (i) and (ii) are achieved, the Close callback is invoked; if this does not happen, so it's a bug inside the Tcp socket. You can debug the code, by searching the point on which the callback is invoked, and then discovering (by prints or through gdb) why it is not invoked.

Nat

[Hardwood Bao]

Hey, Nat

This is my test script, simply modified from fifth.cc. I still don't know where the problem.

would you convenient to run this script ./waf --run scratch/fifth.

I am really appreciate your help.

[Nat P]

No, I will not run and debug your script for you, you have enough informations to start work yourself and ask more precise questions, which would be happily answered.

Nat

[Hardwood Bao]

Hey, Nat.

Thanks for your reply. I am still working on my problem.

by hardwood.

[Tommaso Pecorella]

@Hardwood: upgrade your ns-3. Like... now. How do I know ? Because your AddTraceSource uses an obsolete syntax.

@Nat: yes, it's a bug.

If you invoke TcpSocketBase::Close while the buffer is full, and if you didn't set m_closeOnEmpty to false, then the effective close should be deferred to when the buffer is empty. 

However, when the buffer is empty for real, the close doesn't happens.

Please note that his is a known bug: 

"Bug 1167 - IPV4 TCP Socket Deferring CLOSE forever." - https://www.nsnam.org/bugzilla/show_bug.cgi?id=1167

T.

[Hardwood Bao]

Hey, Tommaso.

Thanks for your help. I will upgrade my ns3 version.

By hardwood.

[Nat P]

Il giorno mercoledì 18 maggio 2016 15:51:36 UTC+2, Tommaso Pecorella ha scritto:

@Nat: yes, it's a bug.

If you invoke TcpSocketBase::Close while the buffer is full, and if you didn't set m_closeOnEmpty to false, then the effective close should be deferred to when the buffer is empty. 

However, when the buffer is empty for real, the close doesn't happens.

Please note that his is a known bug: 

"Bug 1167 - IPV4 TCP Socket Deferring CLOSE forever." - https://www.nsnam.org/bugzilla/show_bug.cgi?id=1167

Hi Tommaso,

do you have a test case for this ? The one provided in the bug tracker is working fine on ns-3-dev (don't know when that bug was fixed)

Nat

[Tommaso Pecorella]

Hi Nat,

Hardwood's code is a valid use-case. You can "safely" use his code (I guess it will work even with the normal BulkSend).

If you activate TcpSocketBase logs, you'll notice that node 1 hits CloseAndNotify, but node 0 doesn't (node 1 is the sink).

T.

[Hardwood Bao]

Hey, Tommaso:

sorry to disturb you again. i have used the newest version of NS3 and run the scripts, but they have the same problem.

And i activate  theTcpSocketBase logs, that node 1 hits CloseAndNotify, but node 0 doesn't (node 1 is the sink).

I am really confused where is the problem.

by hardwood.

2016-05-20 12:34 GMT+08:00 Hardwood Bao <hardwo...@gmail.com>:

hey, Tommaso:

If i want to solve the problem ,the only way is to upgrade the vision? and no patch to fixed the problem? Because i am using the version 3.21 and with the corresponding version of DCE, it's difficult for me to upgrade both of the NS3 and DCE. 

by hardwood.

--

[Tommaso Pecorella]

Hi,

sorry if I didn't update the thread.

Please check the bug status and its comments for a full explanation of the behaviour. To make the long story short, the "missing" socket close callback will be called, as per standard, after 4 minutes.

Cheers,

T.

[Hardwood Bao]

Hey, Tommaso,

Thans for your help.

"the "missing" socket close callback will be called, as per standard, after 4 minutes." makes me awake.

The simulation time is too short in the fifth.cc, and can not wait for the execution of the callback function.

And i want to calculate the flow completion time for the transmitter, it is from the time the first packet has been sent to the correct acknowledgement of the last packet.

I wonder that the setting the MaxSegLifetime=0 would be right?

by Hardwood.

[Tommaso Pecorella]

Hi,

it should do in this case and with this ns-3 version. At the moment MaxSegLifetime seems to be only used to delay the Close, but I can not be 100% sure that this will never change in the future.

T.