[OTR-dev] Pidgin + Yahoo not support SMP?

[chris-tuchs at hushmail.com]

I just tested SMP interoperation between the GreenLife 
implementation
of OTR and the Pidgin implementation.  With one issue, I am able to
complete the SMP protocol in both directions.  However the issue I
encountered may explain the problems with Pidgin <--yahoo--> Pidgin
SMP problems I have experienced.  Yahoo does not maintain order of
IM's in every case.  Below is a message coming from Pidgin via Yahoo
to the official Yahoo IM client, which doesn't have OTR.  I was 
doing
Avy1(OTR) <--SL--> Avy2(no OTR) <--cut-n-paste--> User1(yahoo no 
OTR)
<--yahoo--> User2(pidgin with OTR).  I arbitrarily cut the lines off
at 64 characters cause all that matters really is demonstrating the
out of order delivery.

?OTR,00002,00004,OCTiVspdIkxpqKlACVXDfCp/lFiI345aBsx60GgPF/vL1XP
?OTR,00001,00004,?OTR:AAIDAQAAAAMAAAAEAAAAwEIH2lnX+NPoHtYYXuDIvf
?OTR,00004,00004,Z+vhQwKssDnBB18z1nFURGZz3k2I2jaOqJek3U8/XkDlVd7
?OTR,00003,00004,84StZgo+6T/vqtG+9OD4x3tHO1DirnzOih3A2Zg/j+I8CeG

This is unfortunately a problem I also see in Second Life -- the IM
system does not maintain order of fragments under some situations.
Also when I send long messages (256KByte) Second Life is arbitrarily
dropping some fragments.

I am not sure what the 'right' solution is, but the existing message
fragmentation re-assembly code in the released source does not 
handle
out of order fragments or missing fragments.  Is there more recent
code which handles some of these problems?

To be clear, SMP does work in GreenLife now, when SL doesn't drop
or re-order fragments.  I assume SMP would work Pidgin to Pidgin
over Yahoo if Yahoo didn't reorder the fragments, but I have not
tested that.

Chris