In your guide here:
you give this launch command line for the server:
th tools/translation_server.lua -port … -model …
and, this, is only allowing for local access, as shown in you client sample:
sock.connect(“tcp://127.0.0.1:5556”)
It would be nice to also give this ‘host’ option:
th tools/translation_server.lua -host 0.0.0.0 -port … -model …
that allows for a remote client access:
sock.connect(“tcp://XX.XX.XX.XX:5556”)
I highlighted the -host option in the documentation so that users know it is configurable.
However, we don’t enforce any value. Additionally, only allowing local access is a possible use case.
In the output help of tanslate_server.lua, the default value for this host option is said to be “127.0.0.1”. With this value, only local access is allowed.
I searched few hours why my Java client didn’t succeed in its callings. I first thought it was a trouble with the ZMQ Java version I used. I then had the good idea to test your python code, that worked locally on the server, on the remote machine, and found out more precisely that this was coming from a right access on the server. I finally had to search around ZMQ to find the exact explanation and solution.
All this could have been avoided if your documentation would have used the “0.0.0.0” host option in your sample.
I will add a note about that.
Thanks for sharing.
I met errors below when set the host parameter:
It works well WITHOUT host parameter, I mean I can only access the server on the server itself instead of accessing remotely. Any suggestion is much appreciate.
It’s very strange, because it seems to complain about de “-host” option itself, not its value.
I just made a short test, with a wrong value, it even doesn’t complain.
Is it possible that you have copied a invisible char with the “-host” text option ? Did you tried to enter it by hand, to be sure of each char ?
Thanks very much for the hint, I didn’t remember where I copied ‘–host’ instead of ‘-host’, this is the reason. It works now.
