Hello Carsten, I spent some time today looking at the ack handling between GroupMcastConnection and PointMcastConnection. Actually I don't think that it's much clearer to me now. :-( I would be very pleased if you may find some time to have deeper look.
Thanks in advance, Michael Am 29.10.2011 00:00, schrieb Carsten Neumann: > 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 > ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
