Friday, October 12. 2007
KMess file transfer fixes; MSN Protocol goodies
Last week I've committed a major change to the KMess SVN. In this case "major" means the diffs were 100kB in size. 
It fixes the last two problems we had with MSN direct connections, and brings the next release a lot closer too.
The first problem was caused by our way of sending file data. KMess 1.5-pre2 pushes messages to aggressively to the socket, choking the buffers of KExtendedSocket. By only sending the few bytes it could, this broke all message-length fields of squential packets. Oops..! This is fixed thanks to the readyWrite() signal and a lot of internal API refactoring. Hence the 100kB diffs.
Another problem was caused by some unknown protocol goodies revealed by Windows Live Messenger (WLM). Half way the transfer progressbar stalled in WLM, while KMess still thought it was sending file data. wtf... A closer look revealed it did get some messages back (flag 0x01). Now what..? That flag is isn't known yet at msnpiki.
From the WLM logs I've learned this means "chunk out-of-order", and it happened after KMess received some kind of "application/x-msnmsgr-transudpswitch" or "application/x-msnmsgr-transdestaddrupdate" message. I still have to clue what that message means or what to do with it, except sending an ACK as usual. I did figure out this broke the transfer in SVN. KMess incremented the message-ID to send the ACK, and now the remaining file data was sent with the wrong message-ID. Whoa. Not good! Fortunately it was easy to fix, and learned about some interesting new protocol messages too.
Finally, these two problems also broke picture transfers, emoticons and winks. Why you might ask? Those are also sent in parallel over the same direct connection! Almost everything is sent over the direct connection! It's good for performance and server load, but hard to code right at once. We've got it all working now, which I'm really proud of.
I can finally say that KMess supports direct connections properly for MSN file and picture transfers. Yay! 
I can't wait for the next release!! =) I want to definetely remove amsn!
Keep up the good work!
Many thanks!
Kmess's great!
It's always great to hear why people prefer KMess over other solutions.
Thanks for your encouraging comment
You may also want to try out the next release we're about to make available. Have a few days patience and hope you'll like it
Thanks for your article, although it's unconfirmed at this point, I'm pretty sure this might be the cause of aMSN's file transfers failing with some of our users. I'm currently fixing it, thanks to the explanation in your post (we also incremented the BlobId and didn't save the one used for the file data).
I've put a link to your post in the comments and give you credit for this discovery.
Thanks.
p.s: Nice to see some aMSN fans in here :p
Somehow your comment got lost and it seamed I had to approve it. Thanks for your feedback and credits!
I'm interested in that particular problem described in the fourth paragraph, and since there isn't documentation describing how to deal with message identifiers, I thought you would be able to help me with the following:
- In kmess p2p implementation, how do you increase identifiers (of sent messages)? Globally, per-user, per-transfer (or session), or what?
- Maybe i didn't understand, but does the data messages increase the message identifier? If it does,
- Do you have any idea, based in your experience, on identifier sequences? The docs say something like -3, -2, -1, 1, 2... but i think that doesn't apply always. And somebody said that it also differs between client versions...
- When does kmess p2p rely on message identifiers to process a message? (in my case, long file transfer invite messages with preview data in the context field)
- Can I use your reply as reference for documentation in msnpiki?
Thanks
Regarding the message identifiers, the message-id remains the same between all fragments of a payload (e.g. long invitation or file data). I haven't tested if message-id's should be unique across all p2p sessions, but I think this is a good idea. KMess uses a different object per session-id, and tracks a message-id counter per session.
I noticed you're one of the admins at the emesene forum. How would you feel about discussing things further over msn? You can add "vdboor" --at-- "hotmail.com" if you like.
