Multicast and callback functions

119 views
Skip to first unread message

Steve Marotta

unread,
Jun 24, 2011, 4:34:43 PM6/24/11
to ns-3-users
Hello again. I've got yet another multicast question. Here goes.

I've got my multicast source all set up, and if I do this...

TypeId tid = TypeId::LookupByName("ns3::UdpSocketFactory");
tx_socket = Socket::CreateSocket(GetNode(), tid);
tx_socket->SetAllowBroadcast(true);
tx_socket->Bind();
tx_socket->Connect(InetSocketAddress(Ipv4Address("226.1.2.3"),
42));
Ptr<Packet> p = Create<Packet>(1024);
tx_socket->Send(p);

...it works. Multicast, packets flitting about the network with
reckless abandon, heading right where they're supposed to go. If, on
the other hand, I do this...

TypeId tid = TypeId::LookupByName("ns3::UdpSocketFactory");
tx_socket = Socket::CreateSocket(GetNode(), tid);
tx_socket->SetAllowBroadcast(true);
tx_socket-
>SetConnectCallback(MakeCallback(&BftClient::HandleSocketConnect,
this), MakeCallback(&BftClient::HandleSocketConnectFailed, this));
tx_socket->Bind();
tx_socket->Connect(InetSocketAddress(Ipv4Address("226.1.2.3"),
42));

...and my "HandleSocketConnect" function does the following...

const char* msg = "REQUEST";
Ptr<Packet> p = Create<Packet>(1024);
tx_socket->Send(p);

...it doesn't work at all. No multicast packets get sent. The
HandleSocketConnect callback definitely gets called because I have
logging statements there that get called, and my client app tries to
send data on that socket, but nothing actually gets sent. What happens
when I call Send(..) right after I make the Connect(..) call that
stops happening when I'm in the callback?

~ Steve

Steve Marotta

unread,
Jun 27, 2011, 3:29:31 PM6/27/11
to ns-3-users
I found the problem, and I think it's a bug in the current version of
ns-3. Here is the udp-socket-impl.cc "Connect" function:

int
UdpSocketImpl::Connect(const Address & address)
{
NS_LOG_FUNCTION (this << address);
InetSocketAddress transport = InetSocketAddress::ConvertFrom
(address);
m_defaultAddress = transport.GetIpv4 ();
m_defaultPort = transport.GetPort ();
NotifyConnectionSucceeded ();
m_connected = true;

return 0;
}

Notice how "NotifyConnectionSucceeded ();" is being called before
m_connected is set to true. So what was happening was that the
connection handler callback was being called before m_connected got
set, and I was trying to send data on a socket that wasn't considered
to be connected yet. When I switch "NotifyConnection..." and
"m_connected...", my code works as expected.

I realize that UDP is connectionless, so using connection-oriented
callbacks may seem unnecessary. My code originally used TCP, but I
switched to UDP to leverage multicasting and I left much of the
original code in place. I would agree that using the callbacks is
unnecessary, but be that as it may, the API still supports their use.
In fact, the API supports setting lots of connection-oriented event
handlers on connectionless protocols, and most of these event handlers
simply never get called. However, in this case, the outgoing
connection handler was being called. So either the event handler
shouldn't get called at all, or it should get called once m_connected
is set to true so it will behave properly.

~ Steve

Tom Henderson

unread,
Jun 28, 2011, 2:16:19 AM6/28/11
to ns-3-...@googlegroups.com
On 06/27/2011 12:29 PM, Steve Marotta wrote:
> I found the problem, and I think it's a bug in the current version of
> ns-3. Here is the udp-socket-impl.cc "Connect" function:
>
> int
> UdpSocketImpl::Connect(const Address& address)

I agree with you; filed in bug 1201 and should be checked in shortly.

- Tom

Reply all
Reply to author
Forward
0 new messages