Connection management questions

[reconbot]

I'm making a chat program for fun using hyperswarm. I'm able to get the connected sockets on the connection event but I'm not sure how to do session management. I know tcp connections have a close event, but udp connections don't do they?

• Is there a common way to know if both kinds of connection have gone away?
• It seems multiple connections get made to the same peer, is there a way to identify the peer so we can handle additional connections (ignore them, fall back to them, close them, etc) or do we have to do that in the app layer?

This is probably a bad idea, but it's been so fun

★ npx hackerchat
☠️  Your network is not hole-punchable. This will degrade connectivity.
🎉 new friend 0!
🎉 new friend 1!
😀 0: hello?
😀 1: hello?
> hi!
>

Thanks!

[pfrazee]

@mafintosh Correct me if I'm wrong, but hyperswarm doesn't arrange UDP connections does it? I think it gives you either TCP sockets or UTP sockets. We might be smart to link to the socket interfaces in the docs.

@mafintosh Also correct me if I'm wrong, but yes you need to deduplicate connections in the app layer. There's a specific procedure we use in Dat that's designed to do that without each peer accidentally closing opposite connections, but I can't remember the exact details. Each peer gives themselves a random ID and communicates it, which is how we detect dups. Then on dup, you need some kind of connection identifier so that both sides can follow a rule like "disconnect the stream with the lower ID".

[reconbot]

There's no such thing as a UDP connection 😂 so that's on me for misreading. UTP Docs show it to be a UDP based protocol but it does do the connection management itself. Which is wonderful. 👌

That random ID approach is how I'm thinking of extending hackerchat, might keep the dupe connections around and fallback to them. 🤔

I couldn't figure out what a "peer" was during the connection event. It seems like metadata information on the socket, but I would think incoming connections should have that too? I think the ID based approach is good for most concerns but it is app level and I can't imagine that I wouldn't want to identify the IP of the remote host. Do I have this concept wrong?

[mafintosh]

Yea a couple of things

Connections are either a TCP stream or a UTP stream (note the T). They act ~ similarly in terms of events/api etc.

When they are done, they emit close. We are still tweaking the internal reconnect logic on this layer btw but will be handled by this stack. Re: duplicate connections, yes you might be one duplicate connection per peer because the TCP/UTP stream emitted is the raw stream. When it can detect dups it does and drop them, but you might wanna run your own dedup logic on top by sending an ID through. We are gonna add a .ban(...) api or similar to help with not reconnecting to dups obvs.

[mafintosh]

For clarity the dups only happen when two hyperswarm peers run with { lookup: true, announce: true} both as they'll each discover each other and cross connect (that's why it's at max one dup per peer).

[whatsdis]

are there any performance degradation with this duplicate connections?

what is the solution here? what if I have multiple peers running with lookup and announce set to true, will this cause any issues for my end users?

[reconbot]

No? Depends on what you do with them I suppose. You just have to account for the fact that one connection !== one peer