We Keep Coding

Java - Online game, should the game happen in the server or the client?

I'm implementing a multiplayer option for a chess game I made, but I'm starting from zero to do both client and server. A friend said to me to make the game happen in the server, and the client only gets the data and shows in the GUI. Does this means that I have to implement the game in the server (without GUI); and in the client project, just the GUI, actionListeners and stuff, so that, for example, when I click on a piece and then click where I want it to go, the server will "make" the move (set new position etc) and then send this information back to the client so that it can print? Is this the best approach?
By the way, my server can (will) host several games (each time 2 sockets connect it creates a game thread). Oh and also, after finishing the game, I want to implement a little chat in-game. Don't know if this information changes something...

Longer answer is that you really have a lot of flexibility in how you want to do this. The "traditional" way of doing this is the model-view-controller pattern, where you separate the model (game state) from the view (what the board looks like), and a controller (your server code) handles interaction between the two.
The question is where to place each section of code.
One option is to place have the client do the heavy lifting with the server acting as a middleman between clients and communicating updates. This has the advantage that servers don't need to do as much work, but results in a client that can be easily modified for cheating.
The other option is to place most of the important code on the server and simply have each client be a "dummy" display that just shows whatever the server sends and just send the bare minimum amount of information to the server for the server to determine what was done. This is more hackproof, but places greater load on the server.
You can also do a hybrid model where the both the client and the server share the load of sanity checking, so the load on either isn't quite as severe. I think that this is a pretty good option, even though it violates the "pure" MVC pattern.
What works "best" for you might depend on the kind of load you expect on your server. For a small number of connections, "pure" MVC with "dumb" clients might work. Client makes move, server verifies that the move is valid, and if so, sends updates to both clients. If your framework starts to get overwhelmed you might want to consider putting some checking code in the client though.
None of this affects having multiple pairs of clients or a chat. You should be able to implement each of those parts separately, and if done correctly piecing the modules together shouldn't be bad.

How reliable are Binary Messages in Java ME

I am to develop a mobile application for the Java ME platform that sends SMS messages, containing binary data. However, the application is to use a custom port for sending these messages (so that it can register itself and automatically receive these messages, instead of the standard messaging system of the phone).
My question is:
1) Are BinaryMessages to custom port widely supported in mobile networks worldwide? Or is this something "extravagant" that would work only with a few telecom operators?
2) Normal TextMessages tend to be broken down to multiple parts when their text exceeds the limit of a single message. Are BinaryMessages treated the same way, and if so, how can I deal with this issue (fragmentation) in my application? Obviously part of the message will not do the work and ideally I would like to get the full message when all of its parts are received. Is this dependent on the carrier network?
I realize I could test this out, but I can't run the test on many telecoms, just those in my (small) country, and this is crucial to whether this application should be developed, or not.
I tried looking for the answers by myself, but I failed. Sorry if these are trivial questions and thank you for your time.

I see nothing wrong with this question. I can only offer a semi-answer though.
It is true that it is up to the individual network provider to choose whether they want to keep all ports open, or not. Therefor you cannot assume that it's always possible to send/receive a text message or a binary message.
However, I was told by another JavaME developer long time ago, that it's very unusual for them to close the ports. (Aren't the same ports used for a lot of other protocols such as sockets and http? If yes, then surely they are always open. Closing them wouldn't make any sense).
If I were you I'd add some code to check if messages are sent, and then output some error message to the user about it if it fails. (If possible, also call some URL as a way of error-reporting back to you).
About the broken down messages, that's a good question. I have no idea. I would make some real-device tests to find out.

designing an audio architecture

I am designing an audio architecture in java. I know I know, I should be using c++...
Anyway, Ive read Craig Lindleys book Digital Audio with java. He describes a pull architecture where devices are connected in a linked list and the sink devices requests data from the the device immediately prior to it. That devices calls the same interface method to get the data from the device prior to it. The method is something like:
public int getSamples(byte[] data);
I am interested to see what other people think of this. c++, java, whatever. can somewhat elaborate on the architecture of something like pro tools, ableton, and reason. Do those systems at all rely on a "pull architecture" similar to what Lindley describes albeit more mature.
Forgive the broad nature of the question.

