RE: multicast: same port, different IP address?

From: Jeff Haran
Date: Wed Apr 08 2009 - 13:57:28 EST

> -----Original Message-----
> From: linux-net-owner@xxxxxxxxxxxxxxx
> [mailto:linux-net-owner@xxxxxxxxxxxxxxx] On Behalf Of Matt Garman
> Sent: Wednesday, April 08, 2009 10:42 AM
> To: Lawrence MacIntyre
> Cc: linux-net@xxxxxxxxxxxxxxx
> Subject: Re: multicast: same port, different IP address?
> On Wed, Apr 8, 2009 at 11:52 AM, Lawrence MacIntyre
> <macintyrelp@xxxxxxxx> wrote:
> > If all nodes need all of those messages, then you should
> probably use one
> > multicast address and multiple ports.  This will reduce the routing
> > overhead.  However, if different nodes need different
> messages, then you
> > would increase the network overhead by sending all messages
> to all nodes.
> The latter case is what we need. We are basically already using the
> former, but since all messages aren't required at all sites, we're
> trying to reduce network load. (We have lots of message types and
> very high message volume.)
> >  In that case, you should use different multicast addresses
> for each message
> > type.  In the second case, if the packets are small, you
> might even eschew a
> > transport protocol and simply run your protocol over IP.  
> It is in this case
> > that a port number has no meaning, since ports are a
> transport protocol
> > mechanism.
> The "raw IP" idea certainly sounds interesting, but we already have a
> decent amount of multicast infrastructure built up that we're hoping
> to use without a major overhaul.

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.

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