Sorry for these obscures questions out of any context.
It's a proprietary software developped by my firm. This software can
manage multiple VoIP calls simultaneously, one per multicast address.
It's why we need to bind to several, dynamicaly assigned multicast IP
addresses, not only one per guest.
With your help, we find a workaround to addresses assignment by
creating one interface by IP. 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 ?
On Fri, Jan 21, 2011 at 5:47 PM, Michael S. Zick <firstname.lastname@example.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?
>> 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 17:18:31 2011