I’d like to propose an implementation of IPv6 for SFML. As yet, nobody makes any pull request, therefore I wish to.
I hope to have returns on this forum. Only after, I’ll make the pull request, as suggested by Laurent Gomila.
State of the artActually, SFML (v. 2.3 rev.746bb9c et previous) doesn’t support IPv6. It means the type
sf::IpAddress and dependencies are implemented around IPv4 only.
Right now on GitHub there is only 1 report on this subject, classed as rejected:
https://github.com/SFML/SFML/issues/307Affected components:- SFML/Network/IpAddress.hpp
- SFML/Network/Socket.hpp
- SFML/Network/TcpSocket.hpp
- SFML/Network/SocketImpl.hpp
static sockaddr_in createAddress(Uint32 address, unsigned short port); - SFML/Network/Unix/SocketImpl .hpp
sockaddr_in SocketImpl::createAddress(Uint32 address, unsigned short port) - SFML/Network/Win32/SocketImpl .hpp
sockaddr_in SocketImpl::createAddress(Uint32 address, unsigned short port)
Several implementation possibilities:split v4 and v6 → YES
- multiple inheritance
sf::IpAddress ―> sf::IpAddressV4
sf::IpAddress ―> sf::IpAddressV6 - a composition
sf::IpAddress ◄►― sf::IpAddressV4
sf::IpAddress ◄►― sf::IpAddressV6 - dynamic type (but it is still a composition, careful of RAII)
- a union
A union type which can store either v4 or v6. Not sure the memory space gain is relevant (almost insignificant) compared to the errors it could cause. But maybe.
Tip: We don’t know which kind of storage structure we need before parsing the given address. So it will always be a treatment in 2 times.
To help judging this different approaches, I have listed the implementations in several notorious libraries:
- Boost
boost::asio::ip::address
v4 & v6 exist as independent types and are merged in the ip::address type by a composition. - C++ Standard Library
std::ip::address (the proposal of Christopher Kohlhoff for C++17 TR2, rejected yet)
same as in Boost, composition, so 2in1. - WxWidget
wxIPaddress ―> wxSockAddress
2in1 through an union but then, this class wxIPaddress is specialized to make specific v6 or v4 daughters. Well, it looks like a nasty mess. - Qt (v5)
QHostAddress
2in1 like Boost. But with their own implementation approach (many test to make it backward compatible).
As first shot, I choose a composition with member values like in
boost::asio (or the next
std::ip).
Use case. How the developer has to use sf::IpAddress?One unique component
sf::IpAddress for the user. Two specific classes for v4 and v6 (priv or not?).
sf::IpAddress is a generalisation of v4 plus v6.
When using
sf::IpAddress, the dev must interest in the type of address he manages… in some cases like sockets.
FixIn the current version, testing if an address in localhost (to make loopback redirections) is on user’s responsibility. Something like:
if ( my_address == sf::IpAddress::LocalHost )But it doesn’t respect the IANA normalisation. IPv4 localhost has the form 127.0.0.1/8, which means addresses from 127.0.0.1 to 127.255.255.255 (/8 means 8 significant bits).
So, if we fix that, the test can’t be user side any more. We need a method
isLocalHost().
On another side IPv6 has only one localhost address ::0.
Naming this method localhost or loopback?« localhost » is a set of addresses. « loopback » is the consequence on path taken. This 2 words are some times interchangeable. However if we only check addresses and not network reality, it’s better to name it localhost, technically.
ExtensionOther domain addresses exist like the Unix type AF_UNIX (which is not ip like AF_INET and AF_INET6). There is also AF_IPX and AF_AX25 (Novell and radio) but very rare.
Unix type is somehow popular. Do we restrict to ip like now?
Also watchChristopher Kohlhoff IPv6 ready:
https://youtu.be/bsoR5m-036U?t=10m10s (I put it at the time he speaks of implementation).
Previous discussion in French on
http://fr.sfml-dev.org/forums/index.php?topic=8782.msg151009#msg151009PS: the mentioned libs are under their own license
Show Posts