Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Regular Coder DELOCH's Avatar
    Join Date
    Apr 2006
    Location
    Canada
    Posts
    537
    Thanks
    4
    Thanked 2 Times in 2 Posts

    Server-Client communication

    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
    process message
    loop

    this thread is also passed an arraylist pointer that all the threads share(to be able to communicate to each other):

    example:
    PrintWriter i = new PrintWriter(ArrayList.get(x).sock.getOutputStream);
    i.println("hello");

    ~~~~

    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...

    ~~~~~

    another problem:
    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

  • #2
    Regular Coder DELOCH's Avatar
    Join Date
    Apr 2006
    Location
    Canada
    Posts
    537
    Thanks
    4
    Thanked 2 Times in 2 Posts
    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...

  • #3
    Regular Coder Aradon's Avatar
    Join Date
    Jun 2005
    Location
    USA
    Posts
    734
    Thanks
    0
    Thanked 20 Times in 19 Posts
    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

  • #4
    Regular Coder DELOCH's Avatar
    Join Date
    Apr 2006
    Location
    Canada
    Posts
    537
    Thanks
    4
    Thanked 2 Times in 2 Posts
    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?
    connectionObject.println("getdatabase DELOCH")
    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...

  • #5
    Rockstar Coder
    Join Date
    Jun 2002
    Location
    USA
    Posts
    9,074
    Thanks
    1
    Thanked 328 Times in 324 Posts
    Quote Originally Posted by Aradon View Post
    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.
    TCP will also handle number 1 as well. TCP ensures the data arrives in the right order.
    OracleGuy

  • #6
    Regular Coder DELOCH's Avatar
    Join Date
    Apr 2006
    Location
    Canada
    Posts
    537
    Thanks
    4
    Thanked 2 Times in 2 Posts
    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


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •