Possible (?) developments
Last updated
Was this helpful?
Last updated
Was this helpful?
This is unknown territory for me and will stay so until at least I get the beta, and more probably until the official launch of the product.
There should remain a virtual table access/communication mode of the same kind as FG "Classic", but also some much awaited "MMO-like" features like a lobby, etc.., supposedly freeing the GMs from the port forwarding issue.
That would probably mean that SmiteWorks maintain some kind of central routing platform (?) handling inbound communications for the live virtual tables from GMs+Players ???
That would also probably need to be globally deployed, to be viable on a worldwide scale, and that makes me wonder about running costs ???
Enough what-ifs !
I'm ignorant on what can actually be done with Unity network features, so I'll just have to look at the new FGU networking when I can test the beast...
One drawback of this setup is under-utilization : it uses a complete server virtual machine for only 1 GM at a time, because the server only has 1 public IPv4 address (to avoid costs). With the smallest possible virtual server at AWS (currently 1 virtual processor + 512MB RAM), the CPU is used less than 0.5% ! What a waste !
While using multiple public IPs is an option, it requires using "Elastic IP Addresses" (EIP) at AWS, which are fixed public IP addresses that are reserved for your account when allocated, but they are free ONLY when attached to a RUNNING server as the ONLY public IP for that server :
the first EIP attached to a running virtuall server is free
an additional EIP attached to the same running server will cost $0.005 /Hour +VAT
an unattached EIP, or an EIP attached to a stopped server will also cost $0.005 /Hour +VAT
That means (as of june 2019) for an unused/second EIP : around $4.4 /month, VAT included.
Also, an EIP is attached to a network interface, of which there can be only a limited number per server depending on its type, and of course the smallest/cheapest servers can only have 2 interfaces => a maximum of 2 concurrent GMs that could be reached from players on EIP1/1802 + EIP2/1802.
And finally, the "create on use, destroy when finished" strategy we use for the server would leave the EIP(s) unattached => billable...
So, the only way i see to "mutliplex" is on the client side (i.e. the player machine), to introduce proxying and redirect an outbound connection to TCP 1802 towards another (IP+)port. The best way to do that for a player is to use the localhost (127.0.0.1) address as the connection target, and intercept 127.0.0.1/TCP 1802 inbound connections to redirect them.
lightweight, simple, NO permanent setting left behind...
This is what I tested :
We can have concurent GMs connected to the VPN server, each with his own fixed VPN private IP PrvIPnn (using the GMs' certificate identity and the ccd="client config directory" feature of OpenVPN) and with corresponding PrvIPn-specific port forwarding rules installed in the VPN server :
GM1 always gets private IP PrvIP1 in the VPN when connecting to OpenVPN (configured in ccd)
GM2 always gets private IP PrvIP2 in the VPN when connecting to OpenVPN (configured in ccd)
the server listens to ports p1 and p2 (ex: 18021 and 18022) on its single public IP : PubIP
1 forwarding for PubIP/p1 <=> PrvIP1/1802 for GM1
1 forwarding for PubIP/p2 <=> PrvIP2/1802 for GM2
So the problem is to find a way, for a session (NOT permanently : we don't want to "lock" players to a specific GM and we absolutely don't want to modify anything in the players' machine), for :
players A, B, C to have their FG connect to PubIP/P1 to get into GM1's virtual table
players X, Y, Z to have their FG connect to PubIP/P2 to get into GM2's virtual table
Still only 1 public IP but 2 different TCP ports => 2 FG virtual tables at a time, and that can be generalized to a higher number than 2 of course...
config line for players A, B, C : 127.0.0.1 1802 (PubIP) (p1)
config line for players X, Y, Z : 127.0.0.1 1802 (PubIP) (p2)
Then after the session, the players kill their rinetd / close their command prompt window.
Done !
Unfortunately that defeats our "transparency" objective :
Diag.tools, common commands etc...
Not sure it would be useful : there are already sooo many examples everywhere.....
If interest appears for "own closed VPN" for example...
However we have one issue for FG "Classic" : FG "Join Game" connects exclusively to TCP 1802 on the target server, and I didn't find anything where you can override this behaviour, and since with only 1 public IP, there can be only 1 "listener" on TCP 1802 for inbound connections...
The solution exposed below is still valid, but I think the new section provides a more elegant/easy to use solution.
It relies on the ability to use another TCP port than 1802 when launching FG "Classic", which I finally discovered after 2 years using the program...
I have successfully tested setups with the old utility with a very simple 1-line config file, and that is the "best" (least bad) solution i found for Windows :
It is also achievable with netsh interface proxyport on modern versions of Windows, but it is very awkward, needing Windows admin access and creating a permanent redirect that you have to delete afterwards...
That can be achieved with the players running in a background command prompt window before they connect to their GM by using localhost as the "host address" : their "player FG" will connect to 127.0.0.1:1802 and rinetd will redirect that according to its config :
Even if it's not a VPN client install, it's still a specific config to manage for the players (1 small exe + a 1-line config file to keep somewhere, and run when needed), so the solution becomes "NOT transparent" for the players.
That could be acceptable for a regular group (GM + Players) for a whole campaign...
...But it would not be viable for ephemeral things like 1shot games, FGC classes, etc...
So : no satisfying (transparent) free workaround on my side for the moment...sorry !
After I finish this exhausting doc writing exercise, I plan to build a small basic operations admin bot for my own OpenVPN + Discord : launch, terminate, start, stop, reboot + getting the public IP (+updating DNS name in Route53)
This will be based on ideas I found while prowling the ...............and all unmentionable places where a role playing dino can lurk...
