Error: UTP_ECONNRESET

[JacopoDaeli]

Hello @mafintosh,

I am trying to use utp-native for a p2p file transfer application.

I am testing with the following code:

[Server]

var utp = require('utp-native')

var server = utp.createServer(function (socket) {
  socket.pipe(socket) // echo server
})

server.listen(10000, function () {
  console.log('server listen')
})

[Client]

var utp = require('utp-native')
var fs = require('fs')

var socket = utp.connect(10000, '10.0.103.24') # where 10.0.103.24 is another host in my LAN

var r = fs.createReadStream('/Users/jacopodaeli/Desktop/test1.mp4')
var w = fs.createWriteStream('/Users/jacopodaeli/Desktop/test1.copy.mp4')

r.pipe(socket)
socket.pipe(w)

Before the transfer is completed the server crash with Error: UTP_ECONNRESET.

Any idea how can I solve it? As well, it seems quite slower than a normal TCP connection. Any idea?

I am running these scripts with Node.js 4.2.4 on OSX El Capitan.

Thanks in advance,
Jacopo

[mafintosh]

this is probably because utp doesn't support half open connections so when your client calls .end in the pipe the server will stop echoing pending data (similar to doing socket.destroy with tcp).

could you hook up .on('end') on the file read stream and see if that fires before the ECONNRESET is emitted?

re: performance. yes utp-native is currently slower than tcp because i haven't really optimised it yet (primary focus has just been getting things to work) and it's probably always gonna be slower than tcp on a local network / very fast internet. Since tcp runs inside the kernel and utp is running in js and you have a lot of bandwidth on a local network, io might not be the bottleneck. that being said i think we can make it 2-3x faster by solving some easy perf bottlenecks :)

i'm gonna add a benchmark so we can start tracking perf overall

[JacopoDaeli]

@mafintosh Yes .on('end') on the file read stream is fired before the ECONNRESET is emitted. Any work around?

[JacopoDaeli]

@mafintosh I confirm it is probably because utp doesn't support half open connections. Any work around you have in mind?

[mafintosh]

you need some sort of overlay protocol to work around this like http. you
could also use mafintosh/length-prefixed-stream and send an empty buffer to
indicate end. i'm on my phone right now but i can send you an example when
i get to my laptop.

for hole punching you can use the bittorrent-dht or custom dns servers. it
is a bit complicated but see mafintosh/discovery-swarm for a real world
example of this.

we should probably add some of this stuff to the readme.
On Mon, 22 Feb 2016 at 09:45, Jacopo Daeli [email protected] wrote:

@mafintosh https://github.com/mafintosh Yes .on('end') on the file read
stream is fired before the ECONNRESET is emitted. Any work around?

—
Reply to this email directly or view it on GitHub
#5 (comment).

[JacopoDaeli]

@mafintosh I will really appreciate an example when you get to your laptop :-) Please keep me posted!

Thanks a lot,
Jacopo

[JacopoDaeli]

Hey @mafintosh , I am building a sort of overlay protocol to transfer file over UTP. For the moment I made a kind of example/idea/prototype which solve the ECONNRESET issue.

Here the code:
https://github.com/JacopoDaeli/udtp/blob/master/example.js

Please, let me know what do you think, and if it make sense to you.

Thanks,
Jacopo

[JacopoDaeli]

@mafintosh can we add Half Open connection support with utp ?

[daviddias]

👍 for halfOpen connections. Is there any technical limitation of why we couldn't have it on the uTP level? Isn't the ST_FIN packet designed for this purpose also?

[mafintosh]

i don't think libutp supports half-open connections even though the protocol might. the only end api exposed is

utp_close()

which closes both the readable and writable end of the connection.

[daviddias]

@mafintosh pointed out to me that libutp finally has half-closed connections -- bittorrent/libutp#102 🎉 \o/ and I see that it was added to utp-native already b0af19f 🎉🎉🎉👏🏽👏🏽👏🏽