[OTR-dev] Freeze, .NET, RPC, and other weirdness

[Ian Goldberg]

On Fri, Dec 18, 2009 at 10:21:20AM -0800, chris.tuchs at hushmail.com wrote:
> That does seem to be the cause and the appropriate workaround.  I 
> call libgcrypt to get a 32 bits of random data at start up of the 
> application.  Now all the strange .dll action happens, along with a 
> freeze I assume, during start up.  I no longer get the freeze 
> during the normal operation of the application.

Excellent.

> Two "oh-yeah"s.  1: Please change the name on the software page to 
> be just "Emerald Viewer - a Second Life Client"  The PR folks 
> decided a shorter name was better.

Done.

> 2:  I still have sitting around 
> as a patch the minor change I made to the fragmentation code to 
> support Second Life's surprising out of order delivery of IM.  The 
> format, syntax and semantics of the fragments remain the same, I 
> just changed the logic in the fragment reassembly to better handle 
> out of order delivery.  I would be happy to submit the patch, let 
> me know.

The semantics can't be *quite* the same, right?  Since there's no ID
number in the fragments (unnecessary if the packets are delivered in
order, possibly with drops), how do you know if:

1/2 1/2 2/2 2/2 

is A B A B or A B B A?  Current OTR would treat it as:

A B(dropping the partial A) B ignore

I guess "message ids in fragments" should be in the next version of the
wire protocol.  But that opens up a potential DoS attack where you send
packets with holes in them, forcing the other side to keep state around
(forever?).  When does your patch decide that it's time to expire old
partially completed messages?

> For a short while it looked like Linden Lab was going to try to ban 
> the use of OTR.  In the end they decided that there are valid use 
> cases for private messages, that they will look at doing something 
> similar.  So my battle for privacy in Second Life has moved on to 
> another area of their system.

Very cool, thanks!

   - Ian