| | 1 | |
| | 2 | == Socket Rework == |
| | 3 | The current state of socket handling of openvpn is suboptimal. It lacks proper support of dual stack environments. There are some design decisions to be made beforehand. This a first list of things that should be discussed before beginning a rewrite. |
| | 4 | |
| | 5 | * Meaning of udp, udp6. At the moment udp forces AF_INET and udp6 AF_INET6. If no udp/tcp is specified the client will guess ipv4/ipv6 and stick to that guess |
| | 6 | * Change udp to AF_INET/AF_INET6, add udp4 |
| | 7 | |
| | 8 | * tcp design is straightfoward |
| | 9 | * tcp-server resolves address with AI_PASSIVE, bind to all returned results |
| | 10 | * tcp-client resolve all adresses, iterate through them in the returned order |
| | 11 | * as for udp, introduce tcp4 |
| | 12 | |
| | 13 | * Behaviour of udp p2p clients, now it is simply only socket is open for both peers, in dual stack this assumption breaks |
| | 14 | * introduce udp-server and udp-client. Let udp-server bind/listen on all socket and udp-client only on the one currently trying to connect |
| | 15 | * Both peer bind on all sockets but iterate through the socket when trying to connect |
| | 16 | |
| | 17 | * behaviour of bind/remote if they different in the returned protocols |
| | 18 | * bind only IPv4 but remote IPv4/IPv6, issue warning |
| | 19 | * bind only IPv4 and remote IPv6, exit with error |
| | 20 | |
| | 21 | * Listening on multiple sockets is needed for dual stack anyway. So simultaneous udp/tcp is possible too: |
| | 22 | * <listen> like <connection> but uses all <listen> blocks at the same time |
| | 23 | |
