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?
> On Fri, Jan 21, 2011 at 3:02 PM, Michael S. Zick <email@example.com> wrote:
> > On Fri January 21 2011, Furgerot Julien wrote:
> >> On Fri, Jan 14, 2011 at 5:47 PM, Herbert Poetzl <firstname.lastname@example.org> 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
Received on Fri Jan 21 16:48:58 2011