Skip Menu |
 

This queue is for tickets about the POE-Component-IRC CPAN distribution.

Report information
The Basics
Id: 72206
Status: resolved
Priority: 0/
Queue: POE-Component-IRC

People
Owner: Nobody in particular
Requestors: pkerling [...] casix.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: DCC: Receiving a resumed file sends wrong position back to host
Date: Sun, 06 Nov 2011 14:32:32 +0900
To: bug-POE-Component-IRC [...] rt.cpan.org
From: Philipp Kerling <pkerling [...] casix.org>
Download (untitled) / with headers
text/plain 1.3k
The DCC protocol specifies that every received packet in a DCC SEND transfer should be confirmed by the client by sending the count of total bytes received back. When using the DCC resume extension, this seems to become not the number of bytes received, but the current position of the file write pointer inside file, i.e. the byte count including the part that has already been downloaded before. I noticed that while using DCC RESUME to receive data from a DCC host, the connection was not terminated by the host upon complete transmission of the file like it usually is (thus sending no dcc_done event). After changing the confirmation number sent back to the host by the DCC plugin from using the received byte count to the overall size received, it started working like it usually should. Now I could not find any specification clarifying this, but at least XChat also does it that way (see dcc.c:690 in xchat-2.8.8). I would therefore suggest to change the DDC plugin to also do it that way (patch attached). It should be noted that this also changes the numbers reported back by the dcc_* events. While I think that it's more useful this way anyway, it could potentially break existing applications and the documentation should be changed to reflect this. If this is not desired after all, I can rewrite the patch to use a different byte count only internally. - Philipp

Message body is not shown because sender requested not to inline it.

This fix will be in the next release.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.