Hello Carsten, Am 27.10.2011 17:44, schrieb Carsten Neumann: > Hello Michael, > > On 10/27/2011 04:37 AM, Michael Raab wrote: >> I think I have somehow understood the problem now. It has two main aspects: >> network communication and changelist based synchronisation. >> >> With StreamSock enabled, the communication seems to work well but the sync >> for latter arriving servers went wrong. The issue was that the completeState >> changelist I created before doing the sync contains everything except the >> type mapping (NEWTYPE fields) definitions as they are only generated once. I >> was able to fix that. Patch for RemoteAspect is attached. >> Now everything seems to run fine as long as I use StreamSock. > hmm, although the already connected servers receive all changes a second > time.
Yes correct. I'm not sure what the alternative may be. Ideas? >> 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... > 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? > > Cheers, > Carsten 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. 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... Thanks & Best regards, Michael ------------------------------------------------------------------------------ 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
