1

I have two processes running on my box as follows:

  1. Normal client program sending to multicast 224.1.2.3:8000
  2. "Router" process

The router process is joined to two multicast groups:

  1. 224.1.2.3:8000
  2. 224.1.2.4:8001

The idea behind the router is simple, when traffic comes in from either multicast group, simply forward it to the other multicast group. In order to do this, I turn off multicast loopback on the router process so that it doesn't "hear what it sends" (as is normal with multicasting.)

The idea is complicated by the fact that there is a "normal" process running on the same machine. With multicast loopback turned off, the router process doesn't see the traffic that originates from the normal process, and thus the normal process' traffic cannot be routed properly.

I could turn on multicast loopback in the router process, but I dont know how to identify the process that sent the packets. Without identifying the packet's source process, I get stuck in a loop:

receive_packet from 224.1.2.3:8000
--- Forward packet to 224.1.2.4:8001 ---
<< Forwarding causes a receive packet >>

receive_packet from 224.1.2.4:8001
--- Forward packet to 224.1.2.3:8000 ---
<< Forwarding causes a receive packet >>

Unfortunately I can't simply encode that information into the the packets that are sent.

Any ideas? All help is greatly appreciated.

-- Dan

Edit:

My coworker suggested implementing a third multicast group specifically for the normal client to send stuff to the router. In this scenario the normal client would listen on 224.1.2.3:8000 and send across 224.1.2.3:8002. The router would also listen on 8002 and forward it appropriately. It would just never send anything across 8002 (ie. it would treat 8002 as a one way pipe from the normal client.)

This would actually work for many cases, but unfortunately the underlying software requires two way communication on the multicast socket during a number of common operations. So that's a no go.

debracey
  • 6,517
  • 1
  • 30
  • 56
  • I'm not too familiar with multicast but could the sending processes be identified by source port? Presumably the processes would share the same source IP but different port? – Dave Rager Mar 17 '11 at 20:30
  • Unfortunately with multicasting everyone must use the same IP/port combinations when sending and receiving. – debracey Mar 17 '11 at 20:49

2 Answers2

2

You could have the client that is on the same machine as the router bind to a virtual interface so that its source IP would be different from that of the router.

Community
  • 1
  • 1
Jeff
  • 1,807
  • 1
  • 15
  • 17
0

OK so here's what I had to do to get it working:

Jeff's suggestion got me thinking about using two virtual interfaces (one for each program.) Unfortunately I couldn't figure out a way to send data between the two if I gave each interface a regular IP from a restricted block (ie. 192.168.1.100 & .101.)

Then I thought about giving each interface an IP from the loopback range (127.*). Unfortunately, Windows doesn't allow to assign IPs in the loopback space -- it pops up an error about 127 being reserved as soon as you type it in the IP address block.

So I decided to just manually bind to a specified IP in my program. C# allows you to bind to 127.* addresses, so I ended up using 127.0.0.2 and 127.0.0.3 -- giving a unique to each process.

This didn't solve the multicast part of the problem -- the router process couldn't see the regular process' traffic. So - I had to write a UDP unicast module for the two to talk (I could have used TCP, but the app is framed up to use UDP.)

That ultimately did the trick.

+1 to Jeff's post for pointing me in the right direction

-- Dan

debracey
  • 6,517
  • 1
  • 30
  • 56