We want to play remote games but zeroconf is not available.
Problem
Usually, we would have to run pelita-player --remote TEAM ADDRESS on a server, where ADDRESS is usually of the form tcp://151.11.0.123:12345. Now arbitrary many teams can connect to this address using the remote:tcp://... syntax and will get the chance to play a remote game against the code given in TEAM. (See #769 for syntax changes to make this a bit nicer.)
For additional teams that should be run on the remote server, we will have to run pelita-player with a different port in ADDRESS (and a different TEAM of course).
In networks in which zeroconf is possible, this is not much of a problem, as the URL details will be hidden from the user. When this is not possible, however, remembering the different ports for the different teams is a bit tedious and opaque. Additionally, the firewall on the server has to be changed to let through traffic for each additional team/port.
Proposal
We change the handling of the remote:tcp (future pelita) protocol to have a default port that is used when no port is specified.
We allow the specification of a path to the URL, which will be used to request a specific player from the remote server. This way, we can have one remote service handle all connections to all remote players.
Possible implementation
pelita already uses a zmq DEALER–ROUTER dispatch system in remote games. It should be possible to simply add the path component to the request and have some code on the pelita-player site to have a proper mapping between a path and a TEAM.
As a bonus, there should be a minimal API to see which TEAMs are available and they should optionally be advertised via zeroconf.
tl;dr
instead of
we want to do
Context
We want to play remote games but zeroconf is not available.
Problem
Usually, we would have to run
pelita-player --remote TEAM ADDRESSon a server, whereADDRESSis usually of the formtcp://151.11.0.123:12345. Now arbitrary many teams can connect to this address using theremote:tcp://...syntax and will get the chance to play a remote game against the code given inTEAM. (See #769 for syntax changes to make this a bit nicer.)For additional teams that should be run on the remote server, we will have to run
pelita-playerwith a different port inADDRESS(and a differentTEAMof course).In networks in which zeroconf is possible, this is not much of a problem, as the URL details will be hidden from the user. When this is not possible, however, remembering the different ports for the different teams is a bit tedious and opaque. Additionally, the firewall on the server has to be changed to let through traffic for each additional team/port.
Proposal
remote:tcp(futurepelita) protocol to have a default port that is used when no port is specified.pathto the URL, which will be used to request a specific player from the remote server. This way, we can have one remote service handle all connections to all remote players.Possible implementation
pelita already uses a zmq
DEALER–ROUTERdispatch system in remote games. It should be possible to simply add the path component to the request and have some code on thepelita-playersite to have a proper mapping between a path and a TEAM.As a bonus, there should be a minimal API to see which TEAMs are available and they should optionally be advertised via zeroconf.