Improve the P2P support

[diederik]

The P2P support of KMess is already at a high level. There are some situations which are not supported yet. These are currently not visible because KMess won't invoke such situations.

However, implementing these improves the P2P support, fast file transfers in some corner cases, and future compatibility with Windows Live Messenger releases.

• When a SLP Decline/error is sent for a SLP transfer invitation, it should continue the transfer over the switchboard. Currently the session is aborted entirely. -> #176
• ~When the remote client only returns it's internal IP, send a SLP transfer invitation back so KMess becomes the server instead.~ -> #178, #179
• Find out which situations cause WLM to send a second SLP transfer back (one is sending "Listening: false". -> #180
• Enable KMess to start a direct connection for picture transfer, like WLM: -> #181
  • Currently it can only sent such invitation if it also started the session. Picture transfers requires the receiver to send one too.
  • The data preparation ACK should be sent after the connection is established.
• Keep a queue of messages which are waiting for an ACK. -> already in KMess 1.5, and added #185
• The data preparation can't be aborted properly now. Also detect when contact does this. -> #182
• Find out how to receive the 0x40 message -> #183 P2PApplication is also already left "half-open" as of r2240.
• Check P2P incomingMessages_ / outgoingMessages_ cache for timeouts.
• Detect multiple external IP addresses (use Solid in KDE 4). -> #187

Purely for protocol compatibility:

• When receiving a BYE message with unknown call-id, send '481 No Such Call' back. -> #188
• When receiving a message with unexpected offset, send 0x01 flag back (chunk out-of-order). already in 1.5
• When a ACK does not arrive, the 0x06 message should refer to the previous message which is missing. not true -> #186

And some unknown outcome:

• Test what happens when there is a picture transfer in a multi-chat, and: 1) a private chat with the same contact is started 2) when one of the chats becomes buzy.
• Test which applications need to be aborted when the switchboard disconnects or reconnects. -> #189, #190
• Test whether KMess should implement the "datacast emulation over MSNP2P" for wink invites. New clients don't require this. Not done by WLM either, no matter what MSNC version is used. If a client doesn't support multi-packet, WLM won't send the wink.

[diederik]

added 0x01 message.

[amroth]

I've noticed this bunch of failed ASSERTs: It's probably due to changes in the new MSN protocols. Note that they don't prevent the file transfers from completing.

ASSERT: "waitingState_ == P2P_WAIT_DEFAULT" in kmess/network/applications/p2papplication.cpp (3695)
ASSERT: "waitingState_ == P2P_WAIT_DEFAULT || waitingState_ == P2P_WAIT_FOR_FILE_DATA || waitingState_ == P2P_WAIT_FOR_PREPARE" in kmess/network/applications/p2papplication.cpp (1589)
ASSERT: "waitingState_ == P2P_WAIT_DEFAULT" in kmess/network/applications/p2papplication.cpp (3695)
ASSERT: "waitingState_ == P2P_WAIT_FOR_PREPARE_ACK" in kmess/network/applications/p2papplication.cpp (505)
ASSERT: "waitingState_ == P2P_WAIT_FOR_PREPARE" in kmess/network/applications/p2papplication.cpp (902)
ASSERT: "waitingState_ == P2P_WAIT_FOR_PREPARE" in kmess/network/applications/p2papplication.cpp (902)
ASSERT: "waitingState_ == P2P_WAIT_FOR_PREPARE" in kmess/network/applications/p2papplication.cpp (902)
ASSERT: "waitingState_ == P2P_WAIT_FOR_PREPARE" in kmess/network/applications/p2papplication.cpp (902)
ASSERT: "waitingState_ == P2P_WAIT_DEFAULT" in kmess/network/applications/p2papplication.cpp (3695)
ASSERT: "waitingState_ == P2P_WAIT_FOR_PREPARE" in kmess/network/applications/p2papplication.cpp (902)

[diederik]

Some of the asserts are duplicates, I've fixed some with r2240.

[diederik]

Splitted this ticket to separate ones. Wrote ticket numbers in description itself.