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!