4.5.x XFR "issue" results in closed socket, gets into redirect loop

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Attempt to login with MahChats OR the MSNPSharp sample client

What is the expected output? What do you see instead?
Transfer loop, first hits NSMessageHandler.OnXFRReceived, then initiates the 
disconnection.  Eventually it gets to  
SocketMessageProcessor.BeginDataReceive:392 which throws

ObjectDisposedException, Cannot access a disposed object. Object name: 
'Org.Mentalis.Network.ProxySocket.ProxySocket'.

An interesting note is that this happens with my accounts (I've got multiple 
for testing purposes, and because of LiveID requirements for Bizspark/etc), but 
NOT with the default account included in the test client.

It seems like it does the XFR bits correctly, and eventually starts getting 
extra data (like Censor stuff), then a XFR request to  
beta.gateway.messenger.live.com:1863... and it goes back to the start, looping.

What version of the product are you using? (MSNPSharp, OS, Mono etc.)
The bug is with 4.x/4.5.x, but works fine under 3.x (it doesn't have the login 
loop), .NET 4, Win7

Is your code check out from SVN or download from our download site?
Both latest release and SVN (trunk and MSNPSHARP_45_STABLE)

Original issue reported on code.google.com by theleagu...@gmail.com on 22 Nov 2011 at 2:31

[GoogleCodeExporter]

Nice report, let me take a look. Can you attach a full trace log copied from 
the Trace form of example client so we can better debug it?

Original comment by freezing...@gmail.com on 22 Nov 2011 at 10:51

[GoogleCodeExporter]

Or can you share us an account to reproduce the problem?

Original comment by freezing...@gmail.com on 22 Nov 2011 at 10:54

[GoogleCodeExporter]

I'll see if I can setup a test account to replicate the issue with tomorrow. I 
apoligise for the delay in response, Google Account stuffup means I no longer 
get email notifications :/

I've attached the traceform log, that log is the size generated after about a 
minute!

Original comment by theleagu...@gmail.com on 22 Nov 2011 at 12:50

Attachments:

• tracelog.txt

[GoogleCodeExporter]

I haven't yet figured out how to replicate this issue with a different/new 
LiveID. Interestingly the new account does *not* get redirected to 
beta.gateway.messenger.live.com at all. I was able to add the new LiveID to the 
contact list of my old one but then neither were visible to each other - and 
this was all through official clients. When I then fired up MSNP3.x sample 
client with my LiveID and readded the test LiveID, everything worked (and in 
current clients too). This is suggesting there is something 'wrong' with my 
account.

In the soap packet for the new user on logging in, there is 
"<IsBetaMigrated>false</IsBetaMigrated>"

I'll see who I'm able to contact on the Live team to try and see if this is 
related to my account.

Original comment by theleagu...@gmail.com on 23 Nov 2011 at 7:26

[GoogleCodeExporter]

Hi,

Actually there is nothing wrong with your account but something wrong with 
Microsoft. Due to my inspection, their live platform suffers from many bugs 
recently, many be windows live department is experiencing a big change.

Original comment by freezing...@gmail.com on 24 Nov 2011 at 10:33

[GoogleCodeExporter]

btw, would you please use wireshark to capture the data flow while logging in 
with the official WLM client and attach the dump here?

Thanks

Original comment by freezing...@gmail.com on 24 Nov 2011 at 10:52

[GoogleCodeExporter]

I think new protocol will handle all messages via http poll processor.
Socket processor will be deprecated on new live messenger.

Original comment by hepha...@gmail.com on 9 Dec 2011 at 9:08

• Changed state: Accepted
• Added labels: Priority-High, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I'm not sure I understand you here.. HTTP poll will be one option for the 
transport, but we sure need to keep the support for straight TCP connections.

Original comment by liuchang...@gmail.com on 9 Dec 2011 at 9:12

[GoogleCodeExporter]

I mean http transport is more acceptable then tcp socket processor in new 
protocol. Of course, we keep it for backward compability.

Original comment by hepha...@gmail.com on 9 Dec 2011 at 9:38

[GoogleCodeExporter]

Hi Chang,
That XFR redirection is redirecting MSN to a server that only supports HTTP 
polling. That's what they call "live beta services". What Ethem means is that, 
from now on, there will be more and more such cases, windows live might use 
http polling as their first connection choice instead of the current TCP 
connection (This is truth due to my tests so far). So you are actually leading 
our future (We have the plan of implementing HTTP polling before, but all of us 
are busy and now you come). Once you have made a workable version (even it's a 
version that only support login), we will go ahead and help you migrate the 
whole project. Please feel free to contact me and Ethem if you have any 
question :)

Original comment by freezing...@gmail.com on 9 Dec 2011 at 10:37

[GoogleCodeExporter]

Oh, that makes sense. Heh, HTTP is the new TCP.

Can you try the implementation in the Chang branch first; it seems the log in 
part is already there but then the conversation just drops off. I'm kind of 
busy lately so if you can spot anything obvious there it'll help a lot.

Original comment by liuchang...@gmail.com on 9 Dec 2011 at 10:48

[GoogleCodeExporter]

Original comment by hepha...@gmail.com on 30 Dec 2011 at 9:32

• Changed state: Fixed
• Added labels: Milestone-Release5.0.0