dcsimg
Results 1 to 12 of 12

Thread: How to deal with predictable errors?

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    How to deal with predictable errors?

    Provocative title, and maybe it displays my biggest mistake right there.

    I am making a network game running a client/server model, and at the moment there are a lot of opportunities for errors to occur (on both ends), in particular when receiving data about some entity.
    To illustrate an example:

    1) Client fires a projectile and leaves map (which refreshes his list of relevant entities).

    2) Projectile connects with a monster, the server registers a hit and sends some data to the client (eg. a damage number should appear over the monster or whatever).

    3) The entity to which the server is referring is now unknown to the player, and I get an error.


    There are a lot of instances quite like this, and it's of course even worse if it's the other way around (server getting the error).
    Right now I have a placeholder solution by checking .Contains for every potential entity error, but I feel this solution isn't viable in terms of performance as my goal is to have a large amount of players.

    Since these errors are actually pretty rare on a bigger scale, would it make more sense to embed them in a try/catch instead, or is there perhaps another better way all together?

    I have read that try/catch is actually very, very slow, but to my understanding that slowness only occurs when an error is actually trapped.

    I'm aware that this is a pretty broad question, but I'm looking for new ideas.
    Last edited by Nirwanda; Dec 7th, 2016 at 05:56 PM.

  2. #2
    PowerPoster
    Join Date
    Oct 2010
    Posts
    2,141

    Re: How to deal with predictable errors?

    Quote Originally Posted by Nirwanda View Post
    ...
    3) The entity to which the server is referring is now unknown to the player, and I get an error.
    I question the information you are exchanging between the client and server. Presumably the client sends its location and direction of fire to the server. Why can not this location info be returned along with the registered hit info and be easily processed by the client to know if the it is still relevant to the client's current state?

    Perhaps what you are referring to as your place holder solution is doing this, but I do not understand your reference to the usage of Contains in this context.

  3. #3
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    34,918

    Re: How to deal with predictable errors?

    To answer one question: If you expect to have a large number of players, then you have to find a solution that doesn't involve Try...Catch. The performance hit you would be taking on that would be FAR too high for you to bear. Redesign if you need to, but don't be relying on throwing exceptions for what amounts to flow control, or your performance will never be acceptable.
    My usual boring signature: Nothing

  4. #4

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    Re: How to deal with predictable errors?

    Quote Originally Posted by TnTinMN View Post
    I question the information you are exchanging between the client and server. Presumably the client sends its location and direction of fire to the server. Why can not this location info be returned along with the registered hit info and be easily processed by the client to know if the it is still relevant to the client's current state?
    I've been very conservative with the amount of data I'm exchanging so far.
    The client is basically just sending a flag "27|35" which translates to "create projectile | type 35". The server already knows the location and faceDirection of the client, since this data gets exchanged continously through other channels.

    Quote Originally Posted by TnTinMN View Post
    Perhaps what you are referring to as your place holder solution is doing this, but I do not understand your reference to the usage of Contains in this context.
    What I mean by .Contains is that the client has a dynamic list<of>RelevantEntities, and a monster in another map is not considered relevant in my design.

  5. #5

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    Re: How to deal with predictable errors?

    Quote Originally Posted by Shaggy Hiker View Post
    To answer one question: If you expect to have a large number of players, then you have to find a solution that doesn't involve Try...Catch. The performance hit you would be taking on that would be FAR too high for you to bear. Redesign if you need to, but don't be relying on throwing exceptions for what amounts to flow control, or your performance will never be acceptable.
    That's what I thought, thanks for confirming.

    I'll need to get around to finally setting up a performance tester. The general consensus seems to be using a stopwatch of some kind a running a function X (million) amount of times or whatever.

    It would be interesting to see the difference in running some simple function like

    Code:
    for i = 0 to 1 zillion
    TestNr +=1
    vs

    Code:
    try
      for i = 0 to 1 zillion
      TestNr +=1

  6. #6
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,417

    Re: How to deal with predictable errors?

    For that kind of test to be apt, you would need the Try-Catch inside the loop (and preferably have two versions of the code, one designed for Try-Catch, and one for .Contains or similar).

    Quote Originally Posted by Nirwanda View Post
    What I mean by .Contains is that the client has a dynamic list<of>RelevantEntities, and a monster in another map is not considered relevant in my design.
    In that case .Contains would be the kind of thing to do, as it is quite a fast process (just iterating an array).

    If the list could contain lots of RelevantEntities, it may be faster to use something like a HashList rather than a normal list, but you would need to test as the speed of adding/removing items will also be affected.

  7. #7

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    Re: How to deal with predictable errors?

    To correct myself I'm actually using a dictionary<of ID/entity> for my RelevantEnteties, and thus I am of course using .ContainsKey rather than .Contains (which to my understanding is much faster, both in terms of lookup and removal).

  8. #8
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,919

    Re: How to deal with predictable errors?

    Since which entities you are interested in apparently depends on the map the user is on, its too bad the map id isn't part of the information as that would seem to be a quick gate to drop processing of a message you're not interested in without having to search a list or dictionary.

  9. #9

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    Re: How to deal with predictable errors?

    It's a good idea, however it doesn't only depend on map id, I just used it as an example.
    I use sectors (currently 1000x1000 pixels) as the main tool for seperating relevancy, and the server performs an update once per second where it checks which entities are either in the players actual sector, or any of its eight neighbours.
    You can also breach some parts of this limit by for example forming a group with another player. There are a lot of factors to take in, and I was merely hoping for some general advice since I'm getting closer and closer to a stage where I'll have to commit to some sort of netcode to move foward (and I don't like my current one).

  10. #10
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    34,918

    Re: How to deal with predictable errors?

    In your comparison in post #5, you wouldn't see a difference. The Try...Catch itself costs nothing at all as long as no exceptions are thrown. If an exception is thrown, then the Try...Catch would be MUCH more expensive....unless you also count the cost of the other code completely failing as a result of an unhandled exception, which is pretty doggone costly. That's the whole point, exception handling is a slow means of handling exceptions, but not handling them at all is generally a disaster, so you want to test for exceptional conditions and make them not so exceptional to the greatest extent possible, but for situations that you can't solve with a test, then exception handling is all that is left. This will include things like DB or file access, and a few other things.
    My usual boring signature: Nothing

  11. #11

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    Re: How to deal with predictable errors?

    Quote Originally Posted by Shaggy Hiker View Post
    In your comparison in post #5, you wouldn't see a difference. The Try...Catch itself costs nothing at all as long as no exceptions are thrown. If an exception is thrown, then the Try...Catch would be MUCH more expensive....unless you also count the cost of the other code completely failing as a result of an unhandled exception, which is pretty doggone costly. That's the whole point, exception handling is a slow means of handling exceptions, but not handling them at all is generally a disaster, so you want to test for exceptional conditions and make them not so exceptional to the greatest extent possible, but for situations that you can't solve with a test, then exception handling is all that is left. This will include things like DB or file access, and a few other things.
    That's interesting. I did not know that the associated cost with a non-error generating Try/Catch is zero (there's always SOME miniscule cost to reading any line of code I guess, but let's ignore that for now).

    Eliminating exceptions completely in a project like this seems extremely difficult to me, considering disconnects/lag etc.

    Edit:

    I've had plenty of "***?" moments, where I had some super weird exeption cause my app to crash. What I mean by super weird is the amount of stuff that had to happen for the error to be generated.
    Then I'm thinking *sigh* so I have to perform a check EVERY time just for this rare exception?

    Even if that check would very cheap, it quickly adds up if I need to do a lot of them frequently.
    Last edited by Nirwanda; Dec 8th, 2016 at 11:41 PM.

  12. #12

    Thread Starter
    Hyperactive Member
    Join Date
    Aug 2014
    Posts
    285

    Re: How to deal with predictable errors?

    Dictionary key lookups are insanely fast. I finally got around to setting up a proper test function.

    Code:
    'Before measure setup
            '-----------------
            Dim Dict As New Dictionary(Of Integer, Integer)
    
            For i As Integer = 0 To 1000
                Dict.Add(i, i)
            Next
    
            'Create stopwatch
            '-----------------
            Dim watch As Stopwatch = Stopwatch.StartNew()
    
    
            'Do measure
            '----------
            For i As Integer = 0 To 1000
                If Dict.ContainsKey(i) Then
                    'Do nothing
                End If
            Next
    
    
            'Stop watch
            '----------
            watch.Stop()
    
            'Print time
            '----------
            Debug.Print(watch.Elapsed.TotalMilliseconds)
    Results from five tests:
    0,0231
    0,0147
    0,0147
    0,015
    0,0147

    The same exact test, but using a List and .Contains instead of .ContainsKey resulted in ~1.5ms / try.
    The first test is I'm doing when the app is "cold" is always considerably slower than the following.

    Just thought I'd share!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width