Hi,
E.g. you have a chat server, an you want to send a private message to another client. (or send the message to
several clients only in the same chat-room)
What is the best way, to manage these clients on the server side(every User gets an id an the SocketChannel are saved in a Hashtable, then select every user etc…) ?
Or do you have a better solution ?
Raven
Basic problem of identifying things across JVM/database/network boundaries?
A ID number is the most simple solution. I have a complete class system implementing my interface ‘Identity’. The only method of ‘Identity’ is ‘isSameAs(Identity id)’.
Identity is implemeted as NamedIdentity using a string, LongIdentity using a long. Additionally Idenitities may be constructed within a scope Identity, which makes even ByteIdentity a useful class.
All public IP addresses could be modelled by 4 nested ByteIdentities. Or by a NetworkIdentity of course…
[quote]Hi,
E.g. you have a chat server, an you want to send a private message to another client. (or send the message to
several clients only in the same chat-room)
What is the best way, to manage these clients on the server side(every User gets an id an the SocketChannel are saved in a Hashtable, then select every user etc…) ?
Or do you have a better solution ?
[/quote]
Obviously, there are many ways of doing this. Unfortunately, Sun’s documentation for the 1.4.x JDK’s is crap (lots of features and deliberate decisions are undocumented - leading to people writing broken code until they discover “it’s not a bug, it’s a -feature- we forgot to tell you about”).
The very best way is to use IP Multicast, and have each chatroom as a Multicast group. I haven’t been brave enough to trust the multicast stuff in java yet (although it SHOULD work properly) - it seems in general that something as infrequently used (and as poorly documented) as this in the standard libraries is often under-tested, from previous experiences.
Also, lots of routers on the internet are prone to ignore/dump multicast traffic, so it can’t necessarily be relied upon to work outside of your local LAN. Which is a pity, because it’s perfect for chatrooms.
Otherwise, for a chatserver, I’d have one thread per chatroom, delivering messages to all people in that chatroom. So, you should have one Selector per chatroom (lots of undocumented “features” if you attempt to use multithreading with NIO/Channels in 1.4.x. It’s not worth bothering until Sun gets its act together. Sigh). If you can follow the 1.4 examples for networking, you’ll be up and running with SelectionKey’s etc. Attach the SocketChannel for each connection to the SelectionKey associated with that connection.
If you want to handle thousands of simultaneously connected clients, you should look for resources on “writing servers for (tens of) thousands of clients” in C++ … the Java NBIO architecture is based on the way many C/C++ implementations used to do things, especially on unix, and so most of the details are the same. Google should find the most important articles on the subject.
But if I send private messages from one client to another, I cannot use your solution ? Then I need to know where the other user is ?
Also if I use a “friend list”, the server have to know if someone is online or offline (if the person is on my list). So I have to manage every client separatly ?
Yes, you have to implement kind of a router that assigns connection lines to users. Or you broadcast everything and let the clients filter the unneeded messages. But this of course is a waste of resources.
So just a side note.
Ive been using multicast with a TTL of 1 for simple ad hoc discovery and its working like a champ.
JK
[quote]So just a side note.
Ive been using multicast with a TTL of 1 for simple ad hoc discovery and its working like a champ.
JK
[/quote]
True. But this won’t get you past the LAN. Multicast seems to be great for local broadcast (where you usually don’t have enough clients to require it) or local discovery where it makes perfect sense. Go beyond the LAN and you usually run into routers that ignore multicast or network flooding which is, of course, why many routers ignore multicast traffic in the first place. One of the ways you typically get around this is with multicast bridges (used in distributed Jini registries and decentralized JMS implementations) where unicast connections between specialized hosts are used to transfer multicast traffic between LANs. Great for enterprise Apps, not sure how practical this is for games.
[quote]Ive been using multicast with a TTL of 1 for simple ad hoc discovery and its working like a champ.
[/quote]
I’ve been impressed with Java Rendezvous (I’m not sure they can use both parts of that name, but whatever.) which is a Java implementation of multicast dns / dns service discovery from Zeroconf.
It should be noted, that this too, is limited to the local network. Useful perhaps for LAN games, but you still need some form of unicast bride to use this for wider-scale multicast.
Which is something some of the JXTA folks did (using JXTA) to wire together multiple Rendezvous networks into a single network.
How many clients are you talking about for your chat channels?
And are you using a client/server architecture or applet-based or what?
One possibility is using JMS topics (publish/subscribe method). Setup one topic per chat room. Everyone who joins that chat room subscribes to that topic. When you leave the chat room you unsubscribe from the topic.
There are some free JMS implementations out there, such as JBoss and others. The downside is that JMS can be slow and/or heavyweight just for chat, depending on the implementation. But it is easy to set up (again depending on the implementation) and gives you quite a bit of nice functionality without a lot of effort.
Hi,
I dont know how many clients / server I want. Now I would say as much as possible.
I use a classic client / server architechture (Swing app + java server).
I start with the observer pattern (with NIO), that means every client can subsribe for a chat / game room and gets the informations from all other clients.
Now I cant give you more informations (how many clients, performance etc.) , because the project is now “sleeping” (that means my current job is too time intensive ;-( ).
But after I finished my chat- and game-room server, I can use this for various other apps.
Raven
Hello! I am new to this board and dang, I wish I knew about it a year ago! I suspect I will be back often 
I saw this thread and wanted to speak up a bit. In Java 1.4+ it is fully possible to create a very powerful and scalable server. Java NBIO is more then capable but the documentation is simply terrible. Many of the examples of NBIO online are very poor to say the least. Also, there were several cross-platform JDK bugs that are just now resolved (I believe). Personally, I found NBIO to be quite confusing as well but that might be just me.
With much help from Ron Hitchens (author of the O’Reilly Java NBIO book) our chat server has been load tested to 5000 concurrent connections on Windows 2003 Server. At that point, the OS simply started blocking all inbound connections (never really figured out why either).
After three unique versions of the server, the key learnings for a high performance server are pretty simple and really boil down to these two things:
You need to use NIO to managed all the incoming and outgoing data. We use a single thread to constantly poll everyone for incoming messages. Every connected client has a buffer they store partially completed messages in that is drained when a message terminator is received.
Use a thread pool to handle dealing with every transaction from the clients. If you think about it, each message from a client is a discrete unit of work. To that end, our server has a mapping of all types of transactions it handles. We take a message from the client and a worker thread then determines which handler users it, executes the handler, disposes of the message, and returns to the pool.
We have played with several other threading models from 2 threads per user (one for inbound data and one for outbound data) to a thread per room. Thread per room works pretty well, but can lag pretty bad when you get into lots of messages in a room. Private messaging of users cross rooms gets really messy too. The two threads per user option is by FAR the simplest but also the least scalable. It seems to crap out at about 300 or so users and the memory usage gets pretty extreme.
Be extremely careful with synchronization. This is by far the biggest problem we have. We are STILL squashing synchronization bugs where we get a deadlock on a single thread in the pool and things become unstable. It’s very hard to isolate.
To handle room level messaging, you simply need to ensure the Room on the server knows all Clients inside of it. Then the room has a method like “sendMessageToRoom()” to iterate over the clients and send a specified message to them.
To handle private messaging, we use the username as a key in a HashMap at the chat server level. If you want to send a message to someone, you simply ask the server to look up the Client object from the HashMap and use the sendMessage() method on the client. This seems to work pretty well. The downside of the using a username as a key is that you have to “log in” first. The user doesn’t have a username until after it connects AND logs in. This means that if you need to reference or message a user before they logged in, you have to provide another means for locating them. We handle this by requiring that login be the very first transaction called before all others. Anyone that breaks this rule is disconnected immediately. We also have a clean-up thread that disconnects people that have connected but not logged in after a configurable period.
Thus far everything described is completely protocol agnostic. Everything we do uses TCP entirely. A single channel between client and server. I suppose we could use a second channel via UDP or some such like many games but thus far it hasn’t been much of an issue and so we haven’t explored it too far.
To make it worse, we actually use XML as the format for all messages. I’m sure some of you are cringing, but hear me out. We have a very high performance and lightweight (interpret this as VERY SIMPLE :)) parser that we use on the server. This has proven to work great and be nice and simple for clients in multiple programming languages. In the next release of the server, we will support replacing this with a message interpreter of chose based on an interface. This will allow people to use more effecient message formats at the expense of simplicity.
bmyers mentioned the idea of using JMS. We found this intriguing and played around with it about a year ago. We used dynamic topics for rooms and it works pretty well but the machinery to handle keeping track of who and what was where became quite a chore. In the end, it proved overly complicated and performance heavy due to all the J2EE code involved. BUT, this might be a perfect solution depending on the requirements of a given game. One thing to keep in mind is that if this is an application on their machine or a signed applet, you can actually run the JMS server on each users machine to provide direct access between users in a P2P style configuration…
Woah! I just looked back at what I wrote and realized this this has become a rather lengthy tome ! Sorry about that, I hope this was helpful to someone! Feel free to contact me with any questions.
Mike Grundvig
Electrotank, Inc.
mike@electrotank.com
[quote]Hello! I am new to this board and dang, I wish I knew about it a year ago! I suspect I will be back often
I saw this thread and wanted to speak up a bit. In Java 1.4+ it is fully possible to create a very powerful and scalable server. Java NBIO is more then capable but the documentation is simply terrible. Many of the examples of NBIO online are very poor to say the least. Also, there were several cross-platform JDK bugs that are just now resolved (I believe). Personally, I found NBIO to be quite confusing as well but that might be just me.
[/quote]
No disagreement there. Could you have a look at the NIO articles at:
http://grexengine.com/sections/people/adam/
and let me know what you think? It’s not a complete set of articles, but I’m looking for feedback.
Looking back at this thread, it seems the original question might have goten lost.
To uniquely identify items across VMs you need what is called a GUID (Globally Unique ID) or a UUID (Universally Unique ID). JDK1.5 is slated to have a built in UUID class. Until then you need to build your own.
There are two kinds of UUIDs, a truly unique ID and a statistically unique ID. A truly unique ID requires some truly unique seed. Etherent cards have a unique built in ID called the MAC address. Unfortunately, there is currently no way to get a MAC address directly from the JDK APIs Jso to do this you will need to do some JNI and some native code.
A simpler solution is a statistically unqiue ID. This is an ID where the chances of collision are so low that its virtually impossible. The solution for this is usually a date/time stamp plus a large bit random number. To collide two systems woudl have to produce the same random numebr at the same moment in time.
Generally a Java long for date/time and a second long for the random is enough for this method.
Btw bbb…
I’m writing a chapter on LAN networking for Sahwn’s book. Want me to refernce your web pages on NIO?