Sending MissionInit doesn't return when the given client doesn't have a running minecraft instance

[lydiatliu]

The following line is printed
DEBUG: Sending MissionInit to 10.190.103.109 : 10000
where 10.190.103.109 : 10000 is my local machine that is not running a minecraft client.
but Malmo stays there and doesn't go on to try the rest of the clients in my client pool.

i'm running Malmo from a Linux cluster.

[timhutton]

Not sure we can do anything about this. Suspect it's the TCP timeout setting on the machine.

Closing for now, until get more information.

[DaveyBiggers]

I'm getting this problem in a multi-agent scenario.
Python essentially hangs - the last thing displayed is:

DEBUG: Sending find server request to 127.0.0.1 : 10003

By mistake I'd left 127.0.0.1:10003 in the client pool, though I have no Minecraft instance running on that port.
netstat gives some interesting details:

netstat -a -o | grep 10003
  TCP    0.0.0.0:10003          MSRC-3617251:0         LISTENING       18904
  TCP    127.0.0.1:10003        MSRC-3617251:34613     ESTABLISHED     18904
  TCP    127.0.0.1:34613        MSRC-3617251:10003     ESTABLISHED     18904

18904 is PID of my python process. It seems to have established a link to... itself?
Am trying to reproduce this in the single agent case.

[DaveyBiggers]

Have created a python script that constantly tries to connect to port 10003, and left four instances of it running overnight. Everything still happy in the morning - no spurious connections. Must be something else going on here...

[DaveyBiggers]

Okay, so this is an actual thing, apparently - http://stackoverflow.com/questions/4949858/how-can-you-have-a-tcp-connection-back-to-the-same-port
TCP allows for "simultaneous connect", so it's possible for our client to connect to itself by accident. Most common workaround seems to be to use a different (non-ephemeral) port range, but that would break a fair bit of existing research code. Will look for other solutions.