checking ServerSocket.accept() in passing?

Networking & Multiplayer
#1

InputStreamReader.ready() checks if there is information to be read on the socket, and it’s really useful for me because I update information based on information fed over the socket, but if any info isn’t written, then I pass by the updates and the game continues. Otherwise, DataInputStream would wait until something was sent to it before continuing.

is there anything similar to that for a server? I’d like to have my server check if anyone is trying to connect to it. If so, addt the client, if not, update everyone else and check again. There a way to do this?

#2

just run ServerSocket::accept() in separated thread, store new connections somewhere (in some set/list), and check this set/list from your main thread.
Make sure that access to this list/set is synchronized.
You need something like this:

public class Connector extends Thread
{
    Vector newConnections = new Vector();

    public final run()
    {
        while ( true )
        {
            try
            {
                socket = serverSocket.accept();
                newConnections.add(socket);
            }
            catch (IOException e) {}
        }
}

BTW: some people on this forum will surely try to force you to use NIO, or some middleware. Just don’t listen to them! You don’t need NIO, and you don’t need no stinking middleware as well :wink:

#3

Indeed.

But in the interests of fairness, NIO is superior in all regards.

There are good reasons for using old IO (e.g. “I already know it very well”, “I have libraries that use it exclusively whihc I have to re-use”, and “I’m only allowing a maximum of 4 clients to my server - it’s a 4-player game - so I don’t care that my IO is slow and hard to code against”), but if you’ve got no legacy code, NIO is generally always a better choice.

#4

In the interest of fairness, I have to admit that it is exactly my case. (I already know it well / I have legacy libraries / it is fully sufficient for my purposes).

It may be a little bit off topic, but I also have certain small prejudice against middleware software. But I’m not expert in this area, you sure can correct me:
The question is, what level of flexibility can middleware provide you, regarding low-level format of tcp messages being sent?
For example I like to have total control, I don’t need no redundant headers, I like to have every single byte in the message for my purpose (and not for purpose of middleware).
For example I saw few middlewares, which tried to FORCE me to communicate in xml format! I definitely don’t want this.
How is it done in other middlewares? How is it done in grexengine? Can I have my messages in entirely custom format, without any middleware headers? If no, then how big these headers are?

#5

I’ve never seen real game networking middleware that does that; unless you misread the product description and were looking at something that was specifically designed to speak SOAP or similar.

Why would there be any header content from the middleware, unless it was to implement features that YOU had turned on? No, most don’t put things in unless you have deliberately chosen something that’s sole purpose is to provide you with a high-level abstracted network protocol, in which case of course the protocol has funny things in : that’s exactly why you chose it :).

#6

gulp backs away slowly

#7

well here’s my problem with the multithreading part… presently i have the server only accepting and then handing off to middleman serverthreads that have the socket for each client. The server holds all of the information (namely the Sprite instance for the main character of every client) and distributes those througout the clients by a method within the server, accessed by the middleman, that sends out the arraylist to each client.
so far so good… just like every tutorial on the subject:

  1. client connects to server and server receives the Hero (the character being controlled) and adds him to the heros arraylist.
  2. server passes the received socket off to middleman(serverthread) that loops through receiving from and sending to the client via the socket.
  3. in the client’s send to, it accesses the server’s heros arraylist and sends that to it’s client to paint.

The problem is that via this method, the whole class is sent every time. I tried it to see if it would be that big of a deal, and indeed it brought me from 60fps to less than 1fps. I tried thinking of a way that each client only sends its x,y coords after having sent it’s whole class to the server on construct to be added to the arraylist. that way, the server can deal each Hero instance to each client everytime a new one shows up (a new person logs on) and then distribute only coords every time after that.
I’ve been mapping this for days, trying to figure out the best relationship between server, client, and serverthread and i still can’t figure out a way to effectively pull this off. The closest i got was that the server can tag a byte on before every Hero sent to each client. that byte will say whether it’s a new hero to be added to the client’ repertoire, or an existing Hero of which to update coords. My problem with that is, how can i, from within the server, figure out whether every client has the new Hero’s content so as to change that byte back from newHero to justCoords?
It’s a big mess… and I’m very new to java, but I’ve been told that UDP might be more effective in this regards. If the server had a way of skipping ServerSocket::accept() if there’s nothing to be accepted, that would work perfectly because then the server could cycle through clients with a for loop and set any newHeros back to justCoords at the end of the loop, ensuring that everyone gets the new hero without overhead.
Oy!

#8
  • not sure if I understand what do you mean. Is each new client sending some serialized class (representing himself) to the server, and server re-posts this class to each other client?

  1. don’t use serialization. Write data to some byte buffer and send it as raw data (you’ll have to implement some simple protocol)

  2. the answer to performance problem is: you don’t have to send whole game status, send only deltas. When new client connects, he HAS to receive complete game status, but other clients need just delta information (saying that new client connected). Same thing when client disconnects.