asked on

Any RTS server datagram reliability comments, TCP / UDP ?

Hi
In previous questions, I have determined that the best way to do my Java RTS is with UDP.
Some insisted UDP only.

What sort of packet verification strategies are best, needed? UDP is release and forget.
Will my server have to communicate with any clients that haven't sent in a packet for a frame of the game? Should the client send each packet twice?
How do Blizz and Microsoft do it in Starcraft and AoE ?

I've only done testing on home LAN, university LAN, where UDP is pretty reliable, but dare I try it on cross-town connections yet? UDP packets need extra coding for reliability - like?

I'd prefer to start off correctly with my client-server.
I am good with datagrams and TCP/IP.

ASKER CERTIFIED SOLUTION

dpearson

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

James Hancock

ASKER

Thanks
Are you suggesting every 3rd or 5th or 8th
packet be TCP?

When a client attempts to join the game, should I send a TCP reliable message?
So, a server must have a TCP and UDP socket? Clients also?
With the client object and server having a TCP and UDP connection available,
is there overlap to worry about? I mean, do they conflict?
Thanks

SOLUTION

dpearson

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

James Hancock

ASKER

I'm trying a framework below, where the clients connect with TCP before any UDP begins. But, the ServerSocket object never gets bound. It crashes, and I can't see why.?

Any comments?

Thanks

import java.net.*;


public class DRWserver extends Thread {
	
	public int numClients, numClientsExpected;
	
	
	public static int TCPport=88;
	
	
	ServerSocket serverSocket;

	public DRWserver( int playerCount) {
		
		numClientsExpected=playerCount;
		numClients=0;
		
		start();
		
	}
	
	public void run()  {
		
		try {
		System.out.println("Creating TCP socket on port "+TCPport);

		serverSocket = new ServerSocket(TCPport);
		boolean AcceptingClients=true;

		
		while (!serverSocket.isBound()) {
			System.out.print("x ");
		}
		
		while (AcceptingClients) {


			System.out.println("\nClient accept()");
			Socket socket = serverSocket.accept();

			System.out.println("Client join?");
			System.exit(0);
		}
		
		
		
		
		} catch (Exception e) {

			System.out.println("\nDRWserver run ex : "+e);
			e.printStackTrace();
		}
		}
	
	public static void main(String[] args) {

		
		new DRWserver(3);
		
		

	}

}

Open in new window

James Hancock

ASKER

Could it be an OS thing? I doubt it.

dpearson

Different question than the original. I think you should post a new one.

James Hancock

ASKER

I have posted a new one, thanks

but just to confirm

This is still
Game State on the server.
?

That is getting to me! Because the UDP packets seem to get muddled! But, if I use a TCP message to straighten the game state out, and UDP for unit deltas, that should work?
Should the client ask for a TCP update, or the server automatically send a full update every 900 game cycles/frames?

Thanks

dpearson

Yes game state should always live on the server - that's for security (server code runs on a computer you control, client code runs on a computer you don't control - so it can *always* be hacked).

But, if I use a TCP message to straighten the game state out, and UDP for unit deltas, that should work?

Yes that should be fine.

Should the client ask for a TCP update, or the server automatically send a full update every 900 game cycles/frames?

You can do this either way, it doesn't really matter whether the server always posts the update or the client requests the latest state.

Doug

James Hancock

ASKER

Okay, thanks,

I am getting much closer,

but do you think an ObjectOutputStream or a DataOutputStream makes more sense?

ObjectOutput stream is so well contained, and saves the time of extracting exactly what you want from the stream?

I'm thinking datas members like this struct on the TCP side, integers and bytes as needed by various messages, where the UDP will have its own way of sending the message.
{
int messageType;
int i1, i2, i3, i4;
byte b1,b2,b3,b4;
int[] I1, I2, I3;
byte[] B1, B2, B3;
}

? thx

James Hancock

ASKER

My TCP code on my client isn't linking with my TCP code on my server.

It's probably a simple thing. Do you mind if I post it here?

James Hancock

ASKER

thx