> -----Original Message----- > From: Matt Garman [mailto:matthew.garman@xxxxxxxxx] > Sent: Wednesday, April 08, 2009 11:28 AM > To: Jeff Haran > Cc: Lawrence MacIntyre; linux-net@xxxxxxxxxxxxxxx > Subject: Re: multicast: same port, different IP address? > > > Just my humble opinion here, but to the extent that IP > addresses are used to identify a host (or in this case a set > of hosts) that should receive messages and transport layer > port numbers are used to identify applications (or services), > if it was me I'd probably encapsulate the application layer > messages in UDP and use UDP port numbers to delineate message > types or groups of message types. UDP adds little overhead to > the protocol (8 byte header, if I am not mistaken) and the > standard sockets API provides a straightforward way to demux > the incoming traffic to the interested applications. How that > would be best done obviously depends upon the details of the > application. > > The first part of your comment isn't really what we want to do: each > host+application pair gets its own address. > > But anyway, your suggestion about using raw UDP makes me wonder where > the distinction between multicast and UDP in the 232.0.0.0/6 (i.e. > multicast IPs) lies... > > Maybe I don't understand you correctly, but I think UDP would require > quite a paradigm shift for us. E.g., say we have HostA as a producer > of messages. Right now, HostA's programs just push messages out via > multicast; any number of hosts can become a consumer for this data. > If we switched to UDP, wouldn't HostA need to explicitly send() or > sendto() each and every receiver? I haven't tried this personally, but I would assume that you'd just sendto() the multicast address specified in the struct sockaddr *dest_addr. > > Or were you suggesting that the consumers all pull the data from > HostA, and HostA acts like e.g. a webserver? All I am suggesting is that for portability and extensibility, you might want view it such that the UDP port numbers are what identify the receivers of messages from the application perspective and the packaging of these messages in IPv4 packets sent to multicast addresses is just an optimization to reduce the incoming load on hosts that don't need to see those messages. Someday you might want to run this over something else like IPv6 (never say "never", 8^). If the application semantics are tied to the underlying network protocol, IPv4, that will be difficult. Jeff Haran -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
