Are you using the "demo" loadbalancing or develop your own

edited March 2014 in Native

I'm wondering whether most developers pick up the demo as a basis for their game code, or simply using the lower-level libs to developer their own solution?

In our company, we used "demoloadbalancing" in the NDK build and worked on that.


  • hi, it is the same here. it may take some time to develop your own since the documentation is not complete. my usage of the api is limited and the basics just fit my needs so i did not bother. unfortunately i usually get the TIMEOUT_DISCONNECT(1040) error and could not find a solution to that. i need to close and restart the application to make it connect. did you experienced sth. like that?
  • Hi tasadar.
    In which situations, when and how often do you get that error?
    Do you also get it with an (aside from the appID / server address) unmodified version of the demo?
    This error usually indicates a loss of the internet connection and also appears, if you are not calling service() regularly enough, so that the client can't sent keep alive signals before the connection gets considered dropped. The frequency in which you should call service() depends on the characteristics of your concrete usage scenario for Photon, but should usually be 1-20 times a second.
    Can your reproduce your problems when switching from udp to tcp?
  • i made a lot tests and found a weird way to reproduce this.
    first of all i am using vc08 with the vc10 libs and getting lots of warnings but i did not encounter any problems with this.
    i can produce the same result with the load balancing demo, the only thing i need to is to make a small unnecessary change in code to make it recompile/link and run. it always gives 1040 error if it is the first time run and it continues to fail when i try to reconnect until i close and rerun the application. i also tested with tcp and same thing happens only with a different error code(1023).
    other than these i call the service() every frame. i do not know if calling it ex. 200 times a second can cause a problem.
    do you think using vc08 may cause a problem like this?
  • Yes, this pretty much looks like your VC version is the problem here: The precompiled demos are getting compiled with the same compiler like the libs, but a recompile of course uses your chosen compiler.

    What are you actually meaning with vc08? There is no compiler with that version. There is VC8 (without the 0), which is the C++ compiler of VS 2005 and there is VS 2008, which is using VC9. Both are no longer supported by us. Support for VC8/VS2005 got dropped 4 years ago and support for VC9/VS2008 got dropped 2 years ago. Currently we are supporting VC10/VS2010, VC11/VS2012 and VC12/VS2013 for our Windows C++ Client SDK. For the rest of this post I will assume that you are talking about VC9.

    Compiling the app with a different compiler than the one with which at least one of the static libraries that the app is using has been compiled, will result in undefined behaviour. Everything can happen in that case: All could work just fine or you are getting weird unexplainable crashes or strange/unexpected errors, although everything seems to be correct, or your compiler declares thermonuclear war against i.e. Alpha Centauri, literally everything. That's the reason why we are shipping with lib binaries for 3 different VC versions. However we can't support every legacy VC version until the end of time. We have to get rid of too old versions at some time, so that we can use modern language features that have not been supported by these old compilers. Since VC9/VS2008 6 years have been passed and 3 major successor releases of that compiler have been released - in this business thats like prehistoric. Please check, if you can upgrade to a more recent version. The source of the libs isn't compile-able with VC9 anymore, so we can't simply supply you with VC9 builds of the lib.
  • yes it is vs2008 which uses vc9 compiler. in this case i will test with a never vs and see what happens. thanks for your suppport.
  • i just tried the same thing with vc10 but nothing changed, it always fail to connect after the first run following a compile. once it gives a 1040 error it wont connect again no matter how many times i retry to connect. it makes no sense :(
    i also have more questions. does calling service() too often(per frame) has an overhead and whats the QUEUE_SENT_WARNING(happens when too many msgs are sent) about, if the queue is filled up, will the packets be dropped?
  • :( That means, we will have to continue searching for the cause. You can reproduce this with the original demo from the client SDK, but you have to rebuild it to be able to reproduce it with that demo, right? Are you using an express version of Visual Studio or a full version? You are using the Photon Windows Client SDK, correct? Are you connecting to a local server or to an external address like to the Photon Cloud? Have you tried it on another development machine?

    To your service() question:
    Calling it more often then needed will introduce unneeded overhead in terms of CPU and bandwith (bandwidth overhead only can occur if there is actually anything to send at all).
    The queue warnings are just there to bring it to your attention when you are not calling service() (or directly calling the functions that are called by service() often enough, so that your queues grow beyond "healthy" sizes. Photon won't drop messages when the queues get to big. The theoretical max queue size is 4 billion elements, but long before that your hardware would likely run out of memory. However big queue sizes most of the time mean that your messages are staying in the queue for a (very) long time: If you are reading one element out of a queue every 100ms and you have 100 elements inside the queue then it will take 10 seconds until reading the last of them out: Thats 10 seconds of additional and unneeded latency! That can also mean that you are getting timeout disconnects due to messages taking just too long.
  • i am connecting to the photon cloud.
    i told my friend to try the same thing and there was no problem for him. then i suspected from the antivirus program(bitdefender ts) and i shut down its firewall. problem solved! i tried to add an application exception but it did not work so i totaly closed it and opened the windows firewall instead. thanks for your help.

    about the service() method, i actually send messages about 10 times a second but i need to use the received packets right away without delay so i have to call it per frame. i hope it wont be problem.
  • Thanks for the good news.

    You could optimize that flow by not calling service() at all, but instead directly calling the functions that service() is calling internally. You would then call serviceBasic() and dispatchIncomingCommands() every frame, but only call sendOutgoingCommands() every 100ms.
Sign In or Register to comment.