At the moment I'm writing a server which will introduce players in a p2p game. For this I was thinking of having have various packet types (which the server determines from the first byte recieved) all of which contain different things. Is this a good way to do things? I've read lots of things which advocate sending an int at the start of a packet to show the length of the packet, but if I know what is in a certain type of packet is my method as good? Also is it better to simply hard code the details for each packet type or would a controller class which determines the type of packet and packs/unpacks it be better? My second question is (and this is more about communication between players), if using TCP and I know that I'll be receiving many packets from one source should I close the stream after each packet or could this result in loss of some data if its already in transit? How about if I used UDP? Thanks

For TCP, I would put the int for packet size first. It just makes more sense, and makes it possible to detect where, exactly, your protocol implementations de-sync.

UDP has packet size built-in, so you don't need to add it there.

Using a byte or two for operation code is typical; nothing wrong about that.

When using TCP, opening connections is fairly heavy-weight; you absolutely want to keep the connection open as long as the player is connected.

For UDP, there are no connections, so that worry just isn't there.

Last, if you're trying to "introduce" players such that they can host from behind a NAT firewall (see Forum FAQ for more) then you have to use UDP; there is no realiable or universally supported way of doing that with TCP.

Thats great thanks :)