From the client side (extending StringBasedClient):

- Install a windows hook and detect application window activations by capturing window focus events.

- On window focus detection, get the window title and process id, and send them to the server.

From the server side (extending StringBasedServer):

- Listen for window focus events, sent by one or more clients.

- show the window text and the application process id from those events in a gui

I’m creating strings to perform communication between the clients and the server, concatenating first the PID with a ‘\n’, and later the window text, just when the user activates an app.

I’m interested in creating a JList that handles the current connected clients. I’ve done it holding a SelectionKey that the user selects with the valueChanged event on the JList, to filter what messages are seen on the gui, using this code for the server:

public void processStringMessage(SelectionKey key, String message)
{
if(key.equals(usrSelectedKey)
{
//take the message, parse it and put the contents on the gui
}
}

Unfortunately, the code does work well, and I’m not sure what is the cause. Maybe I have missing a synchronized block, or maybe is something that I haven´t seen on the documentation.

Thank you.

I ‘am in the process of researching comet in general. I just wanted to prototype comet for one of my application where I am currently polling the server ( especially a queue) to download the messages if any.It would be gr8 if you could provide some hands on for this.

Thanks

If I’m reading the source right, there’s just a single thread handling the IO stuff – so everything is synchronized already? For example, If I have clients connecting, sending messages, and clients dropping their connection all at the same time, in the server class I’ll see everything serialized, something like:

processStringMessage();
processStringMessage();
keyCancelled();
processStringMessage();
keyCancelled();
processStringMessage();
etc…

I ask because I’m making a small player manager class which keeps a hash map of all connected clients etc. I guess I don’t need to synchronize anything in it because all these notifications are coming in serialized, as far as I can tell.

Thanks

To work around the issue I added code to recreate the selector after 60 seconds of inactivity and no connected clients.
The code of the change I made follows:

Renamed the run function to runEx.
In the runEx function after while( iterator.hasNext() ) added
lastMessage = System.currentTimeMillis();

After lastPostProcessBegan = currentPostProcessBegan; added the following code to break out of the function if no messages were received in the las 60 seconds and I have no open connections.

if (currentPostProcessBegan – lastMessage > 60000 &&
connectedChannels.isEmpty())
{
System.out.println (Thread.currentThread().getName()+”::runEx “+
“No messages in the last 60 secs (rerun)”);
return;
}

created a new run function that calls runEx the function looks like this

public void run ()
{
while (status != STOPPING)
{
lastMessage = System.currentTimeMillis();
status = STARTED;
runEx();
if (listener)
{
try
{
ssc.close();
}
catch (Exception e)
{
e.printStackTrace();
}
ssc = null;
}
}
}

Note that the member variable listener is something I added to the code to support multiple threads working in parallel to support 1000′s of users where only one of the threads acts as a listener.

I opted to let the client connect, but then I send them a ‘please disconnect’ command. My client sidegets the message then politely closes the connection from its side. That seems to work great. The only thing I’m worried about is – the server right now can’t hard kick a user if it wants to, it needs to ask the client to do it! I’ll give your recommendation a try though, it sounds like another correct way of doing it.

The code you posted is great by the way, I was previously using a classic threaded server model, this architecture is much easier to work with in my opinion,

Thanks!

I would suggest at least that you should accept it, and then add it to a queue of channels to reject as soon as they become writeable.

Then you can at least output e.g. a message “Too many connections; try again later”.

This will make your debugging much easier when you find at some unexpected time in the future one of your clients can’t connect for no apparent reason (i.e. you’ve got another client somewhere that’s still connected that you forgot about ;))

How can we reject a connection? Let’s say I only want to support 5 users. I added a piece of code like this:

if( key.isAcceptable() )
System.out.println(“Client wants to connect………”);
if (getShouldAllowNewConnection(key)) {
key.channel().close();
continue;
}
// Normal stuff for adding the new key to “connectedChannels”.

That works, but then that same client can never attempt to reconnect again. It seems like the client will keep using the same socket channel somehow which the server has permanently condemned because of the channel().close() call. What’s the right way reject the client, but still let them attempt to connect thereafter?

Thanks,
Mark

I’m not quite sure if this is the place to discuss a specific implementation of a chat server using this code, so I just will give you a gist.

1)Created a class that extends the StringBasedServer class.
In the overloaded processStringMessage member function I enqueue the received message along with its SelectionKey into a LinkedBlockingQueue.
2)Created a class called MessagePump that implements Runnable and dequeues messages from the LinkedBlockingQueue. This class implements most of the chat server protocol that I’m using. For example when a message its dequeued from the queue and the SelectionKey has never been seen by this class, a session object its created. In the session object I store the SelectionKey, and all other chat protocol information. The session object is stored in a Hashtable that uses the SelectionKey as its key.

3)To support 1000′s of users I did some modifications to Adam’s code. The key modifications that I did is to be able to extend StringBasedServer in a non listening mode. I did this mainly so I can have multiple threads that extend StringBasedServer each one processing all IO for a subset of the open connections. For my server the order at which messages are sent and received is not important, so I have multiple instances of StringBasedServer and MessagePump. Overall its more important to have multiple instances of message pump since one incoming message can become 1000 of outgoing messages. Also since the message pump implements the protocol its a bit more cpu intense than the network worker thread.

