tags:

views:

7121

answers:

11

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.

+4  A: 

I briefly used Smack a while ago for a simple XMPP application. I didn't need to do much, so I'm not sure if Smack is actually much good, but it's open source and free, and it felt pretty well polished.

skaffman
A: 

I looked at Smack too - but somehow got the feeling it was for a client connection only - am I wrong?

Taylor Gautier
My limited experience of XMPP suggested that there's no much difference between servers and clients. Hopefully you can do the server socket handling yourself (pretty simple in Java), and then use Smack to handle the XMPP streams on server.
skaffman
It is a client library. Why are you not using OpenFire instead of rolling your own.
Robin
Because I was looking for more of a development platform than a pre-rolled server. Openfire looks great - don't get me wrong - for running a real system. That's not what I am really after - I am looking to hack.
Taylor Gautier
+16  A: 
Prakash
+1  A: 

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.

Joe Hildebrand
+1  A: 

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

Taylor Gautier
A: 

Wow, I am looking to build a solution VERY similar to the one detailed above by Taylor Gautier. ...Any ideas? ...Have you come across anything Taylor? Thanks! I'll post back if I come across anything first.

I didn't find anything suitable. One thing about managing the parsing aspect is that it seems difficult if not impossible to separate the IO layer from the parsing layer. I looked at ways to parse the stream in MINA, Netty and Camel (which uses MINA). Finally I looked at the StAX parsers.
Taylor Gautier
A: 

I'm curious if you made any headway on this one Taylor? I'm looking for something very similar as well. Building an XMPP "server", but one that mainly just "talks" xmpp and lets me process packets on the back end as I see fit.

Anthony Webb
Nope, I gave up my search after a while. Went on to other things.
Taylor Gautier
I talked to the guy who wrote wokkel tonight, seems like wokkel/twisted is exactly what I needed, nice guy too: http://ralphm.net/blog/
Anthony Webb
Alas, it is python, but I suppose I better start to learn the language all the cool kids are developing in huh?
Anthony Webb
+1  A: 

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.

smoku
A: 

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.

James Webster
+1  A: 

Hi Taylor,

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
  }
}
Bill Barnhill
+1  A: 

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

ely