------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=113525
------- Additional Comments From freebsd chillt de 2006-03-05 00:32 -------
Created an attachment (id=14961)
--> (http://bugs.kde.org/attachment.cgi?id=14961&action=view)
Fix (or workaround) for MSN file transfer
The attached patch fixes MSN file transfer with MSN 7.5 for me.
According to some debug output I added, what happens during a file transfer is
the following:
MSN 7.5 initiates the connection, sends an INVITE and about 20kB of data. Then,
it sends a new INVITE and another 20kB of data. It keeps going like that until
the entire file has been transferred.
Kopete on the other hand expects an INVITE to be sent once per transfer, at the
very beginning. An INVITE triggers a file open operation, which, if the file
exists already, truncates it to zero size. And this is exactly what happens
when the INVITE appears during a transfer - the file gets truncated.
The attached patch is a one-liner. It simply checks whether a file is being
transferred already and if so, refrains from reopening the file. The good news
is that this fixes file reception for me; I tried with a small ~ 100kB file and
a large 20MB one.
The bad news is that file transfer is unbelievably slow. Each time 20kB have
been sent, MSN 7.5 stalls for a few seconds before sending the INVITE and more
data. It looks like it's waiting for some kind of intermediate acknowledge. The
ack never comes, so MSN times out at some point, resets the connection, sends
the INVITE and a bit more data. All the online resources I found claim there is
only one ack at the end. Maybe MSN 7.5 introduced something extra that Kopete
(and others) are missing? Unfortunately, my knowledge of the MSN protocol is
precisely zero, so I don't know what this ack could look like. Also, I don't
have two machines running Windows between which I could sniff a transfer from
say MSN 7.5 to MSN 6.x.
Maybe this quick hack can be committed to at least fix the dataloss for 0.12
and someone else can pick it up from here?
_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