I've seen audio architectures that are push and pull based, and both have pro's and cons.
In a push based system where each filter pushes data downstream to a down stream filter, you need some notion of timing the push requests such that you have data at the end of your chain of audio processing units when the sound card is ready for data. This usually comes in the form of an external clock which times pumping of your graph. DirectShow works this way.
In a pull based system you can use the I/O requests from the soundcard to drive pumping of the graph, which lets the clocking be run by your device. In this system you will still need buffering at the start of your graph (data sources).
I would recommend not doing a pull/push based system, but an executor style architecture. Imagine that you have a set of audio processing units (APU) which are managed by an AudioGraph object, who knows how they are connected. Now, You can use the audio callbacks from the soundcard, and pass any audio inputs to your AudioGraph, and let the AudioGraph manage processing data through each of the audio processing units. This separates the data flow completely from the I/O requests, and allows your AudioGraph to things like parallelize processing requets, run requets to process each of the filters out of order, etc. Also each APU doesn't need to know about its neighbors and they are only "connected together" at the AudioGraph level. This is AudioUnits on OS X works.

Applet game update screen when network gamestate changes

I am currently following an article about a simple gameloop, I can get my game going locally and I can add a lot of objects and behavior into it.
The article is this: http://www3.ntu.edu.sg/home/ehchua/programming/java/J8d_Game_Framework.html
My game is a grid, where other players can change some simple rectangles. It doesn't need to be the fastest approach, but somehow I need a new thread that connects to my server, and modifies the gamestate, which will get drawn on the screen. I just can't see how I can implement it, without causing the applet-thread to hang.
Can somebody see a solution to this?

Are you having a threading problem, or are you asking how to design the communication between the server and client?
For the communication problem, here's a simple approach: have the server periodically send each player updates, whether through a constantly connected TCP connection or just periodic plain old unreliable UDP packets. The choice of which one to use will depend on your application requirements. Read about the difference between TCP and UDP -- there are many, many places,including on SO (just search), that discuss the tradeoffs. Once you have the server updating on state and you can verify this works by giving the server some scripted state to follow, you can send some data the other way too. Depending on your application, you may need to be careful about security: whether a player can lie to the server about its actions, etc.
In Java, connections are often done through the Socket and ServerSocket classes, or through the DatagramPacket and DatagramSocket classes.

I just can't see how I can implement it, without causing the applet-thread to hang.
Implement an ActionListener to do the server update/check. Call the listener in a loop using a Swing Timer. See How to Use Swing Timers for more details.

Good XMPP Java Libraries for server side? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I was hoping to implement a simple XMPP server in Java.
What I need is a library which can parse and understand xmpp requests from a client. I have looked at Smack (mentioned below) and JSO. Smack appears to be client only so while it might help parsing packets it doesn't know how to respond to clients. Is JSO maintained it looks very old. The only promising avenue is to pull apart Openfire which is an entire commercial (OSS) XMPP server.
I was just hoping for a few lines of code on top of Netty or Mina, so I could get started processing some messages off the wire.
Joe -
Well the answer to what I am trying to do is somewhat long - I'll try to keep it short.
There are two things, that are only loosely related:
1) I wanted to write an XMPP server because I imagine writing a custom protocol for two clients to communicate. Basically I am thinking of a networked iPhone app - but I didn't want to rely on low-level binary protocols because using something like XMPP means the app can "grow up" very quickly from a local wifi based app to an internet based one...
The msgs exchanged should be relatively low latency, so strictly speaking a binary protocol would be best, but I felt that it might be worth exploring if XMPP didn't introduce too much overhead such that I could use it and then reap benefits of it's extensability and flexability later.
2) I work for Terracotta - so I have this crazy bent to cluster everything. As soon as I started thinking about writing some custom server code, I figured I wanted to cluster it. Terracotta makes scaling out Java POJOs trivial, so my thought was to build a super simple XMPP server as a demonstration app for Terracotta. Basically each user would connect to the server over a TCP connection, which would register the user into a hashmap. Each user would have a LinkedBlockingQueue with a listener thread taking message from the queue. Then any connected user that wants to send a message to any other user (e.g. any old chat application) simply issues an XMPP message (as usual) to that user over the connection. The server picks it up, looks up the corresponding user object in a map and places the message onto the queue. Since the queue is clustered, regardless of wether the destination user is connected to the same physical server, or a different physical server, the message is delivered and the thread that is listening picks it up and sends it back down the destination user's tcp connection.
So - not too short of a summary I'm afraid. But that's what I want to do. I suppose I could just write a plugin for Openfire to accomplish #1 but I think it takes care of a lot of plumbing so it's harder to do #2 (especially since I was hoping for a very small amount of code that could fit into a simple 10-20kb Maven project).

