MSNSLP: display picture quirks

[BenoitRen]

Hello, I'm the project owner of XUL MSN Messenger, a basic MSN Messenger clone built on the Mozilla Gecko platform. I recently implemented display picture transfer, and would like to talk about the quirks I've noticed during doing so.

The documentation on MSNPiki on display pictures is decent, but it's outdated. After acknowledging the 200 OK response, my client receives an INVITE request for a direct connection that I don't know what to do with. Yet if I ignore it, the rest of the session proceeds as normal. One would suggest not to worry about this, but the latest version of Windows Live Messenger keeps bugging my client with messages having a flag of 4, telling it that there's a pending invite.

I decided to at least acknowledge this INVITE. Then I made my client reply to it with a 200 OK message that has a message body with the field "Bridge: SBBridge" to tell WLM that I wanted to continue over the switchboard. While both of these solutions didn't stop the transfer from succeeding, the official client still keeps bugging my client as described earlier.

Something else that differs from the MSNPiki documentation is the BYE request. According to MSNPiki, the receiving client should send it. Yet aMSN sends it as the sending client, and I've observed that the official client does this as well. Perhaps the official client is complaining that I don't acknowledge it? Who knows.

I look forward to your thoughts on this.

[kakaroto]

Hi BenoitRen, welcome to the forums!
lol, you know you could have asked me on IRC about this stuff, it would have been easier to answer you 'live' over IRC!
Anyways, if you open aMSN, open a chat with someone, then from the main window, press Ctrl-D, the protocol log window will appear.. clear it, then you can force a redownload of the display picture by right clicking on the display picture of the user in the chatwindow, then select 'Original' for the size.. it will redownload it and you can see what happens in the protocol with aMSN...
basically, what happens is that you accepted the transfer, then a new invitation is sent to initial a direct connection.. if you don't answer it (or it fails), it will go through the switchboard.. which is what you want... you'll notice that aMSN will ACK that invite, but won't do anything more with it..
those 4 bytes messages you keep receiving might be a 'please send an ack' message or something like that... or maybe they are 'data preparation' packets that need to be ACK-ed... make sure your P2P stack automatically ACKs any blob you receive...
Your alternatives are to ignore it.. or answer it with 200 OK (but you'd have to support the direct connection protocol) or just 603 decline it!! you can decline the second invite, i don't think it would affect the DP transfer!

about the BYE, I think (can't really remember) that BOTH parties should send a BYE... I think once you receive the BYE, you should also send a BYE.. and yes, definitely, you should ALWAYS *ACK* any blob you receive! (a blob being a message with the same sequence number).
If you don't ACK a blob, WLM will make you pay dearly for it...
I hope I was helpful.. if you have nay other questions, don't hesitate! I'll be glad to help!

p.s: it's funny, the coincidence made it that in the last week only, i've gotten into contact with 3 alternative MSN clients/libs and we shared thoughts on the protocol!
nirce to see some collaborations happening lately

[BenoitRen]

Thanks for the welcome. The thought did occur to me to just ask on IRC, but it's easier to write out thoughts on the board, and this way the rest of the world can benefit from the exchange.

I did use WireShark to see what aMSN did, and when it got that INVITE, it seemed to go crazy with INVITE requests of its own.

When I wrote "messages having a flag of 4", I did mean that the binary field "vlag" has a value of 4. I wasn't talking about the message length.

It's unfortunate that older MSN versions like 6.0 can't be tested anymore, because recent WLM versions transfer display pictures a bit differently, with an AppID of 12 instead of 1. I still have to try the oldest version with display picture support, though, which is WLM 8.1.

There is a quirk I forgot to mention. The most recent WLM version seems to have a bug in its display picture transfer code. Except for the acknowledgements, all its messages have a flag summed with 0x1000000. Messages that normally have a flag of 0 have 0x1000000 as the flag value, and display picture data messages that normally have a flag of 0x20 have 0x1000020 as the flag value. Otherwise the messages are the same and can be treated as such.

As usual, Microsoft can't follow its own protocol.

[BenoitRen]

I've modified my code so my client waits for a BYE request that it then acknowledges and the acknowledgement to my own BYE request. The official client doesn't seem to complain anymore. Great.

Next on my list is file transfer.

[kakaroto]

cool, glad you fixed it!

[BenoitRen]

Things can never be easy. WLM 8.1 (and I assume 8.5) don't send a BYE request after receiving the data message acknowledgement. This is why the display picture didn't appear anymore after making my code wait for it.

So much for consistency.

[kakaroto]

hehe, well you shouldn't wait for the BYE, you should send the BYE yourself once you're done and if you receive a BYE, simply ACK it.. your p2p stack should always automatically ACK *any* message it receives (assuming size+offset == total_size)...
This should make it work and be consistent..

[BenoitRen]

The problem was that the P2P stack is in a P2PSession object that only exists when there's a session. I solved this by waiting for 5 seconds before deleting the object.

[kakaroto]

hehe, yeah, I thought you had that problem.. your 5 second timeout is a solution but not a great one.. i'd say the ACK should be done by the session manager (that object that creates the session).. acks should be independent of a session, it should just be sent for any message whether they are part of a session or not...