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 ?
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
>>
>>
>
>
>
Received on Fri Jan 21 16:19:58 2011