Pay attention to your math!

Published September 20, 2012
Advertisement
So this week I have been working on a JavaScript node.js server for a project I am working on. In our project we use socket.io to handle the connection to the web browser(So far best cross compadabilty) and then use a node.js tcp socket to talk to the back-end server. This server acts as a middle man message director between the two. Well I was working on some messaging and I could not get the node.js socket to send a second message for the life of me(or so I thought). I spent hours looking around the web and found nothing similar to my problem.

Eventually the next day on random chance I tried to copy paste my first message(that worked) to the code block I was trying to send my message at. It worked. so I looked, the ONLY diffrence was the len variable the first message used a variable that had a sizeof(message param) summed for all the parameters being sent for that message. The next one had the len hard-coded. So I did the same with second message. IT WORKED!. I had no idea why to me the two should have been identical. I thought it had to be something in the buffer.writeUInt() function provided by node.js.

Being happy I finally fixed my issues I called my wife in(no one else around to talk too about my code). And showed her the issue... my code was as follows.
[source lang="jscript"]message.writeUInt16LE(8, 0); //this was the bad code[/source]
[source lang="jscript"]var len = 2+4;message.writeUInt16LE(len, 0); // this code worked.... [/source]
And my wife replies. "In what world does 2+4 = 8"... DOH! I spent all that time because I was trying to pass 8 instead of 6 as length for the variable. I did the math in my head and was just flying through stuff I thought I was a no brainer. It snagged me for far too long. This problem produced no errors or crashes, and everything reported success in sending/recevivng... I thought it HAD to be something buggy in node.js.

So a little annoyed at myself. But happy I fixed it. I figured I could help others remember that sometimes you need to slow down and check EVERYTHING you did even if you don't think it could possibly be the problem.

Thanks guys,

Eric R.
2 likes 1 comments

Comments

Navyman
Test often! I have found testing more often to cut my debug time way down.
September 20, 2012 11:52 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement