Subject: Re: [vserver] RE : [vserver] VServer and Multicasting
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Sun, 23 Jan 2011 21:39:10 +0100

On Fri, Jan 21, 2011 at 07:32:12PM +0100, mourad.alia@orange-ftgroup.com wrote:
> I am working with Julien in the same project (see my previous email on
> OpenVZ vs VServer) :

> Our software is a java application representing a VoIP client which
> able of managing multiple calls at the same time. This application
> uses many server distributed over many servers (out of the scope here)
> to create and to route calls. In our case, we are obliged to manage
> such calls from one instance which is solely hosted on a VServer and
> which is assigned to one client ID. Consequently, we should assign
> many adresses to one guest. Everything is working fine without the JMX
> component. When enabling JMX (part of the software) which uses the
> socket 0.0.0.0.(all interfaces) only the first guest is started.

what is 'the first guest'?

> I hope this will help in udertanding our problem,

maybe somebody could give an example what happens
and what he 'thinks' that should happen instead :)

TIA,
Herbert

> -- Mourad 
> ________________________________________
> De : Michael S. Zick [mszick@morethan.org]
> Date d'envoi : vendredi 21 janvier 2011 18:32
> À : vserver@list.linux-vserver.org
> Objet : Re: [vserver] VServer and Multicasting
> 
> On Fri January 21 2011, Furgerot Julien wrote:
> > Sorry for these obscures questions out of any context.
> > It's a proprietary software developped by my firm.
> >
> 
> Hmm...
> Guess that means it is unlikely that I designed and/or wrote it. ;-)
> 
> > This software can
> > manage multiple VoIP calls simultaneously, one per multicast address.
> >
> 
> Still don't see your problem, why not 256 vserver contexts, one per
> each of 256 individual multicast address.
> 
> > It's why we need to bind to several, dynamicaly assigned multicast IP
> > addresses, not only one per guest.
> >
> 
> So go ahead and assign it, only one of the 256 vserver contexts will
> handle the processing - nearly identical to having only one thread handle
> the processing.
> 
> > With your help, we find a workaround to addresses assignment by
> > creating one interface by IP.
> >
> 
> Great, now do that another 255 times.
> 
> Mike
> > But now, we would like to force
> > "any_addr" (0.0.0.0) binding to a choosen IP/interface, because a
> > component in our software we don't manage (java JMX) bound to 0.0.0.0.
> > In my experiments with vservers, only the first started vserver can
> > bound to any_addr, so others can't bind to the same port.
> >
> > Maybe have I miss something with vserver configuration ?
> >
> > Sincerely,
> > Julien Furgerot
> >
> > On Fri, Jan 21, 2011 at 5:47 PM, Michael S. Zick <mszick@morethan.org> wrote:
> > > On Fri January 21 2011, Furgerot Julien wrote:
> > >> Thank you for this reply.
> > >>
> > >> However, recall, that my software is a VoIP application which could
> > >> use different (a range of) multicast adresses during its lifecycle.
> > >> These addresses are allocated on demand by another software. Thus,
> > >> each instance is configured to be potentially linked to one of these
> > >> adresses. Furthermore, one can have many simultaneous VoIP
> > >> communications where each one uses one given multicast address. Except
> > >> if there is a solution to resolve this multiple multicast adresses
> > >> bindings, I can't see how this could be handled.
> > >>
> > >> What do you think ?
> > >>
> > >
> > > Still can not see your problem in your description above.
> > > Does a single, VoIP call use multiple addresses during its lifetime?
> > >
> > > I would think not. Once the call is put up, it will use whatever
> > > address it was assigned until the call is torn down.
> > >
> > > Or, at least that was the way they used to work.
> > >
> > > Do you mean by "my software" something you invented yourself?
> > > Or do you mean "the software I am using"?  What software?
> > >
> > > Mike
> > >
> > >>
> > >> Julien
> > >>
> > >> On Fri, Jan 21, 2011 at 3:02 PM, Michael S. Zick <mszick@morethan.org> wrote:
> > >> > On Fri January 21 2011, Furgerot Julien wrote:
> > >> >> On Fri, Jan 14, 2011 at 5:47 PM, Herbert Poetzl <herbert@13thfloor.at> wrote:
> > >> >> > services binding to 0.0.0.0 inside a Linux-VServer guest
> > >> >> > will be automagically limited to the assigned IP addresses,
> > >> >> > which in turn means, if you assign different IP addresses
> > >> >> > to different guests, they will live happily side by side
> > >> >> > even if the services inside the guests bind to 0.0.0.0
> > >> >>
> > >> >> You are right, I have tested when the VM is bound to one IP address
> > >> >> and it works fine !
> > >> >>
> > >> >> However, in my configuration each VServer is bound to many IP
> > >> >> addresses in order to be able to receive/send from/to many multicast
> > >> >> addresses that are allocated on demand. Thus, I was wondering whether
> > >> >> it is any hint so that to restrict sockets on 0.0.0.0 to be bound to
> > >> >> only one of these associated IP addresses ? Is there any patch that
> > >> >> can overcome this problem ?
> > >> >>
> > >> >
> > >> > Why not just run a vserver per multicast address?
> > >> >
> > >> > Your whatever-it-is application is probably running an instance
> > >> > per multicast address anyway (perhaps as a thread).
> > >> >
> > >> > If you "hashify" the on-disk files, you'll only have a single
> > >> > copy of those files (on-disk and in-memory) -
> > >> > So even running a few hundred context-per-address vservers would
> > >> > probably not be all that resource intensive.
> > >> >
> > >> > Mike
> > >> >> Again, thank you for all,
> > >> >>
> > >> >> Julien
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> 
> 
> 
> *********************************
> This message and any attachments (the "message") are confidential and intended solely
for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately
and inform the sender.
> ********************************