04:59 <ToasterKTN> !* cmd exec gem update cinch

04:59 <ToasterKTN> opps wrong channel sry :-D

05:05 <dominikh> indeed.

05:32 <ToasterKTN> Good morning. For smaller files up to 120k it seems to work now. Bigger files, i get Broken Pipes / Con resets but no Exception on cinch. it seems the bot closes the connection ebfore everything is transfered..

05:33 <dominikh> that seems unlikely

05:33 <ToasterKTN> It says - II DCC: Outgoing DCC SEND: File name: syslog-47120101T0000.txt - Size: 256394B - IP: 10.1.0.1 - Port: 36703 - Status: done

05:34 <dominikh> well, is that the correct size?

05:34 <ToasterKTN> rw-r--r-- 1 root root 256394 Apr 26 07:30 /tmp/syslogpart

05:35 <ToasterKTN> received 158224

05:36 <ToasterKTN> on Java this happens to me if i dont flush my streams, before i close it. :-X

05:38 <ToasterKTN> I am on a remote side, not on the same net. so it may be some kind of "timing" issue. from stock clients it seems to work. :(

05:40 <dominikh> what's the receiver?

05:40 <dominikh> sending 1 GB locally works, as does sending 1 GB locally very slowly.

05:40 <dominikh> have you tried a different client?

05:40 <ToasterKTN> i use LimeChat for me as client.

05:40 <ToasterKTN> Lemme retry with XChat

05:42 <dominikh> I do see a bug in the code.

05:42 <ToasterKTN> Same... * DCC RECV syslog-47120101T0000.txt von ctsprdfiw101 gescheitert. (Connection reset by peer).

05:42 <dominikh> give me a sec

05:44 <dominikh> can you clone from git, check out the dcc-bugfix branch and test that?

05:47 <ToasterKTN> On it.. lemme test

05:51 <ToasterKTN> Hmm.. Seems to break now on the last 16k or so.. i receive like 300/315k , 114/131k and sometimes... 2 out of 20 it works :-D

05:52 <dominikh> are you sure you're running the new version from the right branch?

05:53 <ToasterKTN> I feteched https://raw.githubusercontent.com/cinchrb/cinch/dcc-bugfix/lib/cinch/dcc/outgoing/send.rb

05:54 <dominikh> can you have the bot send me a file?

05:55 <ToasterKTN> Its on a corporate network via VPN. So i guess no. Bu i can send you my few lines for the plugin if that helps

05:55 <dominikh> how likely is it that the network connection is unreliable?

05:56 <ToasterKTN> unlikly, i transfer gigs per day over this conns, without problems

05:57 <ToasterKTN> lemme test a very big file.. like a gig to see if it breaks at the end

06:03 <ToasterKTN> Hihi.. Well I am sorry man. But if i transfer 210MB i reveice 209MB. To be exact: Send 219291713 / receive 218997594 missing

06:03 <dominikh> fwiw, "breaks at the end" isn't an accurate diagnosis. for example the bug I just fixed would lose data in the middle of the transfer, not at the end.

06:04 <dominikh> so optimally, you'd compare the two files and see where data is missing

06:05 <ToasterKTN> Well thats a binary. But the smallers 300K Files are syslogs. and they are broken at the end.. they stop like in the middle of a log line

06:07 <ToasterKTN> And it differs.. i retransfered a few time the big files.. best transfer was up to 219251233

06:08 <ToasterKTN> I retry with XChat. to make sure its not the client...

06:09 <ToasterKTN> Same with other clients.. :(( (Connection reset by peer)

06:10 <dominikh> well I'm sorry, but I can't spot anything wrong with the code. I have no idea what the issue is

06:14 <ToasterKTN> I will make some tcp inspection to see what happens. Maybe i see something..

06:16 <dominikh> ToasterKTN: try replacing ws.first.write with ws.first.send and see if it makes any difference whatsoever

06:18 <ToasterKTN> Yeah, that differs.. now i get 0 Bytes :-D

06:18 <dominikh> at least it's a consistent result

06:19 <ToasterKTN> /var/lib/gems/1.9.1/gems/cinch-2.3.2/lib/cinch/dcc/outgoing/send.rb:109:in `send': wrong number of arguments (1 for 2..3) (ArgumentError)

06:20 <dominikh> try send(chunk, 0)

06:20 <dominikh> instead of send(chunk)

06:22 <ToasterKTN> Same problem as before.. i got 208/209MB

06:23 <dominikh> no idea then. also I'm going to bed now, so we'll have to talk later.

06:24 <ToasterKTN> Good night, and thanks for your support. i will do some investigation..

06:24 <dominikh> good luck. bye.

06:54 <ToasterKTN> !ctsprdsup001 syslog 1000

06:55 <ToasterKTN> !ctsprdsup001 syslog 1000

06:55 <ToasterKTN> sry :-D

11:51 <ToasterKTN> @dominikh This works for me. even for very large > 1GB Files. But it misses Timeouts / Resends and Data checks. Seems if i wait for the answer of each packet, it works perfectly... https://github.com/ToasterKTN/cinch/blob/master/lib/cinch/dcc/outgoing/send.rb

11:54 <ToasterKTN> Because i have no clue on ruby, i did not yet find a clean way to backout, if con breaks or if a packet gets missed. as i understud the whitepapers, the bytes i get back are a 32bit int with the amount of data received. Would be nice to check that.

15:45 <dominikh> The acks in DCC are entirely useless and slow down transfers a lot. They aren't numbered, so you can't recover. All modern clients pretty much ignore them

15:46 <ToasterKTN> @dominikh Yeah i checked a few of them... most client dont seems to run like that

15:47 <ToasterKTN> this is kinda annoying.. 30 years old standards, and still not usefull :-D

15:49 <ToasterKTN> well i guess i will kinda upload shit to a webserver and post a link to my clients :-X