Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#ActualGlass_Knife

Posted 23 April 2014 - 07:46 AM

1.  Rolling log files that keep a certain amount of data (10 Mb) or so you always have enough to go back and find the problem.  If it would help, you can log data in XML or JSON or some kind of parsable format so you can generate HTML views of the data or sort through it with code.  This can help in with finding problems you didn't know were there.

 

2.  Wireshark - Some kind of network protocol analyzer can really help with weird bugs.  You won't need it often, but sometimes this is the only way to figure out what is happening.  

 

3.  Testing - there should be a clear separation between the networking code and the rest of the system.  I always have a Network interface or something like that.  You can create a mock network for testing that simulates all the weird things that can happen: packets out of order, lost data, etc.  If you assume that the network code works, you can test all the code that uses the network to verify it behaves as expected.  It isn't possible to test all the network functionality, but if you test that your code gives the correct stuff to the network class, and anything taken from the network class is handled correctly, then there is a lot less that can go wrong.  And when you find that the server behaves in a weird way, you can test that your classes respond correctly to the new buggy behavior you've discovered.


#1Glass_Knife

Posted 23 April 2014 - 07:45 AM

1.  Rolling log files that keep a certain amount of data (10 Mb) or so you always have enough to go back and find the problem.  If it would help, you can log data in XML or JSON or some kind of parsable format so you can generate HTML views of the data or sort through it with code.  This can help in with finding problems you didn't know were there.

 

2.  Wireshark - Some kind of network protocol analyzer can really help with weird bugs.  You won't need it often, but sometimes this is the only way to figure out what is happening.  

 

3.  Testing - there should be a clear separation between the networking code and the rest of the system.  I always have a Network interface of something like that.  You can create a mock network for testing that simulates all the weird things that can happen: packets out of order, lost data, etc.  If you assume that the network code works, you can test all the code that uses the network to verify it behaves as expected.  It isn't possible to test all the network functionality, but if you test that your code gives the correct stuff to the network class, and anything taken from the network class is handled correctly, then there is a lot less that can go wrong.  And when you find that the server behaves in a weird way, you can test that your classes respond correctly to the new buggy behavior you've discovered.


PARTNERS