Since this is Adam’s page I’m not quite sure if he is interested on the details of a full blown description of my implementation. Theres are a few other modifications that I did, but this is just a gist of what I had to do. If you need to contact me directly, I can be reached at http://www.uiija.com, use the contact us link at the bottom of the page.

Thanks for this sample code, it’s great. I just wonder about how the client connection is supposed to get notified that the server has sent it a message. It seems that in StringBasedClient, there is a member:

iMessageProcessor messageProcessor

It’s not set anywhere, so I just added a parameter to connect(), so that it takes a reference to an iMessageProcessor object. Once set, it seems to work fine with the string client calling receiveMessage() everytime the server pushes a message to the client. This is how it’s supposed to work, right?

Thanks,
Mark

I need to write a chat and a voice chat server, which should support around 1000 users, Could you please guide me in this?

~Sandy

Diego

In regards to the spinning bug that I mentioned before. The simple fix is to add the following code to readIncomingMessageFromKey
if (bytesRead == -1)
{
throw new IOException(“Channel Closed”);
}
after
if( bufferIsEmpty )
{
bytesRead = ((ReadableByteChannel) key.channel()).read( bb );
}

Another question
In StringBasedServer.run after

Set keys = selector.selectedKeys();
Iterator iterator = keys.iterator();
while( iterator.hasNext() )

Yes, attachment() is broken.

Yes, Sun has known about this for at least 4 years (I logged a bug on it with them).

No, as far as I know, they haven’t fixed it yet.

Yes, this is pretty depressing :).

Oh, and – if you read any of the books published on NIO, they probably won’t mention this. Because most of the authors never actually tried using NIO on any real project. Sigh.

I know that its being set because I can retrieve it with a call attachment() after I have set it. Originally I was doing the attachment from a different thread, but I have changed my code so its done in ProcessStringMessage.

I also looked into your code and you are not using the attachment, so the only conclusion I have is that java lost it.
The attachment its not crucial since I can store my session object in a hashtable, however it would be nice to get to my session without the need of a lookup.

Also I have run the code under the debugger with a watch on the attachment, the watch does not trigger, but attachment still returns null.

Thank You
Again Diego

Re: 64 sockets – that’s the default limit that Windows puts on IOCP (completion ports), although you can programmatically tell windows to change the limit to something higher.

From memory, there WAS a bug in Java 1.4.0 (about 4 years ago) where the Sun programmers had forgotten to increase this limit, but it’s been fixed for many years now. I suspect that what you read was a rumour from a half-remembered description of that bug?

I read somewhere that selectors can only handle 64 sockets, I can’t recall were I read this and as you said the doc on nio is spotty at best. If it is so, what would you think is the best approach on your code to handle this. 1) create a thread for each selector or to process all the selectors using the same thread iterating threw the selectors ?

Thank You Again
Diego Cassinera

The “massively multiplayer game development” books from CRM sound good on the cover, but are almost totally useless in fact, being full of mostly overly simplistic or even downright poor ideas and implementations. So I would suggest avoiding them. They’re the most technical books I’ve seen, though.

RAM is generally only a problem if you run out, and you’ll know how much you need pretty quickly when you start developing. Any more detailed answer is going to take a LOT more detail to answer, sorry :).

For area-searching, I very much doubt it will be a major issue for you in the longrun, unless you’re truly stupid with your implementation. Google for work on “2d collision detection” – it’s the same problem, phrased slightly differently, and all modern games have good algorithms for this stuff already.

Database performance is usually the one that kills people…

I am (with educational purposes) making a server for a MMORPG-game, that is supposed to be able to hold up to around 2000 players at once, so I got a few questions to ask:

1. Does the RAM-requirement (either if it is 30.000 kB or above 100.000 kB) have any visible impact on the servers efficiency?

2. What would be the best method to handle static game-data (XML files using XStream, or something else)?

3. What algorithm should preferrably be used for area-searching, to see which entities overlap the view-field of the current entity?

4. Do you know of any very good books about the subject MMORPG-game development for Java, or something covering other heavy server-frameworks?

Then again, off the top of my head, I think the last online chess system I looked at had hundreds of thousands of simultaneously connected clients, so I suspect you should be able to find some good prior art that is chess specfic and more than adequate to your needs.

Happy to help with basic questions, but please note that I currently work for one of the world’s biggest massively multiplayer online game publishers / developers, so there are limits to how much I can get involved with other people’s games – unless we’re going to fund or publish them.

thanks

Also … this overly-simplistic implementation is quite easy (I think!) to read and understand and learn for yourself what is going on…

i am very interested to know exactly what the “few major flaws and a few unfixed bugs” are – as much as i dont really like the api, my game im making seems to be working ok so far – i mostly used online tutorials to help me learn nio. Only thing i can thing of is maybe a lack of built in timeout handling?