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

Reply via email to