Properly relay ns3 callbacks

[teto]

First evoked in https://groups.google.com/forum/#!topic/ns-3-users/tzG5TmweQp0

DCE overrides socket callbacks, for instance in UnixStreamSocketFd:

  m_socket->SetAcceptCallback (MakeCallback (&UnixStreamSocketFd::ConnectionRequest, this),
                               MakeCallback (&UnixStreamSocketFd::ConnectionCreated, this));
  m_socket->SetConnectCallback (MakeCallback (&UnixStreamSocketFd::ConnectionSuccess, this),
                                MakeCallback (&UnixStreamSocketFd::ConnectionError, this));
  m_socket->SetCloseCallbacks  (MakeCallback (&UnixStreamSocketFd::CloseSuccess, this),
                                MakeCallback (&UnixStreamSocketFd::CloseError, this));
  m_state = (connected) ? CONNECTED : CREATED;

Thus how can the user script be warned when its ns3 socket got connected ?

I used a workaround here and added an extra callback but this does not feel clean: https://github.com/teto/ns-3-dce/blob/mptcp_tests/model/unix-stream-socket-fd.cc#L475

[thehajime]

I was wondering what you want to use the trace in your ns-3 script. to track the connection for logging purpose ?

[teto]

For instance in this custom example that allows hybrid test between linux/ns3 mptcp stacks:
https://github.com/teto/ns-3-dce/blob/mptcp_tests/example/dce-iperf-mptcp-mixed.cc#L39
I need to know when the connection is established to be able to initiate new subflow (call to ConnectNewSubflow).

[thehajime]

I think this additional callback is fine if it is well documented with your concrete example (i.e., initiating subflow connection with a trigger). it would be great if you have another PR.

[teto]

I don't really like how I did it. I put this on hold until I get a better idea or when mptcp stuff advance on the ns3 side.

[thehajime]

okay. please close this issue if you're fine.

[teto]

What I meant is that it's a real problem but that my current solution is not clean enough: the user should not have to map to different callbacks depending on if it's an ns3 stack or a DCE one.
I could only think of 2 solutions both invloving changes in ns3:

• save the original callbacks and rebind them once DCE finished its job.
• or let ns3 manage several callbacks (in form of a TraceSource on tcp state for instance).

[thehajime]

do you agree to postpone this fix after dce-1.8 ? if yes, keep this issue open.

[teto]

yeah fix is not straightforward. I will try to come up with sthg based on
tracing Tcp state.

2016-02-03 0:51 GMT+01:00 Hajime Tazaki notifications@github.com:

do you agree to postpone this fix after dce-1.8 ? if yes, keep this issue
open.

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[thehajime]

ack.