I'm developing a networked java game. The problem is that I'm not experienced with the networking concepts. My problem is that I want first to try my game on a LAN (the lab network) but all the tutorials and references are telling how to do networking through the internet. My question is: Is there a difference in using sockets with LAN from using them with an internet. Please give me the basic steps of creating a simple networked application (client/server) to work on a lan.
Running on a TCP/IP LAN versus over the Internet (which also runs on TCP/IP) will make no difference on your networking code. Granted, you will certainly get different performance characteristics when playing on a LAN versus across the globe, but the code is no different.
I recommend going through Sun's I/O and networking tutorials. You'll need to understand I/O as you'll use it when using Sockets. For example, when you connect a Socket from one machine to another, both ends will have an InputStream and OutputStream for reading and writing data.
I/O streams are basically byte pipes. You write bytes to an OutputStream on one end of the Socket, and the other machine reads those same bytes from its Socket's InputStream in the same order they were written.You also have two choices to make, though don't worry about them yet as you can't decide until you become familiar with I/O and Sockets in general.
First, based on how your game works, will you use TCP which is connection-oriented as pictured above (think of a permanent two-way pipe or imagine how most people think of a telephone call), or will you need to use UDP which is more packet-oriented? I'm being loose with terminology because both are implemented using packets, but the key is that TCP gives you error-handling, delivery order, and other features that can end up hurting a game's performance.
In a fast-paced FPS, if a packet for a single game "tick" doesn't make it to a client, the client can either lag for that short time slice (no update happens as it freezes for 1/30 of a second) or guess where the other players should be from the previous update packets. It's not a big deal as long as the lag doesn't last too long. The client just picks up where it left off.
If you use TCP for that fast-paced game, when a packet doesn't make it, the TCP protocol will request the other machine resend the missing packet and hold up any newly arriving packets while it waits. This is because TCP has a contract to provide an ordered stream of bytes without any gaps or errors. As well, if a packet gets slightly altered, TCP will request it be resent. This would end up causing far worse lag than simply ignoring the missing or erroneous packet.
As you probably guessed, UDP can be more complicated to work with, but it's more how you design your protocol that makes the complexity rather than using the Java networking APIs.
The other decision you might have open to you is whether or not to use Java's New I/O, introduced with JDK 1.4. If you want to support 1.3, there's no choice. But if you are okay with limiting your game to 1.4 or later, you can take advantage of NIO. I won't go into this as I've already dumped out too many details, I'm afraid.
In any case, start with the tutorials and go from there.
Rototillers convert rich soil into dirt. Please note that this tiny ad is not a rototiller: