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

Waiting for an answer

I want to describe my first iteration of exsim, the core server for the large scale simulation I described in my last blog post. A Listener module opens a socket for listening to incoming connections. Once a connection is made, a process is spawned for handling the login and the listener continues listening for new connections. Once logged in, a Player is created, and a Solarsystem is started (if it hasn't already). The solar system also starts a PhysicsProxy, and the player starts a Ship. These are all GenServer processes. The source for this is up on GitHub: Player The player takes ownership of the TCP connection and handles communication with the game client (or bot). Incoming messages are parsed in handle_info/2 and handled by the player or routed to the ship, as appropriate. The player creates the ship in its init/1 function. The state for the player holds the ship and the name of the player. Ship The ship holds the state of the ship - …

Large scale ambitions

Learning new things is important for every developer. I've mentioned this before, and in the spirit of doing just that, I've started a somewhat ambitious project.

I want to do a large-scale simulation, using Elixir and Go, coupled with a physics simulation in C++. I've never done anything in Elixir before, and only played a little bit with Go, but I figure, how hard can it be?

Exsim I've dubbed this project exsim - it's a simulation done in Elixir. Someday I'll think about a more catchy name - for now I'm just focusing on the technical bits. Here's an overview of the system as I see it today:

exsim sits at the heart of it - this is the main server, implemented in Elixir. exsim-physics is the physics simulation. It is implemented in C++, using the Bullet physics library. exsim-physics-viewer is a simple viewer for the state of the physics simulation, written in Go. exsim-bot is a bot for testing exsim, written in Go. exsim-client is the game client, for inter…

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_…