http://xmpp.org/xmpp-software/libraries/ has a list of software libraries for XMPP. Here is an outdated snapshot of it:
ActionScript
as3xmpp
C
iksemel
libstrophe
Loudmouth
C++
gloox
Iris
oajabber
C# / .NET / Mono
agsXMPP SDK
jabber-net
Erlang
Jabberlang
Flash
XIFF
Haskell
hsxmpp
Java
Echomine Feridian
Jabber Stream Objects (JSO)
Smack
JavaScript
strophe.js
xmpp4js
Lisp
cl-xmpp
Objective-C
xmppframework
Perl
AnyEvent::XMPP
PHP
Lightr
xmpphp
Python
jabber.py
pyxmpp
SleekXMPP
Twisted Words
xmpp-psn
xmpppy
Ruby
XMPP4R
Tcl
JabberLib

I went through the same search. I first tried Smack and then realized it's targeted at c2s (client to server) and didn't have what I need. I looked at Tinder but didn't like the licensing model (also when I looked it was much more raw). I finally looked at Whack and realized it was what I needed - but it's missing a lot (that's why Tinder came about I think).
So..my solution? Forked Whack, added some code to abstract out things, and try to make it easier to use: http://github.com/Communitivity/Adirondack
I wrote a Scala library based on that to help create external component based agents, see
http://github.com/Communitivity/Shellack
and http://github.com/Communitivity/MinimalScalaXMPPComponent
One of my main goals was to make it easy to write a component quickly. An example of such a component is below:
object Main {
/**
* #param args the command line arguments
*/
def main(args: Array[String]) :Unit = {
new XMPPComponent(
new ComponentConfig() {
def secret() : String = { "secret.goes.here" }
def server() : String = { "communitivity.com" }
def subdomain() : String = { "weather" }
def name() : String = { "US Weather" }
def description() : String = { "Weather component that also supported SPARQL/XMPP" }
},
actor {
loop {
react {
case (pkt:Packet, out : Actor) =>
Console.println("Received packet...\n"+pkt.toXML)
pkt match {
case message:Message =>
val reply = new Message()
reply.setTo(message.getFrom())
reply.setFrom(message.getTo())
reply.setType(message.getType())
reply.setThread(message.getThread())
reply.setBody("Received '"+message.getBody()+"', tyvm")
out ! reply
case _ =>
Console.println("Received something other than Message")
}
case _ =>
Console.println("Received something other than (Packet, actor)")
}
}
}
).start
}
}

Ignite Realtime shares its Tinder API which is a basic building block extracted from OpenFire just for the creation of server-side components and possibly other servers. It implements basic XMPP building blocks and you are free to start from there.

Also from Ignite Realtime is the Whack API which is specifically for building XMPP components
Whack is an Open Source XMPP (Jabber)
component library for XMPP components.
A pure Java library, it can be
embedded into your applications to
create anything from a full XMPP
component to simple XMPP integrations
such as sending intercepting and
acting on certain messages.

Your best bet is to use an existing server, and add your functionality to it. Writing an entire server from scratch, even using a library, is going to be a lot harder than you expect.
Can you tell us more about the problem you are trying to solve? We can then point you to an appropriate server, and help you with the right place to plug in.

check this out:
this is a lower level library. it is in incubation status and it seems nobody is pushing it. but it is a great api and i hope it will progress.
http://java.net/project/jso-jabber-stream-objects

I think you already looked at the right solution: Openfire
It's not a commercial solution. It's an XMPP Server on top of Mina and Jetty written in Java released under the Apache License. Comes pretty close to what you asked for.
While I know that you asked for a library, why not use some stable developed open source software that can easily be extended like openfire?

I found a good xmpp server based on Java : http://www.tigase.org/

Have a look at Vorpal. Its a Java EE 6 framework that implements XEP-0114 protocol.

I know that the intent is to build a small hack in the OP.
However, if there is ever an interest in scaling it, end-to-end security,
etc. I would suggest looking at Soapbox from Coversant.
They are our partner. We use SMACK on our hard realtime virtual machine environment, JamaicaVM to communicate with Soapbox.
Also, if the intent is to communicate with a server app, and not to reimplement
an XMPP server (e.g. Soapbox), the SMACK client can be used for that.
It is a client to the XMPP server, but the instance of actual communications can be
from client to client through the XMPP server.