Hello Michael,
On 10/27/2011 01:02 PM, Michael Raab wrote:
> Am 27.10.2011 17:44, schrieb Carsten Neumann:
>> hmm, although the already connected servers receive all changes a second
>> time.
>
> Yes correct. I'm not sure what the alternative may be. Ideas?
not really, it's just what prompted me to suggest tearing down the
connection and starting anew, the amount of data transmitted would be
the same - see below.
>>> With Multicast enabled, it seems communication between client and late
>>> arriving server is not initialized well. Looking at the code in
>>> OSGGroupMcastConnection the reason seems to be clear. Method initialize()
>>> is only called once, before the first message is send over the connection.
>>> That means server1 is respected by initialization, latter ariving servers
>>> not. I tried to move the server specific initialization code into the
>>> connectPoint() implementation but unfortunately failed to understand the
>>> logic behind the acknoledgement handling :-( (Lines 644-670). Hope someone
>>> may help to split the initlization into a general and a server(socket)
>>> specific part.
>> yes, that part is definitely not built for end points joining the
>> connection after the first write. Looking at the code a bit it seems to
>> me that most of the code from initialize could move to
>> GroupMCastConnection::connectPoint(). To be honest I don't quite
>> understand "ack" handling either at this point, but mostly I'm wondering
>> if it ever was used with ackNum != 1? I'm somewhat tempted to assume
>> ackNum == 1 and just drop the other code paths. It may take me a couple
>> of days before I can get around to trying this - in case you want to
>> give it another try.
>
> I can definitly give it a try ( its kind of urgent :-( ) but I'm not
> sure if there are more changes needed, e.g. in PointMcastConnection.
> What about the sendThread? Do I need to restart it after an additional
> connection...
I'm afraid I don't know the answer without actually trying, sorry.
>> How dynamic do you expect the server connect/disconnect to be for your
>> application? Would it be easier to create a new GroupConnection and
>> RemoteAspect when the number of servers changes?
>> Can you give is some background information on your application?
>
> Not so dynamic as you may think. ;-)
> The idea is to connect to a immersive environment (e.g. CAVE) somewhen
> after startup and later on be able to connect/disconnect more
> external devices, e.g. mobile devices, touch display....
> Dynamically disconnecting during runtime works fine now, but connecting
> additional displays causes the mentioned problems.
yes, I don't think dynamically increasing the number of nodes was really
considered as a use-case when the networking code was written. The idea
of programs like testDynamicClusterClient.cpp was more that the client
could keep running and dynamically connect to a render cluster (of fixed
size) for example if someone wanted to visualize data on a
larger/immersive display system. That the render cluster would change
its size (i.e. number of nodes) at runtime while connected was not
really considered.
> Could you give a hint how the problem may be solved using a new
> GroupConnection/RemoteAspect.
> To be honest, I can't imagine at the moment...
Using a new connection and RemoteAspect would put you pretty much in the
same situation as if you where running a cluster with the new number of
servers connected from the beginning - a much better tested case and the
assumption a lot of this code is based on, as you are discovering :-/
It would be somewhat disrupting on the already running servers, but if
the connect/disconnect events are infrequent this may be acceptable (of
course it may not be ok for your specific app).
Cheers,
Carsten
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
