Skip to main content

Go, bots, go!

Earlier this year I started experimenting with the Xmpp protocol, and implemented bots in Python to communicate with an Xmpp server. I've now revisited those bots and reimplemented them in Go. I've been meaning to learn Go for quite a while, and this seemed like a reasonable first project to tackle.
The source code lives on GitHub:
If you are an experienced Go developer, I would appreciate any feedback and suggestions on how to improve the code - if you are just starting out with Go like myself, I hope this blog and the code is useful to you.
As before, I'm using Prosody to communicate with. Just like I did in Python, my first experiment is to simply open up a socket and poke the server to see where that takes us:
func main() {
    conn, err := net.Dial("tcp", "localhost:5222")
    if err != nil {
        fmt.Errorf("Couldn't connect")
    message := "<?xml version='1.0'?>" +
          "<stream:stream to='localhost' version='1.0' " +
          "xmlns='jabber:client' xmlns:stream=''>"

    recvBuf := make([]byte, 4096)
    fmt.Print("Message Received: ", string(recvBuf))
The output should look something like this (minus the formatting):
Message Received: <?xml version='1.0'?>
<stream:stream xmlns:stream='' 
    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <auth xmlns=''/>
    <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
This is the start of the handshake of Xmpp - I won't go into the details here as I've already covered it in the context of Python, but this is a good start.
In my blog post on the Echobot in Python I discussed how to handle the incoming Xmpp stanzas. I'm basically using the same approach in Go, although I have to resort to some tricks to handle the incomplete XML we're bound to get when feeding the incoming stream.
Just like in my Python implementation the XmppContentHandler responds to the incoming parser events and builds a queue of XmppElement objects. The XmppHandler pulls from this queue, allowing it to work on a somewhat higher level, with whole XMPP stanzas.
An XmppElement looks like this:
type XmppElement struct {
    Tag        string
    Namespace  string
    Attributes map[string]string
    Children   []*XmppElement
    Text       string
The Parse method of XmppContentHandler uses the xml Decoder. It pulls tokens from the parser until an error is encountered. The handler keeps track of any leftovers, combining them with incoming data so eventually it becomes a whole stanza that then gets added to the queue.
func (handler *XmppContentHandler) Parse(input string) (err error) {
    buffer := new(bytes.Buffer)
    parser := xml.NewDecoder(buffer)
    var current_input = handler.leftovers + input
    for {
        var token xml.Token
        token, err = parser.Token()
        if err == io.EOF {
            err = nil
        if err != nil && strings.HasSuffix(err.Error(), "unexpected EOF") {
            // Restore State to last know good
            handler.current_element = handler.prev_current_element
            handler.queue = handler.prev_queue
            handler.element_stack = handler.prev_element_stack
            handler.leftovers = current_input

            err = nil
        if err != nil {

        if handler.element_stack == nil {
            handler.element_stack = list.New()

        switch token.(type)  {
        case xml.StartElement:
            start := token.(xml.StartElement)
            element := XmppElement{
                Tag:        start.Name.Local,
                Namespace:  start.Name.Space,
                Attributes: map[string]string{},
            for _, attribute := range start.Attr  {
                element.Attributes[attribute.Name.Local] = attribute.Value
            if element.Tag == "stream" {
                // This element won't close until stream is closed
                handler.queue = append(handler.queue, &element)
            handler.current_element = &element

        case xml.EndElement:
            if handler.current_element == nil {
                err = errors.New("No current element")
            parentListNode := handler.element_stack.Front()
            parent := parentListNode.Value.(*XmppElement)
            current_element := handler.current_element
            handler.current_element = parent
            if parent != nil {
                parent.Children = append(parent.Children, current_element)
            } else {
                handler.queue = append(handler.queue, current_element)

                // We've just completed a stanza - store the current State
                // so we can handle incomplete xml snippets
                handler.prev_current_element = handler.current_element
                handler.prev_queue = handler.queue
                handler.prev_element_stack = handler.element_stack

                current_input, _ = buffer.ReadString(0)

        case xml.CharData:
            if handler.current_element != nil {
                handler.current_element.Text = string(token.(xml.CharData))

    return err
Incidentally, this was one of those times were a TDD approach worked beautifully. Go has excellent support for unit tests, and working in PyCharm with their Go plugin is a joy.


The XmppHandler manages the connection to the Xmpp server and processes the incoming stanzas. It manages the initial handshake, then issues callbacks to handle messages once it's in the ready state.
The Connect method sets up the connection, sends the first part of the handshake and starts a Go routine to handle the incoming stream.
func (self *XmppHandler) Connect(server string, host string, username string, password string) {
    full_address := server + ":5222"
    fmt.Printf("Connecting to %s\n", full_address)
    conn, err := net.Dial("tcp", full_address)
    if err != nil {
        fmt.Errorf("Couldn't connect")

    fmt.Printf("Connection made\n")
    self.connection = conn = host
    self.username = username
    self.password = password

    self.State = "waiting_for_stream"
    self.request_id = 0 = "bot"
    go self.receive()
The receive method, called as a Go routine, is basically an infinite loop, reading data from the socket, parsing it and handling each stanza in turn:
func (self * XmppHandler) receive() {
    for {
        fmt.Print("Waiting to receive\n")
        recvBuf := make([]byte, 4096)
        n, err := self.connection.Read(recvBuf)
        if err != nil {
        msgReceived := string(recvBuf[:n])
        fmt.Printf("Message Received: %s\n", msgReceived)
        parseErr := self.parser.Parse(msgReceived)
        if parseErr != nil {
        fmt.Printf("%d elements in queue\n", len(self.parser.queue))

        for {
            if len(self.parser.queue) == 0 {
            elem := self.parser.queue[0]
            self.parser.queue = self.parser.queue[1:]
iq stanzas get a response back from the server - these are handled by passing a callback to the XmppHandler IssueRequest method:
func (self *XmppHandler) IssueRequest(request string, request_type string, to string, callback func(*XmppElement)) {
    request_id := self.getRequestId()
    to_clause := ""
    if len(to) > 0 {
        to_clause = fmt.Sprintf("to='%s'", to)
    template := "<iq id='%s' type='%s' from='%s' %s>%s</iq>"
    packet := fmt.Sprintf(template, request_id, request_type, self.username, to_clause, request)
    self.requests[request_id] = callback
The callback is then issued when handling a response:
func (self *XmppHandler) handleResponse(response *XmppElement) (bool) {
    fmt.Printf("handleResponse - State %s\n", self.State)
    if response.Tag == "iq" {
        request_id := response.Attributes["id"]
        callback := self.requests[request_id]
        return true

    if self.State == "ready" {
        if response.Tag == "message" {
            if self.HandleMessage != nil {
            return true


With the XmppHandler in place, writing the actual bots is easy. Here is EchoBot:
func main() {
    handler := xmpp.NewXmppHandler()

    HandleMessage := func (element *xmpp.XmppElement) {
        sender := element.Attributes["from"]
        msg := element.Children[0].Text
        fmt.Printf("Got message from %s\n%s\n", sender, msg)
        handler.Message(sender, msg)
    handler.HandleMessage = HandleMessage

    exitSignal := make(chan os.Signal)
    signal.Notify(exitSignal, syscall.SIGINT, syscall.SIGTERM)
Note that it is important that the main thread doesn't exit prematurely - all the work is done in the receive Go routine. The code above sets up a channel and waits on it, until you hit Ctrl-C. This allows the receive to simply block on the Read call, then process data as it comes in. The echo bot is purely reactive so it only needs that one Go routine to do its thing.
Try this out with some XMPP chat client - I've been using Swift. Start a chat with echobot@localhost and you should see everything you say echoed back.


The JumperBot jumps between chat rooms, saying a few random phrases in each room, then jumping to the next one. This can be useful for generating traffic for load testing your chat server, by running any number of those bots. Seehere for a discussion of my Python implementation of this.
type JumperBot struct {
    xmppHandler *xmpp.XmppHandler
    name string
    host string
    numRooms int
    currentChannel string

func NewJumperBot(numRooms int) *JumperBot{
    return &JumperBot {
        numRooms: numRooms,

func (self *JumperBot)Connect(server string, host string, username string, password string) { = username = host
    self.xmppHandler.Connect(server, host, username, password)

func (self *JumperBot)Run() {
    for self.xmppHandler.State != "ready" {
        fmt.Printf("Waiting for %s to log in\n",

    for {
        n := rand.Intn(5) + 5
        for i := 0; i < n; i++ {
            seconds := rand.Intn(10) + 5

func (self *JumperBot) sayRandomPhrase() {
    choice := rand.Intn(len(PHRASES))
    phrase := PHRASES[choice]
    self.xmppHandler.GroupChat(self.currentChannel, phrase)

func (self *JumperBot) joinRandomRoom() {
    roomNumber := rand.Intn(self.numRooms)
    room := fmt.Sprintf("bot_room_%d@conference.%s", roomNumber,
    if room != self.currentChannel {
        if self.currentChannel != "" {
            fmt.Printf("%s: Leaving %s",, self.currentChannel)
        self.currentChannel = room
The main function instantiates a few bots:
func main() {
    bots := make([]*JumperBot, 10)
    for i:= 0; i < 10; i++ {
        fmt.Printf("Creating bot %d", i)
        bot := NewJumperBot(10)
        go bot.Connect(
            fmt.Sprintf("jumperbot_%d", i, ),
        go bot.Run()
        bots = append(bots, bot)
    exitSignal := make(chan os.Signal)
    signal.Notify(exitSignal, syscall.SIGINT, syscall.SIGTERM)
This time we're using more Go routines - the Run method is called as a Go routine as the JumperBot is proactive, rather than simply reactive as the EchoBot was.

Trying it out

The bots do their chatter in rooms named bot_room_0 through bot_room_9. Connect to the server with Swift (or your favorite chat client) and join one or more of those rooms to listen in.

What's next?

I need to polish the XmppHandler - the handleResponse method is kind of quick and dirty. The state machine for the handshake is simply a series of if statements and doesn't deal with errors at all. I would also like to see if there is a better way to handle incomplete XML handling in XmppContentHandler. Hopefully some experienced Go programmers out there will give me some constructive feedback on all this.
Then I want to take a step back and compare the Go and Python implementations. My first impression of the concurrent features of Go are very positive. This feels easier and more natural in Go than using Python 3 and asyncio.
Finally, I want to do some performance comparisons between Python and Go. How many bots can I run on one machine before things start breaking down?


Popular posts from this blog

Mnesia queries

I've added search and trim to my expiring records module in Erlang. This started out as an in-memory key/value store, that I then migrated over to using Mnesia and eventually to a replicated Mnesia table. The fetch/1 function is already doing a simple query, with match_object. Result=mnesia:match_object(expiring_records, #record{key=Key, value='_', expires_at='_'}, read) The three parameters there are the name of the table - expiring_records, the matching pattern and the lock type (read lock). The fetch/1 function looks up the key as it was added to the table with store/3. If the key is a tuple, we can also do a partial match: Result=mnesia:match_object(expiring_records, #record{key= {'_', "bongo"}, value='_', expires_at='_'}, read) I've added a search/1 function the module that takes in a matching pattern and returns a list of items where the key matches the pattern. Here's the test for the search/1 function: search_partial_…

Replicated Mnesia

I'm still working on my expiring records module in Erlang (see here and here for my previous posts on this). Previously, I had started using Mnesia, but only a RAM based table. I've now switched it over to a replicated disc based table. That was easy enough, but it took a while to figure out how to do, nonetheless. I had assumed that simply adding ... {disc_copies, [node()]} ... to the arguments to mnesia:create_table would be enough. This resulted in an error: {app_test,init_per_testcase, {{badmatch, {aborted, {bad_type,expiring_records,disc_copies,nonode@nohost}}}, ... After some head-scratching and lots of Googling I realized that I was missing a call to mnesia:create_schema to allow it to create disc based tables. My tests for this module are done with common_test so I set up a per suite initialization function like this: init_per_suite(Config) ->mnesia:create_schema([node()]), mnesia:start(…

Optimizing Wine on OS X

I've been doing some performance analysis of EVE running under Wine on OS X. My main test cases are a series of scenes run with the EVE Probe - our internal benchmarking tool. This is far more convenient than running the full EVE client, as it focuses purely on the graphics performance and does not require any user input.

Wine Staging One thing I tried was to build Wine Staging. On its own, that did not really change anything. Turning on CSMT, on the other hand, made quite a difference, taking the average frame time down by 30% for the test scene I used. While the performance boost was significant there were also significant glitches in the rendering, with parts of the scene flickering in and out. Too bad - it means I can't consider this yet for EVE, but I will monitor the progress of this. OpenGL Profiler Apple has the very useful OpenGL profiler available for download. I tried running one of the simpler scenes under the profiler to capture statistics on the OpenGL calls mad…