Thanks @dragon but I’m not the only one checking up on haikuports PR’s, a bit more active as I have some more time atm, will look into it 
EDIT looks like @Diver already merged 
DENetwork Libraries now builds on Haiku. I’ve updated the release on github with the prebuild static library: Release Drag[en]gine Networking Release 1.0.1 · LordOfDragons/denetwork · GitHub
4 Likes
I disagree, having to deal with NAT is hugely annoying. I don’t see any reason to use ipv4 where ipv6 is available.
(and I also dont see why one would use udp when SCTP is available, though granted Haiku does not have an SCTP implementation… oops)
I certainly have not IPv6 available so it would be difficult to implement this at the time being. Right now though I’ve not seen a reason to look into IPv6 harder. At last for the time being. As always, time will tell.
(To make this clearer, my LAN/Server has IPv6, so on LAN I can do IPv6 but for some reason it doesn’t get outside. Something in the way outside my control mucks up).
About SCTP I’ve looked around and I could not find anybody who actually recommended this protocol for game development nor a wide enough support. There seem to be quite some problems with hardware not supporting it. It is possible to discuss about this later on but right now I see no reason to dive into that topic.
I’ll keep notes of the two things though for future evaluation.
For our fritz!box there was an explicit switch to enable ipv6.
For games additionally the protocl to open ports automatically could be really interesting.
I think it is quite sad that many games just use the udp and assume it is reliable aproach and not some of the more interesting methods, sctp with its automatic handover to different ips is really interesting for example for mobile devices that leave a wifi network.
SCTP isnt supported everywhere indeed, vut udp is a “okay” fallback.
My reason for wanting to use DTLS is that for one my game has a chat, and for another this gives a direct way to verify peers with their certs if used, which for a game makes an easy way that impersonating other players is much harder.
Additionally, if we only encrypt “important” information attackers will know where to look, if you encrypt most stuff encryption is seen as normal and it is harder to guage where important information might be.
I tried now implementing IPv6 for linux on DENetwork. This had been a bit annoying to say the least. I can get now connection on my LAN between hosts using IPv6 but I can imagine there are edge cases that can cause troubles, namely if IPv6 or IPv4 should be used to begin with. Will be interesting to see if I get this working on Windows and Haiku too.
Concerning impersonating other players I would claim that this is usually done by nicking weak passwords and other information (human attack) to gain access. I doubt encryption with certificates really help there. But it is an option. I looked at DTLS and it seems you need to use something like OpenSSL. Now I’m a marked child what goes for OpenSSL. Needed to use it on company projects, especially statically linked, and that had been quite the pain to begin with. Maybe something like WolfSSL is better but one has to be careful about the licenses. Places like Unreal Market place deny certain licenses. The world is complicated… especially in game deving.
2 Likes
Haiku has BSecureSocket that should give a “safe” interface to openssl, i don’t think it supports DTLS though, if it does not that may be interesting to implement.
Haiku does have ipv6, but unlike linux it doesnt do this wierd hack where opening a socket makes it listen on both protocols indiscriminately and then translates packages (forgot how it is called)
Haiku does however not have autoconfigure for ipv6 atm, so for most normal users it is conpletely useless.
My idea with certs and DTLS is implement a sort of TOFU auth for my game, where a user can simply connect and then next time be verified as the same user, and servers could vouch to each other.
This is more of a thing where i expect many people to host independent servers though.
You are right that password stealing is a bugger threat, in my case passwords would only need to be set if you want to continue playing on another computer, maybe that is a bit of an oddball idea.
It’s called “Multi-Host” or “Multi-Home”… not sure about the name. I don’t think that’s the standard though. In my tests with the IPv6 code in DENetwork it listens only on IPv6 or IPv4 but not both.
Windows and Java is now IPv6 too. Interestingly “localhost” becomes now “troublesome”. On my c++ code “localhost” resolves to “::1”. On java (same host) “localhost” resolves to “127.0.0.1”. But that doesn’t bother me. Real world code wants to use the first public address and that you can do in DENetwork with the “*” address. On my host this picks the IPv6 one. I think that’s fine.
A quick google tells me Haiku knows “getifaddrs”? If this is true then I could use my new find-public-address code from Linux and use it on Haiku too. The old code uses IOCTL and that supports only IPv4. Gonna test this tomorrow. If so this would wrap IPv6 up quickly.
Concerning passwords and authentication in the end you need some kind of password or “in smartphone key” to authenticate users. And in the case of Steam you even have no choice but to use VAC. So I would not think too much about it right now.
1 Like
What does Valve Anti-Cheat (VAC) have to do with encryption?
Not with encryption but authentication.
Ok so once again:
What does Valve Anti-Cheat (VAC) have to do with encryption authentication?
Quoting from the documentation:
Strong encryption and authentication. When a player connects, you can be sure that if a certain SteamID is authenticated, that someone who has access to that person’s account has authorized the connection. Eavesdropping / tampering requires hacking into the VAC-secured process. Impersonation requires access to the target’s computer.
Hence you can only accept connections if they have been VACed. At last that’s how I understand the documentation.
VAC just uses Session Tickets:
https://partner.steamgames.com/doc/features/auth
Session Tickets are signed tickets that can be used to verify a user’s identity between the user’s game client and any number of other game clients (such as in a peer-to-peer multiplayer session) or to a listen/dedicated game server (using the ISteamGameServer API). These tickets can also be used to verify ownership of the current game and related downloadable content, and determine if the user has been VAC-banned (See Valve Anti-Cheat (VAC) and Game Bans).
ISteamUser in the Steamworks API is more relevant to auth than VAC:
https://partner.steamgames.com/doc/api/ISteamUser
You are not required to use VAC when using the steamworks api iirc.
DENetwork Libraries now has IPv6 also on Haiku but I’m not sure if Haiku actually has IPv6. In a full listing I get “::1” but no IPv6 for the LAN interface. Could be VirtualBox, not sure. But technically it should work.
::1 is the ipv6 loopback adress, we have an ipv6 stack but no autoconfiguration, you can use ipv6 on localhost but it should work in your LAN if you manage to configre the right adress
Updated the Drag[en]gine with IPv6 support too. The 1.14 will contain it or the nightly of course. Time to go back to more important things to do 
5 Likes
Build is OK for 32bit, 64bit buildmaster seems down atm, when it comes up it should pick up the build.
Just some (hopefully constructive) critic:
You have to wade through a lot of pages until you find concrete infos which you need to decide if DragENgine is the right rool for you. Especially the homepage doesn’t direct to some useful info.
As a game developer I ask myself among other questions:
- Which programming language is supported? Is it only DragonScript? Which rapid development tools exist?
- Which OSs are supported? And by which modules?
And another comment: Your approach of radical modularity seems very promising . But I doubt that this can totally eliminate the problems you mention in the documentation. Nontheless it seems a cool engine design/architecture.
Greetings
Peter