Re: [ssm] Re: last call comments on ssm-arch doc

Pavlin Radoslavov <> Fri, 17 January 2003 04:39 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id XAA02312 for <>; Thu, 16 Jan 2003 23:39:31 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h0H4snJ18801; Thu, 16 Jan 2003 23:54:49 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h0H4lRJ18548 for <>; Thu, 16 Jan 2003 23:47:27 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id XAA02229 for <>; Thu, 16 Jan 2003 23:31:30 -0500 (EST)
Received: from (localhost []) by (8.12.3/8.12.3) with ESMTP id h0H4Yp2U067291; Thu, 16 Jan 2003 20:34:51 -0800 (PST) (envelope-from
Message-Id: <>
cc: Michael Luby <>, Pavlin Radoslavov <>,
Subject: Re: [ssm] Re: last call comments on ssm-arch doc
In-Reply-To: Message from Hugh Holbrook <> of "Thu, 16 Jan 2003 02:12:47 EST." <>
Date: Thu, 16 Jan 2003 20:34:51 -0800
From: Pavlin Radoslavov <>
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> I like both your suggestions regarding the building of multi-sender
> apps with SSM.  Here's a revision that incorporates your requests; I
> think this is an improvement.
>     SSM is particularly well-suited to dissemination-style applications
>     with a single sender.  It can be used to build multi-source
>     applications, but the multi-source "rendezvous" functionality does not
>     occur in the network layer.  Just like in an application that uses
>     unicast as the underlying transport, this functionality can be
>     implemented by the application or by an application-layer library.
>     For instance, an application that desires to provide a secondary data
>     source in case the primary source fails over might implement this by
>     using one channel for each source and advertising both of them to
>     receivers.

Looks good to me.

> I'm having more trouble addressing Pavlin's comments regarding what I
> wrote about resource discovery:
> > Hence, what about modifying the last sentence to say that resource
> > discovery might be possible, but with the help of additional
> > support, such as application-level relay.
> I don't like the specific phrase that you suggest, Pavlin: "with the
> help of additional support, such as application-level relay" because
> it leaves me wondering what other possibilities there might be besides
> application-level relaying, and I can't actually think of any.
> So how about if I simply say this:
>     Peer-to-peer multicast resource discovery of the form in
>     which a client sends a multicast query directly to a "service
>     location group" to which servers listen is not directly supported
>     by SSM

Fine with me.

> This is true and doesn't rule out other forms of service discovery.
> If the group thinks we need to say more about resource discovery than
> this, then I also wrote this
>     SSM might play a role in a resource discovery
>     service as a mechanism that, for instance, well-known relays can
>     use to forward client queries or server advertisements to
>     interested recipients.

I think there is no need to say that, so the "Peer-to-peer..."
paragraph is just fine.


> The latter bit of text has the problem for me that I don't actually
> think this is a very good application architecture and I hesitate to
> make the text look like it endorses it as a good use of SSM.  Once
> you've got a set of well-known servers, why wouldn't you just register
> the services with them via unicast and let clients do normal unicast
> queries?
ssm mailing list