Saturday, December 20, 2008

Can't blog now, I have a class to teach!

So it's official, I will be teaching the networking class (CS 260) at Digipen starting in January. This was a bit of a surprise to me (a friend of mine recommended me for the job), but I'm really excited about it. This will be my first official foray into the classroom, so I'm looking forward to the experience and more importantly the chance to teach and influence about 100 aspiring developers (and now would be the time where some of you probably have a heart attack). I've done plenty of public speaking and teaching on a much smaller scale, so I view this as a challenge to my current abilities but not something that is beyond me.

Why am I doing this? Well, it goes back to something that Scott Hanselman said back at Seattle last year. I don't remember his exact words, but he said to go out to your local schools and talk about programming and that engaging the next generation of programmers is important. Well, you can't say I wasn't paying attention.

So the obvious question is, why me? Well, to start with, I work with networking every day. I am on the Network Class Library Team at Microsoft, and we are the owners of System.Net, which is where pretty much all low-level networking functionality lives in the .Net framework (technically it lives in winsock and we call into it via P/Invokes). I'm not a game programmer (although I originally started coding to write games) but I've written a few games in my day (tetris clone, text-based RPG, all the common ones that you start tinkering with) so I at least have a good idea about how these things work, and games are very non-trivial to write, even the simple ones.

Also, networking for games isn't horribly different from networking for anything else in terms of passing data, however there are a LOT of interesting considerations in making a networked game. For example, naggling is absolute death for a game. Sending a dataset that is too large is also death because of a few reasons, two of which would be that longer packets are more prone to errors and collisions, and that larger sets of data are more likely to get sent as part of multiple packets, which can delay your messages even further and cause more lag, especially at lower layers than TCP/IP that you're probably not even aware of. On top of that, things like NAT and proxies are a huge problem. Finally, games are real-time sytems, and networks by definition do not have real-time, there is ALWAYS a delay of some type so handling that can be very painful as well.

So, what's the hardest thing about teaching a networking class? So far, it's creating the fucking syllabus! I'm not talking about writing it out and all the class expectations, grading policies, and all that stuff; that's easy. The question is, how do I go from week one to week fifteen and teach people who may or may not know anything about networking how to program networked games? There are obviously a lot of topics that I should cover, and I could probably spend 15 weeks on any one of them. The problem is that I have to figure out what isn't as important and what can be cut out as well as what acedemic information I need to include.

I've made a few choices so far. First, I'm only spending about an hour on the OSI model. It's not horribly useful and TCP/IP, which is the dominant protocol out there right now, doesn't really map very well onto it, despite what lots of people say.

Next, I'm going to jump straight to the top of the TCP/IP model and introduce winsock so that the students can start writing code, then we'll work our way down from there. I will have at least three projects, but I'd like to have four if my current plan for a third project goes the way I intend it to. I won't say what they are (in case some of my students are reading my blog. Yes, I know you are AND I know how you figured out that this is my blog AND I know who told you about it) but they're going to be a lot of fun and a huge challenge. Everything in networking is multi-threaded, it pretty much has to be or you'll get stuck listening and unable to talk or talking and unable to listen. Or maybe you'll just take some of your data and then start doing something with it and meanwhile, your 8k buffer that winsock has is starting to fill up and all of a sudden you're rejecting packets.

Beyond that, I won't say too much, although I will be posting about my experiences here periodically. Anyone who has any ideas or input for the class, please feel free to post up in the comments. I'm really looking forward to this and I hope that my students learn something valuable from it (and I hope they enjoy the class, too, but I'll take learning over enjoyment in this case).

No comments: