Setup for the client to use TCP

benjamlbenjaml
edited January 30 in Native
Hello,

As I only use reliable message, I want to setup the loadbalancing client to use TCP. But when I change the ConnectionProtocol un the client constructor, I can't get it to connect to the photon cloud. Is there something else that I should setup. What are the changes that I will have to do to change the previous usage with the UDP connection protocol to TCP ?

One of the biggest issue that I have right now is that I need to send files to all the connected players. I think that the TCP protocol will help me to avoid sending a lot of chunk with the 1200 byte limit of UDP, which will avoid me to largelly dicrease the number of chunk of those messages.
«1

Comments

  • Hi @benjaml.

    Passing
    ConnectionProtocol::TCP
    
    to the Constructor of class
    Client
    
    is all that you you need to do. Please verify if it works for you in our demos.
    One of the biggest issue that I have right now is that I need to send files to all the connected players.
    Photon is not a a file-server. When you need to send around files between players it is usually better to let one client upload them to a http-server via some non-Photon APIs and then just send around a download link to the other clients inside Photon.

    Note that Photon Cloud has a per player data buffer of 500kb. If you send more than 500kb at once or in a very short time, then that buffer might overflow and the affected client will receive a disconnect. Everything up to 500kb should work fine with TCP on Photon Cloud.

    This per-player buffer is a server side config value and you can increase it on a self-hosted Photon server or ask us to increase it for you in Photon Enterprise Cloud. It is not adjustable on Photon Public or Premium Cloud. You could even run your own Photon server as a file-server and one the Client side create 2 Client instances of which you let one connect to Photon Cloud for actual game play and one to your self-hosted Photon server that acts as a file-server. Over TCP connections to such a server even transferring files that are several dozen megabytes in size has proven to work well under production conditions when using the Photon C++ Client. However Photon is not optimized for such usage, so you would likely get a better bang per buck ratio for your file-transfers with a HTTP file server.
  • benjamlbenjaml
    edited January 31
    I did try to set the connectionProtocol to TCP in the demo_windows_loadbalancing_vc15 solution but I got this result
    connecting to Photon
    2020-01-31 09:28:17,840 INFO    peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::connect()             128   address: ns.exitgames.com:4533
    2020-01-31 09:28:18,160 INFO    client.cpp                     ExitGames::LoadBalancing::Client::onStatusChanged()          2008  connected to nameserver
    2020-01-31 09:28:18,475 INFO    client.cpp                     ExitGames::LoadBalancing::Client::onOperationResponse()      1594  OperationResponse - operationCode: 220, returnCode: 0
    2020-01-31 09:28:18,483 INFO    networklogic.cpp               NetworkLogic::onAvailableRegions()                           580   ["eu", "us", "usw", "cae", "asia", "jp", "au", "sa", "in", "ru", "rue", "kr"] / ["92.38.154.7:4530", "92.223.82.17:4530", "5.188.110.5:4530", "169.54.101.108:4530", "92.38.183.13:4530", "5.8.70.143:4530", "146.185.221.6:4530", "5.188.239.5:4530", "169.38.88.110:4530", "5.188.170.5:4530", "92.38.191.5:4530", "92.38.165.229:4530"]
    onAvailableRegions: ["eu", "us", "usw", "cae", "asia", "jp", "au", "sa", "in", "ru", "rue", "kr"] / ["92.38.154.7:4530", "92.223.82.17:4530", "5.188.110.5:4530", "169.54.101.108:4530", "92.38.183.13:4530", "5.8.70.143:4530", "146.185.221.6:4530", "5.188.239.5:4530", "169.38.88.110:4530", "5.188.170.5:4530", "92.38.191.5:4530", "92.38.165.229:4530"]
    selecting region: eu
    2020-01-31 09:28:18,510 INFO    peer.cpp                       ExitGames::LoadBalancing::Peer::opAuthenticate()             155   OperationRequest - operationCode: 230 {211=true, 224="<app-ID edited out>", 220="1.0", 210="eu"}
    2020-01-31 09:28:28,484 INFO    tpeer.cpp                      ExitGames::Photon::Internal::TPeer::serviceBasic()           72    disconnect due to a timeout - time: 69649718   time of last receive: 69639703
    2020-01-31 09:28:28,490 ERROR   networklogic.cpp               NetworkLogic::connectionErrorReturn()                        371   code: 1040
    received connection error 1040
    2020-01-31 09:28:28,496 INFO    networklogic.cpp               NetworkLogic::disconnectReturn()                             441
    disconnected
    
  • Hi @benjaml.

    Interesting. It works fine for me.
    Which version number of the Client SDK are you using and did you change anything else than setting the appID and passing the value ConnectionProtocol::TCP for the connection protocol?

    Also please check if it works for you when you connect to a Photon server instance that runs on your local machine. Also please check your firewall and router.

    Last but not least could you please give me the log with the DebugLevel set to Debuglevel::ALL?

    PS: I have edited out your appID from the log. Please pay attention to take it out before sending your log output on a public channel like the forum. Otherwise someone else could just take your appID and run his app on your account.
  • I did try with the local server it work well but with the photon cloud it's not working. Maybe it's from the firewall but I have no idea of what to configure to make it work.

    here is the logs with the DebugLevel to ALL
    connecting to Photon
    2020-02-03 16:50:34,697 INFO    peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::connect()             128   address: ns.exitgames.com:4533
    2020-02-03 16:50:35,017 INFO    client.cpp                     ExitGames::LoadBalancing::Client::onStatusChanged()          2008  connected to nameserver
    2020-02-03 16:50:35,337 INFO    client.cpp                     ExitGames::LoadBalancing::Client::onOperationResponse()      1594  OperationResponse - operationCode: 220, returnCode: 0
    2020-02-03 16:50:35,345 INFO    networklogic.cpp               NetworkLogic::onAvailableRegions()                           580   ["eu", "us", "usw", "cae", "asia", "jp", "au", "sa", "in", "ru", "rue", "kr"] / ["92.38.154.7:4530", "92.223.82.17:4530", "5.188.110.5:4530", "169.54.101.108:4530", "92.38.183.13:4530", "5.8.70.143:4530", "146.185.221.6:4530", "5.188.239.5:4530", "169.38.88.110:4530", "5.188.170.5:4530", "92.38.191.5:4530", "92.38.165.229:4530"]
    onAvailableRegions: ["eu", "us", "usw", "cae", "asia", "jp", "au", "sa", "in", "ru", "rue", "kr"] / ["92.38.154.7:4530", "92.223.82.17:4530", "5.188.110.5:4530", "169.54.101.108:4530", "92.38.183.13:4530", "5.8.70.143:4530", "146.185.221.6:4530", "5.188.239.5:4530", "169.38.88.110:4530", "5.188.170.5:4530", "92.38.191.5:4530", "92.38.165.229:4530"]
    selecting region: eu
    2020-02-03 16:50:35,372 INFO    peer.cpp                       ExitGames::LoadBalancing::Peer::opAuthenticate()             155   OperationRequest - operationCode: 230 {211=true, 224="<App_Id>", 220="1.0", 210="eu"}
    2020-02-03 16:50:45,354 INFO    tpeer.cpp                      ExitGames::Photon::Internal::TPeer::serviceBasic()           72    disconnect due to a timeout - time: 4082062   time of last receive: 4072046
    2020-02-03 16:50:45,361 ERROR   networklogic.cpp               NetworkLogic::connectionErrorReturn()                        371   code: 1040
    received connection error 1040
    2020-02-03 16:50:45,368 INFO    networklogic.cpp               NetworkLogic::disconnectReturn()                             441
    disconnected
    
  • Hi @benjaml.
    here is the logs with the DebugLevel to ALL
    I am afraid that The logging level is only set to 'INFO' in that log. Otherwise there would be quite a lot of lines with level 'DEBUG' in that log.

    In demo_loadBalancing in NetworkLogic.cpp there is the following line in the constructor:
    mLoadBalancingClient.setDebugOutputLevel(DEBUG_RELEASE(ExitGames::Common::DebugLevel::INFO, ExitGames::Common::DebugLevel::WARNINGS));
    

    You need to change that line to
    mLoadBalancingClient.setDebugOutputLevel(DEBUG_RELEASE(ExitGames::Common::DebugLevel::ALL, ExitGames::Common::DebugLevel::WARNINGS));
    
    to set the DebugLevel to 'ALL' for debug configs or to
    mLoadBalancingClient.setDebugOutputLevel(ExitGames::Common::DebugLevel::ALL);
    
    to set it to 'ALL' for debug and realese configs.

    Maybe it's from the firewall but I have no idea of what to configure to make it work.
    A start would be to temporarily disable the firewall completely and check if that helps. That's obviously not a long-term solution, but just a quick way to figure out if the firewall is the culprit or if the problem is caused by something else.
    If it should work with a deactivated firewall, then you need to figure out how to configure your firewall to let the TCP traffic from the Photon demo apps and from your Photon apps through.
    Normally it should work out of the box as the client initiates the connection and most firewalls in default settings don't block connections that have been initiated from the local machine, but maybe yours is configured more restrictive.

    Photon uses the ports 4530, 4531 and 4533 with 'ConnectionProtocol::TCP', so you need to allow traffic over those ports for all apps which you want to be able to connect to Photon Cloud over TCP.
    Note that you need to open these ports for all remote IP addresses as there are hundreds of server machines running in Photon Cloud and we regularly add and remove machines on the fly, so it is impossible to give out a range or list of server IP addresses that are in use by Photon Cloud.
  • My bad here is the real logs :
    2020-02-04 10:12:03,894 INFO    peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::connect()             128   address: ns.exitgames.com:4533
    2020-02-04 10:12:03,900 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::reset()               111
    2020-02-04 10:12:03,905 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:03,916 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:03,921 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,027 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:04,032 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,039 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,149 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:04,156 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,160 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,266 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::onConnect()           419
    2020-02-04 10:12:04,270 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::send()                   253   cType: 1 payloadSize: 48
    2020-02-04 10:12:04,276 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,280 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:04,287 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,293 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,399 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::onReceiveData()          195   length = 3, error = 0
    2020-02-04 10:12:04,405 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:04,410 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,414 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::deserializeOperation() 513
    2020-02-04 10:12:04,418 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::deserializeOperation() 532   bodyBuff: 3, msgType: 1 (event = 4)
    2020-02-04 10:12:04,424 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::initCallback()        838   < read init
    2020-02-04 10:12:04,428 INFO    client.cpp                     ExitGames::LoadBalancing::Client::onStatusChanged()          2008  connected to nameserver
    2020-02-04 10:12:04,434 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::serializeOperation()  461
    2020-02-04 10:12:04,439 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::send()                   253   cType: 6 payloadSize: 114
    2020-02-04 10:12:04,444 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,448 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,553 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::onReceiveData()          195   length = 2, error = 0
    2020-02-04 10:12:04,558 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::updateRoundTripTimeAndVariance() 695
    2020-02-04 10:12:04,563 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    
  • 2020-02-04 10:12:04,567 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,573 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,679 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::onReceiveData()          195   length = 110, error = 0
    2020-02-04 10:12:04,685 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:04,691 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,697 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::deserializeOperation() 513
    2020-02-04 10:12:04,707 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::deserializeOperation() 532   bodyBuff: 110, msgType: 7 (event = 4)
    2020-02-04 10:12:04,717 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::serializeOperation()  461
    2020-02-04 10:12:04,723 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::send()                   253   cType: 6 payloadSize: 57
    2020-02-04 10:12:04,728 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,734 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:04,839 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::onReceiveData()          195   length = 306, error = 0
    2020-02-04 10:12:04,845 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:04,849 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,853 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::deserializeOperation() 513
    2020-02-04 10:12:04,858 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::deserializeOperation() 532   bodyBuff: 306, msgType: 3 (event = 4)
    2020-02-04 10:12:04,868 INFO    client.cpp                     ExitGames::LoadBalancing::Client::onOperationResponse()      1594  OperationResponse - operationCode: 220, returnCode: 0
    2020-02-04 10:12:04,874 INFO    networklogic.cpp               NetworkLogic::onAvailableRegions()                           580   ["eu", "us", "usw", "cae", "asia", "jp", "au", "sa", "in", "ru", "rue", "kr"] / ["92.38.154.7:4530", "92.223.82.17:4530", "5.188.110.5:4530", "169.54.101.108:4530", "92.38.183.13:4530", "5.8.70.143:4530", "146.185.221.6:4530", "5.188.239.5:4530", "169.38.88.110:4530", "5.188.170.5:4530", "92.38.191.5:4530", "92.38.165.229:4530"]
    onAvailableRegions: ["eu", "us", "usw", "cae", "asia", "jp", "au", "sa", "in", "ru", "rue", "kr"] / ["92.38.154.7:4530", "92.223.82.17:4530", "5.188.110.5:4530", "169.54.101.108:4530", "92.38.183.13:4530", "5.8.70.143:4530", "146.185.221.6:4530", "5.188.239.5:4530", "169.38.88.110:4530", "5.188.170.5:4530", "92.38.191.5:4530", "92.38.165.229:4530"]
    selecting region: eu
    2020-02-04 10:12:04,903 INFO    peer.cpp                       ExitGames::LoadBalancing::Peer::opAuthenticate()             155   OperationRequest - operationCode: 230 {211=true, 224="<app-id>", 220="1.0", 210="eu"}
    2020-02-04 10:12:04,912 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::serializeOperation()  461
    2020-02-04 10:12:04,918 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::send()                   253   cType: 6 payloadSize: 73
    2020-02-04 10:12:04,924 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:04,927 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    2020-02-04 10:12:05,033 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::service()             203   dispatch == true
    2020-02-04 10:12:05,048 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::dispatchIncomingCommands() 151
    2020-02-04 10:12:05,052 DEBUG   tpeer.cpp                      ExitGames::Photon::Internal::TPeer::sendOutgoingCommands()   83
    ...
    2020-02-04 10:12:14,919 INFO    tpeer.cpp                      ExitGames::Photon::Internal::TPeer::serviceBasic()           72    disconnect due to a timeout - time: 66571968   time of last receive: 66561890
    2020-02-04 10:12:14,930 ERROR   networklogic.cpp               NetworkLogic::connectionErrorReturn()                        371   code: 1040
    received connection error 1040
    2020-02-04 10:12:14,935 DEBUG   peerbase.cpp                   ExitGames::Photon::Internal::PeerBase::onDisconnected()      449
    2020-02-04 10:12:14,940 INFO    networklogic.cpp               NetworkLogic::disconnectReturn()                             441
    disconnected
    
  • Hi @benjaml.

    As you can see at the end of your log, there is a timespan of about 10 seconds without any log at all right before the disconnect. It appears like you are not calling service(), not sendOutgoingCommands(), not sendAcksOnly() during this time. Hence the client can't send out any life sign to the server and hence the server considers the client to be dead and disconnects it.

    I have no idea why this is only happening for you, when you use TCP, but I can't reproduce it here: I see lots of service() and sendOutgoingCommands() calls in the logs when I run with TCP as selected protocol. Maybe there is something in your code that is blocking the service() calls?
  • I do call services, I just removed them to replace by ... to shorten the logs
  • Hi @benjaml.
    I do call services, I just removed them to replace by ... to shorten the logs
    Sorry. I did not realize that.

    At 10:12:04,903 the the authentication operation request with the selected region is made. Shortly afterwards the client should receive an operation response by the server for that operation. However this message apparently never arrives, nor does anything else apparently make it through from that moment onwards.

    That does not really make any sense to me. If it was a firewall issue, then the prior opGetRegions() operation should not be able to receive a response either. However that it works with a locally running server indicates that the code should be fine.

    Can you try running the client from a different machine on a different network and see if you get the same results i.e. at home and in the office, please?
  • PS: Could you also please provide a Wireshark capture of the traffic between the client and Photon Cloud?

    For your privacy you can filter out everything that does not have port 4533 either as source or as destination port.
  • I'm not really used to Wireshark but I think that I exported the packet related to the port 4533
    https://gofile.io/?c=rZNduR

    I cannot test on another machine on a different network for now I'll try it back home after work
  • Hi @benjaml.

    The Wireshark capture shows that the client resends the authentication request several times, but that at that time the server does not send anything at all anymore after the getRegions response.

    One more thing that I would like you to try:
    In Peer.cpp there is a Peer::opAuthenticate() function, which includes an encrypted parameter, which should have the value true.
    Please override it with false and see if that makes a difference.

    Furthermore would you please let me know the Client SDK version number that you are using?
  • Hi @Kaiserludi

    I'm using the photon-windows-sdk_v4-1-14-0. One of my coworker succeed to make the TCP work with the Client sample and a client application. Maybe I cannot use TCP with photon realtime applications ?
  • Changing the encryption to false, does not seem to change anything however i'm not 100% sure it does take my modifications is there a way to be sure that the encryption is disabled ?
  • Hi @benjaml.

    I have now also tried with 4.1.14.0 and it works for me with TCP just fine.
    i'm not 100% sure it does take my modifications is there a way to be sure that the encryption is disabled ?
    Well, you could add an EGLOG() call to opAuthenticate() that prints the value of 'encrypted' or you can set a breakpoint to inspect the variable.
    One of my coworker succeed to make the TCP work with the Client sample and a client application. Maybe I cannot use TCP with photon realtime applications ?
    I don't understand what you mean. Could you rephrase that, please? What do you mean when you say "client application" vs "realtime application"?
  • benjamlbenjaml
    edited February 5
    hi @Kaiserludi

    ok now I'm 100% and it does not make any difference. I mean that one of my coworker succesfully make it work with the chat sample and a chat application on photon cloud.

  • Hi @benjaml.

    Does it work with a LoadBalancing Client and a Realtime application for your coworker, when using TCP?
    Does it work with a Chat Client and a Chat application for your, when using TCP?

    TCP should definitely work with Realtime just like with Chat. The TCP implementation is part of Photon-cpp and LoadBalancing-cpp and Chat-cpp both sit on top of the exact same Photon-cpp implementation.
  • benjamlbenjaml
    edited February 5
    Hi @Kaiserludi
    Does it work with a LoadBalancing Client and a Realtime application for your coworker, when using TCP?

    No
    Does it work with a Chat Client and a Chat application for your, when using TCP?

    No
  • Hi @benjaml.

    OK. Now I am lost. I have no idea how it could be that it works for your coworker with Chat, but not with Realtime.
    Did it work for you when you tested at home yesterday?
  • Hi @Kaiserludi

    So I did missunderstood my coworker, he was using the pun2 demo from the unity asset store. So I did test it also and I can use TCP with the pun2 demo aswell. But with the demo 'demo_windows_loadBalancing_vc15' in which I only changed the ConnectionProtocal from DEFAULT to TCP and set the application id of the photon realtime application on the photon cloud, I get the logs that I previously send to you.

    but on your side you said that it do work fine.

    I forgot to test it at home, but I did setup an alarm to not forget tonight
  • Hi @benjaml.
    'demo_windows_loadBalancing_vc15'
    You are opening the demo project/solution in Visual Studio 2017, right? Not in any other VS version?
  • benjamlbenjaml
    edited February 5
    Hi @Kaiserludi

    Yes I use visual studio 2017, I'm only retargeting the project to another windows sdk version (10.0.18362.0)
  • Hi @benjaml.
    I'm only retargeting the project to another windows sdk version
    Why are you doing that? That option is not relevant for Desktop applications and VS should not ask you to do that. I am running the project on Windows 10 with that target been set to the default value of Windows 8.1 and VS 2017 does not care.
    That setting AFAIK is relevant for Store apps only.
  • Hi @Kaiserludi

    I did download the windows SDK8.1 and also get the last version of the photon windows sdk (4.1.15.3) . Then I took the same project that previously but from the 4.1.15.3 photon sdk and I do get the same result
  • Hi @benjaml.
    Does it work when you copy and paste the IP address that you have received in the
    'onAvailableRegions' list in your log for the 'eu' region and connect directly to that address by passing it as parameter to connect() as if you would connect to your local self-hosted server?
    Note: When doing so, then you need to also pass ServerType::MASTER_SERVER for the serverType parameter to connect(), just like you would do when connecting to a self-hosted server.
  • Hi @Kaiserludi

    Nope, it does not work either
  • Hi @benjaml.

    How does the log look in that case?
  • Hi @Kaiserludi

    the log looks the same as previously. I did manage to test it back home and it is working fine
  • Hi @benjaml.
    the log looks the same as previously.
    I am afraid that is impossible. The log that you have shared previously contains a server response with the list of available regions and the client auth request to the name server, that contains the region that the client has selected.
    Those can't show up in the log when you connect directly to a regions master server.
    Also the log shows that the disconnect happens while the client is still on the name server and has not switched to a master server in the selected region yet. However when you directly connect to a master server, then the name server will never be entered and the log would contain a connect to the master server before a disconnect could possibly happen.
    I did manage to test it back home and it is working fine
    That tells us that it must definitely be connected to the environment that it runs on in your office.
    Either it's the firewall or the router.
    If it does not even work when you have temporarily disabled your local firewal, then I suggest to talk to your LAN admin and let her/him check if the traffic could get blocked somehow.
Sign In or Register to comment.