Bug 1824 - L4 protocol sockets should support BindToNetDevice over IPv6
L4 protocol sockets should support BindToNetDevice over IPv6
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: internet
ns-3-dev
All All
: P5 enhancement
Assigned To: Tommaso Pecorella
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-05 08:17 EST by Tommaso Pecorella
Modified: 2014-09-12 14:52 EDT (History)
2 users (show)

See Also:


Attachments
patch (2.59 KB, patch)
2014-01-05 12:32 EST, Tommaso Pecorella
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tommaso Pecorella 2014-01-05 08:17:53 EST
The problem is in UdpSocketImpl::BindToNetDevice and TcpSocketBase::BindToNetDevice.

In both methods only the v4 methods are initialised, while also the v6 endpoint should be initialised (v6 endpoints have a BindToNetDevice).
Comment 1 Tommaso Pecorella 2014-01-05 12:32:46 EST
Created attachment 1752 [details]
patch

The patch add the required BindToNetDevice calls to the IPv6Endpoint inside TCP and UDP sockets.

The only doubt I have is: if the socket wasn't already bound (normal Bind), BindToNetDevice will do it for the user.

BUT it will open *two* endpoints, v4 and v6.

Since we do have separate Bind and Bind6, and they open just the endpoint they need, maybe it's not a good idea to open another one just because we can.

SO, the BindToNetDevice "logical" thing would be: do nothing or raise an assert if the EndPoint is not already bound by a previous Bind.
This also prevents the idiotic error: call BindToNetDevice() and, after call Bind() (it's causing a a memory leak).

Opinions ?
Comment 2 Tom Henderson 2014-09-12 12:43:31 EDT
I'm OK with this also, as long as there is some documentation added about the expected sequence of Bind() calls supported.
Comment 3 Tommaso Pecorella 2014-09-12 14:52:54 EDT
added in changeset:   10933:7442f5603ef4