Internal server connections work, external doesn't

White Rabbit

We have successfully connected our game through our in-house server using local IP addresses. This server is on the Comcast network, and their modem doesn't have internal loopback, so we just started trying to test using an external connection. It fails.

Internal connections are working fine.
Someone tries to connect from outside the LAN through our static IP, they get these error messages :

4032828: Receiving failed. SocketException:ConnectionReset
4032828: OnPeerStatusCallback - unexpected return code Disconnect

I have port 5055 and 4530 open on the firewall. Port 80 is also open and our website is working fine both externally and internally through the same static IP.

We're testing to a connection in Poland.. Ping latency is about 150ms. Remote site is trying to connect using the Stardust client, which works fine on our LAN.

Also - trying to find in the documentation an explanation of "reliable" vs. "unreliable" data -- can someone point the way to that?

dreamora

Reliable means the packet is sent until its received and reception is confirmed. Reliable also means ordered so the order in which you send data will be the order in which it will be received (packages received later will be postphoned from processing until the previous ones are received)

Unreliable just is 'sent without caring about it being received', which is normally used for high frequency low latency data like position updates where it doesn't matter if one of the 30 or so updates a second went missing cause the prediction can handle half a dozen to a dozen lost packets easily (ie higher latency). You send these unrealiable cause you don't want other packets to wait, even more so cause those other packets that are waiting likely are again position updates for example which would have made this one obsolete anyway

White Rabbit

I don't want to detract from the main question - not being able to access the photon server from outside our local network is a showstopper - but does the reliable switch apply only to TCP (which I had thought was inherently "reliable" at least as far as acknowledgement goes) or is there also an application to UDP?

dreamora

TCP is always reliable, it does not even have the option to be not reliable (thats a fundamental part of tcp protocol)
Only UDP has the option to decide if it is reliable or unrealiable as its software that creates the reliable, ordered behavior there (udp can through code be made to TCP if you want, but not vice versa)

Port 5055 you forwarded from router and on your firewall is for UDP right? (assuming you use udp at all, 5055 is the udp port, 45xx the tcp, at least in the default configs)

Also, cause you didn't mention anything:

Basing on which Photon Application did you develop it? (on loadbalancing base you would need ot change the server port on the gameserver1 and gameserver2 for example to your external one as well)
And are you potentially using unity webplayer, cause then you also need to open tcp 845 for the policy socket server required by unity webplayers to talk to any remote socket.

White Rabbit

We're just trying to run a simple access test using Photon's Stardust client which is TCP, port 4530 and, I assume derived from Lite since it is using Instance1 and not Loadbalancing. The configuration file that works for the machines that are on the LAN is the same one used for the external machine. All we did was take the Stardust client and modify the one line in its config file to reflect our static IP address. The static IP address hits our gateway where it is translated to the local port address for the server. There is a website at the static IP address that works remotely without a problem.

White Rabbit

As a followup, I ran Wireshark on both the internal and external clients. The external machine, running Stardust, is sending and receiving data to/from the photon server but the connection fails with the same messages posted at the beginning of this thread. Machines on the LAN are successful, as mentioned before. So, we know that the ports are open, and that Photon is communicating with the Stardust client on both LAN and WAN machines, but for some reason, the WAN connection fails.

dreamora

Thats totally strange ... is there some hw firewall inbetween or an agressive software firewall that inspects the packets upon transition through the wall and then just kills the line? I've not seen such missbehaviors for years ... last time on zone alarm 7 or so which totally missbehaved in their first multicore usable version, where it started to cap connections upon its own discretion without even logging

White Rabbit

LInes aren't killed... if you compare the two traces, they match up, but one message results in an immediate (< 1 ms) RST return from Photon, the other doesn't. The packets are different but similar in size and composition. Without Photon source, there is no way to debug what is going on, but something in the remote packet causes the photon server to respond with an RST.

White Rabbit

Problem found. We hadn't noticed that a newer version of Photon had been released.. We were running 3.0.6. After updating both server and client to 3.0.12 everything started working.