[Doc] Connection Snafu on different Networks

[Spydrouge]

• Purpose: Document (along with other 'debugging network/connection problem' documentation) that connection issues could be owed to computers residing on different networks (and thus run into firewall mishaps)

Making a connection This assumes that the user has a linux and windows machine, and that they are running Opencog's backend on the linux machine (called the 'router') and the unity game world on windows. This also assumes situations with virtual machines are quite similar.

After Opencog has been set up with a cmake & make combo on the linux machine, and the embodiment has had make_distribution run out of the scripts/embodiment folder, the start_embodiment.sh script can be reached in the opencog/build/dist/embodiment/ directory.

TODO: test to make sure this is working properly; I primarily work out of the Unity development environment... If the user is attempting to connect the stand-alone unity player, then the most important thing to do at this point is to make sure they are entering their command line arguments for the router ip address and router port correctly.

If the user is attempting to connect to the unity editor, then the most important thing to do at this point is to edit embodiment.txt to contain the proper router ip address and port.

If a connection fails at this point, then figuring out why might involve a little 'debugging', not necessarily of the code but more likely of the user's setup.

Are you plugged in? Are you connected to the internet? Are you even on the network? The game world won't really tell you if you're not. Neither will Opencog.

Network Snafu We have witnessed that if the router and game world are operating on different networks, they may be unable to find one another. The symptoms for this condition typically involve the two machines sensing one another such that:

• The unity world will print an additional line conveying it found the router and is waiting for a message.
• The linux machine will print it is listening on a port (as of now, that port is 17002) However, no further communication will go on between the machines past this point.

The solution is simply to get both machines working on the same network. We invite our developers to investigate this quirk in an effort to determine where the break in communications may be happening.
This bug was found when one machine was connected to a lan network and another was connecting to a wireless router.