Subject: Re: [SAM] New Version draft common multicast API

From: Gustavo Carneiro <[email-masked]>
Date: Mon, 13 Sep 2010 16:41:15 +0100

On Wed, Jul 28, 2010 at 22:22, Matthias Waehlisch <[email-masked]>wrote:

> Hi all,
>
>  we submitted an updated version of the draft "A Common API for
> Transparent Hybrid Multicast":
>
>  * http://www.ietf.org/id/draft-waehlisch-sam-common-api-04.txt
>
>  This includes the following changes:
>
>   1.  Use cases added for illustration.
>
>   2.  Service calls added for inquiring on the multicast distribution
>       system.
>
>   3.  Namespace examples added.
>
>   4.  Clarifications and editorial improvements.
>
>
>  Comments are very welcome!
>

Hi,

I am proposing to use/implement a subset of this API inside a european
research project; let's see how it goes.

I have a question regarding the send() API.

4.3.2.  Receive

>    The receive call passes multicast data and the corresponding Group

   Name to the application.

>        int receive(int s, const uri group_name,

                   size_t msg_len, msg *msg_buf);

>    The s argument identifies the multicast socket.

>    The group_name argument identifies the multicast group for which data

   was received.

>    The msg_len argument holds the length of the received message.

>    The msg_buf argument points to the payload of the received multicast

   data.

>    On success the value 0 is returned, otherwise -1.

Is this a synchronous call?  What if there are multiple multicast sockets to
listen to, we need to create a separate thread for each?

I think we could use a select/poll/WaitForMultipleObjects equivalent for the
abstract multicast sockets.  I'd be happy to contribute text or ideas to
this end if you think is a good idea.

Best regards.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 13 Sep 2010 22:33:51 +0200

Hi Gustavo,

  many thanks for your interest on the API draft!

  Please, see comments inline.

> research project; let's see how it goes.
  This sounds interesting. It would be great, if you do not mind to 
share some more details.

> Is this a synchronous call?  What if there are multiple multicast 
> sockets to listen to, we need to create a separate thread for each?
> 
  Yes, it is a synchronous call and thus you need separate threads for 
multiple receive calls. Is this a problem?

  As suggested in Section 3.2 (cf., Figure 2) one may implement the API 
based on a middleware. This middleware abstracts from current system 
sockets.

  In general, you can use one receive call at the application to receive 
data on multiple interfaces.

> I think we could use a select/poll/WaitForMultipleObjects equivalent 
> for the abstract multicast sockets.  I'd be happy to contribute text 
> or ideas to this end if you think is a good idea.
> 
  The intention of the draft is to provide a basic set of primitives.

  Currently, we are not intending to define additional asynchronous 
polling mechanisms. However, we are happy to hear more about your 
thoughts and experiences.

Thanks again & Best regards
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Gustavo Carneiro <[email-masked]>
Date: Wed, 15 Sep 2010 14:50:49 +0100

>   This sounds interesting. It would be great, if you do not mind to

Not much is defined yet, not much to share.  The project is still starting.
 The web site is http://www.ict-alicante.eu/

In a few months I should have more info, then I will share.

> multiple receive calls. Is this a problem?

It could be a scalability problem, depending on the context.  It's too early
to tell whether this will be a problem in my project.

> data on multiple interfaces.

Yes, but not one thread to receive data from multiple "multicast sockets",
as far as I can tell.

> thoughts and experiences.

Ok.  In a few more months I should know.  In the mean time, keep up the good
work.

Best regards.

---

From: Gustavo Carneiro <[email-masked]>
Date: Wed, 15 Sep 2010 15:00:09 +0100

On Wed, Sep 15, 2010 at 14:50, Gustavo Carneiro <[email-masked]>wrote:

> It could be a scalability problem, depending on the context.  It's too
> early to tell whether this will be a problem in my project.
>

Sorry, after sending I realized I wanted to expand on this a bit, but
forgot.

This is not SAM-specific, but in any OS threads occupy resources that should
be considered.  Some OS'es have context switching penalties at runtime (CPU
time overhead).  All OSes have a memory overhead.  At the very least there's
a stack segment to be duplicated for each thread.  For instance, in Linux
the default stack size is 8 MB, therefore 10 threads for receiving from 10
sockets will waste 80 MB of RAM.

But, like I said, only time will tell if this is a problem in practice.

Best regards.

> Ok.  In a few more months I should know.  In the mean time, keep up the
> good work.
>
> Best regards.
>
> --