2. Data Link
The application layer is where your application lives (imagine that). The presentation layer is in charge of getting data either in the right form to send over the network, or take data from the network and prepare it for the application. The session layer handles session state (things like connects/disconnects). Transport is where UDP and TCP live, and it brings in things like reliability (in the case of TCP). The network layer deals with packets and IP addresses, and the data link layer deals mostly with hardware addresses. The physical layer is things like the actual cat-5 that your data is being sent over.
Now, this is just a rough overview, and there are a lot of things that don't fit nicely into this model. For example, routers are physical pieces of hardware, but are also in charge of handing out IP addresses and the like, so they don't fit distinctly into any one layer.
Anyway, enough of that. As far as games are concerned (or at least, I am concerned when working with games), the bottom three layers don't really need to be dealt with, they're too low-level to give much thought. The application layer will be the game itself, so that's not really the target of this project either.
I'll be dealing largely with the session, transport, and presentation layers. The presentation layer will be my serializer, which will take network data and convert it into a game-friendly form, and vice versa. Things like encryption and (de)compression will happen here. Since this project is meant to be a learning exercise, I want to write my own serialization, instead of using a preexisting solution like Boost::Serialize. The messaging layer will also be a presentation-layer beast, I guess. More on that in the future.
For the session layer, it's pretty clear what needs to be done. I'll have to manage networked game state, pre-game lobbies, and all that fun stuff. Most of this should be pretty straight forward, or at least that's my hope.
The transport layer is where things get really interesting. I'll be working with UDP, since I don't want to have to limit any games using this system to the latency inherent in TCP. This means I'll have to implement my own reliability scheme, as well as some TCP-like stream functionality, for sharing large things like game state when synchronizing at the beginning of a game. I'll also implement some quality of service stuff in my transport layer, measuring latency and whatnot.
There are a few special features I'd like to add that I'm not quite sure where to fit in. Voice chat is probably a transport-layer feature. Join in progress and host migration will, I imagine, be session layer, though host migration will have to be pretty game specific, so it will have close ties with the application layer.
Still with me on all that? I don't really know if I am, either [wink]. A lot of this is based on the design we were doing for my networking class this summer, but since that got canceled and I was way behind anyway, I have a lot of work to do, and will likely be tearing down my existing code. My initial thought is to provide a custom std::streambuf that will handle all the sending and receiving over the network behind the scenes. If it works as planned, it will make streaming pretty transparent, and play nicely with serialization and messages (I can just send a serialized game message to the streambuf, tag on a Transport layer header, and send it on its way). I'd like to support both peer-to-peer and client-server network models, but client-server will be the main focus (the less I have to deal with NAT traversal, the better).
Next time, I'll discuss the transport layer in more depth, as well as streambuf programming. It will be whenever I get around to it, so probably in a week or two.