Hi Saros SWP Team, there will be a time when you encouter (depends on how you reintegrate this feature)
that chat tabs will open, but nothing is displayed. Short answer: https://sourceforge.net/tracker/?func=detail&aid=3522454&group_id=167540&atid=3057957 How to solve it ? I do not know, both products uses a complete different network layer. Saros Light uses its own protocol. Some protocol packet are tunneled through XMPP. How they are tunneled ? After they are marshalled (which would now be send through a stream IBB / SOCK5) they are instead send via an IQ stanza (binary representation will be converted via BASE64 encoding). What does Saros do ? This is a little bit historically. In it is beginnings, Saros was used to send all messages as XMPP packets to other participant (with all it "pains", no garantuee that this packet ever reaches destination ... well maybe it reaches its "destination", the buffer of the XMPP server because the JID is offline). This causing also troubles when detecting broken connection. Can Saros detect broken connections ? Before I continue: So the issue is, Saros may sends activities as ChatMessages which will trigger some Smack stuff, that triggers some Business Logic ... which it should not ! So what is next. After some problems with the experimental Jingle Smack support, Hendrik Staib integrated IBB / Socks5 into the Smack Library (currently he implemented a little IBB wrong, but this is fixed since Smack 3.2) So next there were some "clever/smart" guys (I do not know them) who thought that it would be a great idea to "improve" (Premature Optimization) the throughput of sending Activities. The magic code can be found in the XMPPTransmitter class: if (data == null || transferDescription == null || (!dataManager.getTransferMode(recipient).isP2P() && data.length < MAX_XMPP_MESSAGE_SIZE)) { So the question is: When is: dataManager.getTransferMode(recipient).isP2P() == true ? It turns out, mostly never ... wait why ? Direct connections are only established if you send a packet which size is greater than MAX_XMPP_MESSAGE_SIZE ... the connection is currently established against the inviter and invitee (just for some stupid GUI stuff), so if you join a session, you have only a direct connection to the person who invited you, but not to other session participants. Even if direct send fails, Saros just sends the message via XMPP chat messages. Because of this multiple paths we have such a nice class (1000+ Locs) called the ActivitySequencer The intention was that you can continue editing on a file while lots of other file changes (creation of new files) are send indepentently. How often does this occure ? Well Eclipse refactoring is somewhat slow, you would not notice it. Only possible case is if you add a large file (approx 1 MByte). That is the real valid case ... but wait 1st. if you have a direct connection, this would not be used (I would not call sending 1 MByte of data via ADSL with 80 KiByte fast) 2nd. Why must the network layer handle such a case ? We already reworked this code with following result: http://saros-build.imp.fu-berlin.de/gerrit/#/c/148/ It turns out that two participants try to connect to each other at the same time, which will throw an Assertion Error if you run Saros in "debug" mode. Conclusion: the Saros Network layer is somewhat broken by all means, you should not touch it to worsen things. BR, Stefan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Dpp-devel mailing list Dpp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel