Changes between Initial Version and Version 1 of Ticket #2305, comment 16
- Timestamp:
- Jul 9, 2016, 5:49:14 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #2305, comment 16
initial v1 2 2 Part of the message is related to this ticket: 3 3 4 At winter/start of spring (when I had a bit more free time) I've written a test gloox/libnice application (linked in my last comment in the ticket) and I stopped on libnice/enet integration: in 0 A.D. we are using one enet host on host and enet clients for each player (including the host one). libnice seems to be intended to one-to-one interaction, so for each client we need to have a separate agent (or at least a separ ete stream) on host (at least that's the best way I was able to find and the one I implemented in the aforementioned test application), so the only way to integrate libnice I saw was to rewrite the network code sending data via libnice itself (what's probably its intended way of usage, but isn't good in our case) or maybe I needed more time to research.4 At winter/start of spring (when I had a bit more free time) I've written a test gloox/libnice application (linked in my last comment in the ticket) and I stopped on libnice/enet integration: in 0 A.D. we are using one enet host on host and enet clients for each player (including the host one). libnice seems to be intended to one-to-one interaction, so for each client we need to have a separate agent (or at least a separate stream) on host (at least that's the best way I was able to find and the one I implemented in the aforementioned test application), so the only way to integrate libnice I saw was to rewrite the network code sending data via libnice itself (what's probably its intended way of usage, but isn't good in our case) or maybe I needed more time to research. 5 5 6 6 Also earlier Georg suggested on IRC to look at STK implementation of NAT traversal which is done via STUN (which initially (in RFC 3489) was intended as a complete solution, but was reconsidered to be used only as part of higher-level protocols (in particular ICE) later (see RFC 5389)) in which case as far as I understand we are doing a STUN request from the intended host endpoint (generating the inside/outside endpoint mapping on the router and learning the outside one's address/port) and then start a enet host on it (sharing the router's outside endpoint with clients). I looked at the STK code (the STUN request itself is here: https://github.com/supertuxkart/stk-code/blob/master/src/network/protocols/get_public_address.cpp) and had some things to clarify, but then I didn't have enough free time to proceed with it.
