Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
Thread: Server-Client communication
12-03-2008, 11:03 PM #1
I am having a big problem in planning out my design of a similation i want to make.
The big problem is that my design would make server and client communicate by writing strings to each other, thus making synchronization of information(such as updating player information...) impossible...
in other words... Here is my design
Server -- a main component that waits for clients to connect and creates a socket that is passed to a thread that handles the client
this thread does this:
wait for message
this thread is also passed an arraylist pointer that all the threads share(to be able to communicate to each other):
PrintWriter i = new PrintWriter(ArrayList.get(x).sock.getOutputStream);
There is no way I can think of that allows a client(a panel that has a socket connected to port 1234)
Please tell me a method I can make this work...
In a JFrame, to make a client you need to have a button that sends information from a textfield to the server(easy)...
and a listener that listens if there are any messages for the client.
Where should this listener be positioned, is it a thread, and how should it look like?
Thanks ahead of time
12-08-2008, 03:42 AM #2
anybody? this is really confusing me...
note: sorry if bumping is not allowed... I read the rules and couldn't find the part where it says where it wasn't allowed...
12-08-2008, 11:31 AM #3
I'm not sure I understand what you saying the client can't do?
The client should be able to open up a socket and connect to the specified port of whatever remote computer you're trying to connect to. If it's localhost, that's different, but all in all it should be able to perform these things.
Synchronization is an interesting problem in itself. Mostly because you have to figure out a way to make sure that the data you receive from the server is
1) In order
2) Not corrupted.
Lucky for you if you're using TCP, then 2 should already be handled for you. 1 is a little trickier, but that can be handled by creating some sort of sequence number in your design. At least, that's the easy solution.
Ideally for listening, you would either want a thread that continually checks a queue to see if there is something in it, and if there is it processes it, while you have another thread where it's only function is to get the packet, validate it, then put it into the queue.
The other solution is to have the JFrame class that you've created to do the listening itself. You would probably still want another thread however or your game will basically freeze from blocking (Although I hear there is a way to create non-blocking sockets in Java I haven't explored this option).
Let me know if there are any other points of contention."To iterate is human, to recurse divine." -L. Peter Deutsch
12-08-2008, 08:49 PM #4
what i mean is no clients know anything about each other, not to mention get each other's huge parameters of properties(name, id, information, etc)
I am worrying about the huge massive ammount of information needed to be constantly updated so each player can seen all the other players in the given area. to see other players you need to add those players as visible components(such as images or models) at their proper positions with their proper configurations such as hair color etc...
I can't imagine how you could make clients share information among other clients
Another problem is that the request have to be handled in command form such as
connectionObject.println("tell DELOCH Hello World")
which sends information to only me
and those have to be strictly managed...
It doesn't feel right...
for example, how would a client get information from the database?
which would make the server respond with all the information from the table...
it just doesn't feel right to handle all requests as a string... It's hard to explain but it's really important to understand...
12-09-2008, 12:14 AM #5
- Join Date
- Jun 2002
- Thanked 328 Times in 324 Posts
12-10-2008, 09:41 PM #6
i'm not worried about 1/2 they are fully managed by TCP ip... my problem isn't with the protocol, my problem is a method of managing game so everyone sees everyone else without constantly filtering strings