-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two connection events for single peer? #44
Comments
Sorry for this additional post, but I am kind of completely stuck and unable to make progress. It is not clear how to use these "connections". For each peer, we get a 'connection' event with a socket. What is the recommended usage pattern afterwards?
Also, regarding the topics:
|
I also want to know why there is a double connection but the real problem is that the extra connection doesn't actually disconnect and the total connections still increasing. app.js: const hyperswarm = require('hyperswarm')
const crypto = require('crypto')
const swarm = hyperswarm()
const topic = crypto.createHash('sha256')
.update('my-hyperswarm-topic-a59fa874')
.digest()
const isLookup = process.argv[2] === 'lookup' ? true : false
swarm.join(topic, {
lookup: isLookup,
announce: !isLookup
})
swarm.on('connection', (socket, details) => {
console.log('connection', details.stream.remoteAddress, 'size', swarm.connections.size)
socket.on('close', () => {
console.log('close', details.stream.remoteAddress, 'size', swarm.connections.size)
})
})
// same as hyperssh
process.once('SIGINT', function () {
swarm.once('close', function () {
process.exit()
})
swarm.destroy()
setTimeout(() => process.exit(), 2000)
}) Run in two consoles:
There you have the double connection, the remote address is actually my address.
And you can repeat it and the connections size still increasing. |
A quick note to please open separate issues for separate problems. It autoreconnects and you have to use details.backoff() to make it not connect immediately again (needs docs) https://github.com/hyperswarm/hyperswarm/blob/master/lib/peer-info.js#L41 In the near future we'll add connection dedup support, but in the meanwhile you can work around it using that api if you need too. For hypercores atm we just use both of the duplicate connections |
I was checking the double connection and one is tcp and the other is utp. swarm.on('connection', (socket, details) => {
if (details.type === 'utp') {
details.backoff()
socket.destroy()
return
}
// ...
})
I think yes, you already have for (let peer of swarm.connections) {
peer.write('my data');
}
I also need whitelist #46
As far as I can test yes. You have |
there is a dedup api for this now |
Trying to understand the behavior of connection by running the sample code from ReadMe. Not sure if this is the intended behavior, but when running the below code (the same code twice from two different terminals), seeing two connection events on each of them (total 4).
The ouptut looks like below on both terminals:
This happens with every connected peer. Two
connection
events are raised on both sides of the connection (total 4 for each p2p connection).Is this valid behavior?
Do we need
server
instance on both sides of a connection? Sockets are by defaultduplex
right?A single
client -> server
connection between two nodes can be fully duplex, I believe. Do we need the additional reverseserver <- client
connection also for every p2p?Or is it expected form the app that it will kill / close the duplicate connection? Would like to learn more about the right way to deal with these duplicate connections, since these connections count are rapidly escalating as we connect across multiple topics creating unnecessary resource pressure on the process (which can be better utilized for other connections, such as database connections or other app-level things). Especially on resource contraint devices.
The text was updated successfully, but these errors were encountered: