Mail Archives: cygwin/1997/03/20/00:12:55
Interesting trial you have there. I ran your code as-is on
an SGI (which supports multicast send/receive) and didn't
manage to get multicasting. Finally, I got a line fixed and
got it running on SGI doing multicast sending/receiving.
Later, I got it compiled on Win95 and tried on the
combination SGI-receiving/Win95-sending and got the right result.
Unfortunately, Win95 doesn't allow me to emulate being on
a multicast network (using Control-Panel to set another
IP Adapter to 224.x.x.x address), so I can't try the reverse
combination (Win95-receiving/SGI-sending).
Basically, the change is:
localAddr.sin_addr.s_addr = *((long *) myHostent->h_addr_list[0]);
to
localAddr.sin_addr.s_addr = inet_addr(gMyMultiIp);
The idea is that you need to bind to the multicasting
network address, logically as if this host also has a
local address at this multicasting address. The idea
is much like "localhost" (127.0.0.1) being the address
of the local machine. So if your machine+OS+network card
supports multicasting, then the Class D networks starting
from "224.0.0.0" are also logically the address of the
local machine.
The operation is not so clear if you first bind a socket
to a unicast IP address (the one returned by gethostbyname())
and subsequently add multicast membership to a unicast-recipient
socket using setsockopt(... IP_ADD_MEMBERSHIP...)
(by which time bind() would have already named a socket with
a unicast address. On the other hand, setsockopt() could
undo the semantics of bind() on seeing IP_ADD_MEMBERSHIP
so that the socket can be a recipient of a multicast network.
This is implementation dependent [It's not that clean IMHO].)
Chin Chee-Kai (Last, First)
Internet Email-ID: cheekai AT gen DOT co DOT jp
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -