Some feedback on self-hosted SDK + suggestion
Options
Perhaps there is some workaround for this I am unaware of, and I am not too much of an expert; just giving my experience. 
I noticed that it is not possible to connect using a public IP to a self-hosted server (using v4-0-29-11263, no matter if MS or GS) with Unity client on latest PUN2 when the client is running on a machine in the same LAN as the self-hosted server. This seems to make development harder, as the multiplayer service cannot be used and the app developed in Unity at the same time when both are running at home on the same network.
Example 1 - Client app tries to connect to an MS running in the same LAN, using the public IP in PhotonServerSettings of course. ClientTimeout results, making it seem like the server is unreachable. But then the PhotonServerSettings is modified to include the internal IP of the MS instead, and the connection works and we are in the MP Lobby. This first one is avoidable once you understand the problem by adding an option ingame to connect to MS using an internal IP for just dev purposes.
Example 2 (The real problem) - A GS, registered with the MS, is running in the same LAN as the client app. The client connects to MS fine, and then calls CreateRoom(). The MS sends the client's own public IP to the client, and disconnects. The client then tries to connect to the GS in it's own LAN using the public IP. Like example 1, ClientTimeout results as the GS appears unreachable. The client needs the internal IP of the GS from the MS in this case to connect to it, as the public IP is of no use here.
This makes self-hosted development harder to do from home, especially for those who may just be stumbling upon these SDKs without significant experience. My desire is to be able to build the Unity client and write plugin code all on one WiFI network. It almost seems now I must find a way to get my MP service on a different network or something now, I hope a solution can be found and it does not come to anything like this. I personally spent a fair deal of time troubleshooting this, ruling things out, and understanding the problem. I wrongly assumed that as the connection request arrived at my gateway, the packets would just go through the correct open ports (since we are trying to connect to photon via UDP 5055 [ex.] to a master, and UDP 5055 is forwarded to the master on the router...) to find the right local machine on the same network.
Perhaps this will just be seen as a silly misunderstanding due to lack of experience; I am not really a huge expert on networking yet. This doesn't change that perhaps what I went through could be avoided for others, maybe by simply adding a note in the 'Analyzing Disconnects/Timeouts' page or something about this at least if we are unwilling to change the SDK. It would have saved some headache in my case.
The 2cents suggestion, unless something much easier can be done:
***The SDK might be changed by allowing the MS to send the internal IP of a registered GS to a client calling CreateRoom(), instead of the public, if necessary. This way when I call CreateRoom() from within the same LAN as the GS, the MS can check whether or not the client app's public IP is the same as the GS, and forward the client to the GS using the internal IP of the GS instead of the public. This could all just be one 'LAN dev' bool or something in config maybe, so that the SDK can work as it does for other use cases unlike mine...
Anyways, hopefully this made some sense. I currently am not sure how to continue working on my MP service and client app under one network. If nothing can be suggested or changed, it appears I will have to move my servers outside of my network, which will be a drag it seems. Thanks for any help about this
EDIT #1 - Very important, forgot to mention: outside connections to my MP service, both MS and GS, work fine. Port forwarding tested with Nmap. I actually should have known earlier, because I know that port forwarding only works when accessing the router's WAN interface from outside the local network so connection request packets hit a dead end at my gateway probably
I noticed that it is not possible to connect using a public IP to a self-hosted server (using v4-0-29-11263, no matter if MS or GS) with Unity client on latest PUN2 when the client is running on a machine in the same LAN as the self-hosted server. This seems to make development harder, as the multiplayer service cannot be used and the app developed in Unity at the same time when both are running at home on the same network.
Example 1 - Client app tries to connect to an MS running in the same LAN, using the public IP in PhotonServerSettings of course. ClientTimeout results, making it seem like the server is unreachable. But then the PhotonServerSettings is modified to include the internal IP of the MS instead, and the connection works and we are in the MP Lobby. This first one is avoidable once you understand the problem by adding an option ingame to connect to MS using an internal IP for just dev purposes.
Example 2 (The real problem) - A GS, registered with the MS, is running in the same LAN as the client app. The client connects to MS fine, and then calls CreateRoom(). The MS sends the client's own public IP to the client, and disconnects. The client then tries to connect to the GS in it's own LAN using the public IP. Like example 1, ClientTimeout results as the GS appears unreachable. The client needs the internal IP of the GS from the MS in this case to connect to it, as the public IP is of no use here.
This makes self-hosted development harder to do from home, especially for those who may just be stumbling upon these SDKs without significant experience. My desire is to be able to build the Unity client and write plugin code all on one WiFI network. It almost seems now I must find a way to get my MP service on a different network or something now, I hope a solution can be found and it does not come to anything like this. I personally spent a fair deal of time troubleshooting this, ruling things out, and understanding the problem. I wrongly assumed that as the connection request arrived at my gateway, the packets would just go through the correct open ports (since we are trying to connect to photon via UDP 5055 [ex.] to a master, and UDP 5055 is forwarded to the master on the router...) to find the right local machine on the same network.
Perhaps this will just be seen as a silly misunderstanding due to lack of experience; I am not really a huge expert on networking yet. This doesn't change that perhaps what I went through could be avoided for others, maybe by simply adding a note in the 'Analyzing Disconnects/Timeouts' page or something about this at least if we are unwilling to change the SDK. It would have saved some headache in my case.
The 2cents suggestion, unless something much easier can be done:
***The SDK might be changed by allowing the MS to send the internal IP of a registered GS to a client calling CreateRoom(), instead of the public, if necessary. This way when I call CreateRoom() from within the same LAN as the GS, the MS can check whether or not the client app's public IP is the same as the GS, and forward the client to the GS using the internal IP of the GS instead of the public. This could all just be one 'LAN dev' bool or something in config maybe, so that the SDK can work as it does for other use cases unlike mine...
Anyways, hopefully this made some sense. I currently am not sure how to continue working on my MP service and client app under one network. If nothing can be suggested or changed, it appears I will have to move my servers outside of my network, which will be a drag it seems. Thanks for any help about this
EDIT #1 - Very important, forgot to mention: outside connections to my MP service, both MS and GS, work fine. Port forwarding tested with Nmap. I actually should have known earlier, because I know that port forwarding only works when accessing the router's WAN interface from outside the local network so connection request packets hit a dead end at my gateway probably
0
Comments
-
hi, @NimbleSprite
Very long reading...
it is difficult to solve your issues with port forwarding because it too many different hardware. I think I managed to connect from my machine to my machine using port forwarding but that was quite long time ago.
Another thing for you is that, it is VERY bad idea to develop and test your new plugin using same instance of photon as your users.
if you need you may start two instances of photon. just assign different ports and it will work
best,
ilya1 -
@chvetsov Thank you, sorry for the very long post, will try to keep it short in future. You at least confirmed I should not be doing things this way which is helpful0
