search

chocolate-doom / chocolate-doom

Chocolate Doom is a Doom source port that is minimalist and historically accurate.
https://www.chocolate-doom.org/
GNU General Public License v2.0
1.95k stars 572 forks source link

Add IPv6 Support for Chocolate Doom Network Games #1091

Open MasterO2 opened 6 years ago

MasterO2 commented 6 years ago

Fabian told me to put this on the Chocolate Doom bug tracker, which is why I am posting it here.

I am requesting that IPv6 support be added for Chocolate Doom network games (as well as the other Chocolates).

(Also, if it helps at all as a reference, Zandronum is currently working on it for their own network games:

https://zandronum.com/tracker/view.php?id=214

https://bitbucket.org/zandronum/zandronum-sandbox-stable/commits/all

)

fragglet commented 6 years ago

The main problem is that Chocolate Doom (currently) depends on SDL_net for networking, which doesn't have IPv6 support. I'd be in favour of dropping the dependency though and just using the normal BSD sockets API. The API differences between platforms (even Windows) are small enough that the library probably doesn't buy much.

jmtd commented 6 years ago

Seems interesting. the server hosting the master server for Chocolate Doom is IPv6-enabled, and I have IPv6 at home so I could participate in testing.

MasterO2 commented 6 years ago

Any other comments on this feature request? Implementing this should be a no-brainer. IPv6 is the Internet of the future, so it's going to have to be supported at some point.

jmtd commented 6 years ago

@MasterO2 , do you have IPv6 on your Internet connection?

chungy commented 6 years ago

I have IPv6 Internet. and pretty much all your computers should have at least one fe80::/10 address too, so it's pretty trivial to test basic functionality even without a public address :P

MasterO2 commented 6 years ago

@MasterO2 , do you have IPv6 on your Internet connection?

I do. Also, anyone else on most US-based ISPs will have it now as well, especially if you have Verizon Fios or Comcast. I can't speak for Europe and other parts of the world, though.

MasterO2 commented 5 years ago

The main problem is that Chocolate Doom (currently) depends on SDL_net for networking, which doesn't have IPv6 support. I'd be in favour of dropping the dependency though and just using the normal BSD sockets API. The API differences between platforms (even Windows) are small enough that the library probably doesn't buy much.

So what's the consensus on this? Is Chocolate Doom ultimately going to implement it or not? Judging by what you said above, it's better to just use the BSD sockets API over the SDL_net one.

fragglet commented 5 years ago

I think we have consensus on doing it - someone just needs to step up and do the work.

Alternative would be to contact the SDL developers and see how they'd feel about adding an IPv6 API. Actually, I did this myself over 15 years ago (and was paid to do it) but never got the work merged.

fabiangreffrath commented 5 years ago

Actually, I did this myself over 15 years ago (and was paid to do it) but never got the work merged.

What a massive effort! And what a missed chance to get this implemented in time for the 2.0 release. It's a shame that patches like this could get left ignored and rotting in pre-GIT times.

wallabra commented 3 years ago

@fabiangreffrath I will volunteer to write the code for IPv6 networking in Chocolate Doom.

When I do, should I open PRs in both Chocolate and Crispy Doom, or only Chocolate?

fabiangreffrath commented 3 years ago

When I do, should I open PRs in both Chocolate and Crispy Doom, or only Chocolate?

Only Chocolate, please. I'll pull the necessary changes once they are accepted.

wallabra commented 3 years ago

Ah, alright. Thank you! Was just wondering :D

OpenRift412 commented 3 years ago

Just curious, what kind of effect would this have on network performance? Would it be anything noticeable or is it more of just an attempt at future-proofing?

wallabra commented 3 years ago

@fabiangreffrath How should I handle the platform agnostism?

I plan to have a single header with common definitions, and another one for extern declarations to be implemented by a file that is chosen by platform (e.g. net_socket_linux, net_socket_win32, etc).

Just curious, what kind of effect would this have on network performance? Would it be anything noticeable or is it more of just an attempt at future-proofing?

It's mostly just so IPv6 addresses can be supported. There is a whole variety of reasons to support IPv6, like for instance hosts which are behind NATs and whose IPv4 addresses aren't reachable.

Also, simply not requiring SDL_net anymore is a good reason to if you ask me :D

fragglet commented 3 years ago

and another one for extern declarations to be implemented by a file that is chosen by platform (e.g. net_socket_linux, net_socket_win32, etc).

This probably isn't necessary. The Windows sockets API (WinSock) is based on the BSD sockets API that every other OS implements. There are some differences (like the SOCKET type used on Windows, and some function names like InetNtop which use the wrong style), but you can paper over them with some simple #defines. I advise studying the SDL_net source code closely to see how it does things.

MasterO2 commented 3 years ago

Anything new on this issue, @Gustavo6046?

wallabra commented 3 years ago

Anything new on this issue, @Gustavo6046?

Oh, I kind of forgot about this. I will take a look at it momentarily. I've been very distracted lately, and absent-minded when I'm not.

wallabra commented 3 years ago

Yes I think I'm ready now. I have more free time so I can do something :)

MasterO2 commented 3 years ago

Yes I think I'm ready now. I have more free time so I can do something :)

@gustavo6046 Any progress?

wallabra commented 3 years ago

I already have a fork of Crispy Doom on my account, so GitHub doesn't let me fork Chocolate Doom (since technically the former is a fork of the latter). I was going to figure that out, but I procrastinated and forgot :p

Jeez, I'm sorry, this is not my usual progress rate. Either way, you can see if I'm doing anything once I have the fork set up - any progress, like commits etc., should be displayed in the respective branch when I do.

MasterO2 commented 3 years ago

I already have a fork of Crispy Doom on my account, so GitHub doesn't let me fork Chocolate Doom (since technically the former is a fork of the latter). I was going to figure that out, but I procrastinated and forgot :p

Jeez, I'm sorry, this is not my usual progress rate. Either way, you can see if I'm doing anything once I have the fork set up - any progress, like commits etc., should be displayed in the respective branch when I do.

Procrastination is always a formidable opponent. :D