IPPROTO_RM blocks during accept call

Question

This question is similar to https://stackoverflow.com/questions/11650328/using-reliable-multicast-pragmatic-general-multicast-not-returning-from-accept, but my code is slightly different from its, so it may result in a different answer.

I am attempting to get a reliable-multicast server/client proof of concept setup.

The solution itself is a server/client connection. The client connects to the server via TCP/IP. The server then opens up a reliable multicast socket for the client to listen on. The client sends messages via TCP, and the server echoes it back via IPPROTO_RM. The end goal is to have many clients connected to the server, all receiving every echoed message.

The example code is based off of this page.

I have set up my RM sockets similarly (see listings below). The TCP sockets are working fine. The problem is in the RM sockets. The server opens up the multicast socket, then binds and connects to the multicast address properly. The client, however, listens correctly, but the call to accept blocks forever.

Both client and server processes are running on the same host.

I have checked, and Multicasting support is installed on the host (Server 2008).

Update: I've noticed that sometimes the accept will return if I send some data down the socket from the sender's side first. This is not ideal, nor is it reliable.

Update: The signs are pointing to the switch. Seems like a little hub won't cut it. We had an hilarious incident which resulted in lost comms for the whole building.

Listings

Server creates and connects Multicast sender

short
   Port = 0;
const char
   *Address = "234.5.6.7";

SOCKET
   RMSocket;

SOCKADDR_IN 
   LocalAddr, 
   SessionAddr;

RMSocket = socket(AF_INET, SOCK_RDM, IPPROTO_RM);


if (RMSocket == INVALID_SOCKET)
   {
   return Failed;
   }

LocalAddr.sin_family = AF_INET;
LocalAddr.sin_port = htons(0);
LocalAddr.sin_addr.s_addr = htonl(INADDR_ANY);

if ( bind( RMSocket, (SOCKADDR*)&LocalAddr, sizeof(LocalAddr)) == SOCKET_ERROR )
   {
   return Failed;
   }

SessionAddr.sin_family = AF_INET;
SessionAddr.sin_port = htons( Port );
SessionAddr.sin_addr.s_addr = inet_addr( Address );

if ( connect( RMSocket, (SOCKADDR*)&SessionAddr, sizeof(SessionAddr)) == SOCKET_ERROR )
   {
   return Failed;
   }

return Success;

Client creates and accepts Multicast reader

short
   Port = 0;
const char
   *Address = "234.5.6.7";

SOCKADDR_IN 
   LocalAddr;
SOCKET
   RMListener,
   RMSocket;


RMListener = socket( AF_INET, SOCK_RDM, IPPROTO_RM );

if ( RMListener == INVALID_SOCKET ) 
   {
   return Failed;
   }


LocalAddr.sin_family = AF_INET;
LocalAddr.sin_port = htons( Port );
LocalAddr.sin_addr.s_addr = inet_addr( Address );


if ( bind( RMListener, (SOCKADDR*)&LocalAddr, sizeof(LocalAddr) ) )
   {
   return Failed;
   }


if ( listen( RMListener, SOMAXCONN ) )
   {
   return Failed;
   }

// BLOCKS HERE
RMSocket = accept( RMListener, NULL, NULL);



if ( RMSocket == INVALID_SOCKET )
   {
   return Failed;
   }

return Success;

Gull_Code · Answer 1 · 2013-03-20T09:24:02.970

1

Do you have MSMQ (microsoft message queuing) installed ? it is required for IPPROTO_RM to work on Ms based computers. Plus it will only work for Windows version >= Xp||2003

Edit:I saw that you already checked it.

edited Mar 20 '13 at 09:24

answered Mar 20 '13 at 09:14

Gull_Code

115
1
5

That's right, I did indeed check it. MSMQ is installed and so is Multicasting support. all servers are Windows 2008. – Anthony Mar 20 '13 at 10:30
Yea the problem is that the receiver performs accept() syncronous and does not return untill the first data was received.. I am currently searching for a workaround to this design, perhaps AcceptEx() or something. – RobertH Jan 16 '14 at 13:51
@RobertH I would seriously take a look at the specs for your switch. Even though I was only sending/receiving on the local host, it seems like network packets were still being sent to the switch with the multicast flag on. This flooded the whole building (about 1000 PCs) with multicast packets destined for their origin. Funny, but not really what I was after. – Anthony Jan 17 '14 at 21:55
@anthony-arnold: There is nothing wrong with the behavior of the switch, the expected is behavior. Even though the multicast server and client processes are running on the same host, the multicast server data is sent out out the host, this is according to the multicast protocol. There could be multicast receivers outside of your subnet/building, hence the reason for the multicast data to be sent out of the host. And when a switch receives the multicast traffic, it will flood it or drop it depending on the configuration. Most of the switches flood. – leodotcloud Jan 18 '14 at 18:22
@MuraliPaluru Yes, the point being that the switch needs to be configured in order to handle the PGM traffic without flooding, and it wouldn't be unusual for a switch to not be configurable to that level. – Anthony Jan 20 '14 at 01:03

IPPROTO_RM blocks during accept call

Listings

Server creates and connects Multicast sender

Client creates and accepts Multicast reader

1 Answers1