Sorting share trading books with Golang

Golang's sort package provides a set of primitives that allows us to define the order of our own structures. Furthermore we can define various ways of sorting the structures by extending the base collection.

Let say we have we're storing orders in a share trading book.

// order struct
type Order struct {
    Ind      string // buy sell indicator
    Epic     string
    Price    float64
    Quantity float64
    Time     int64
}

// base orders array type
type Orders []Order

Now, so that we can use the sort package we need to define a few simple functions.

// default length func
func (o Orders) Len() int {
    return len(o)
}

// default swap func
func (o Orders) Swap(i, j int) {
    o[i], o[j] = o[j], o[i]
}

So that we can sort Orders in many ways we need to extend the base structure.

// specific buy order stuct
type BuyOrders struct {
    Orders
}

// specific sell order struct
type SellOrders struct {
    Orders
}

Now, we need to specify the less function for each type. Buy orders are sorted price descending, time ascending and sell orders are sorted price ascending, time ascending.

// Define the order of buy orders
func (o BuyOrders) Less(i, j int) bool {

    // we've assumed its the same stock and currency
    // buy orders are reversed

    if o.Orders[j].Price < o.Orders[i].Price {
        return true
    }

    if o.Orders[j].Price > o.Orders[i].Price {
        return false
    }

    // same price, check time priority
    // because of this element we cannot simply call reverse
    return o.Orders[i].Time < o.Orders[j].Time
}

// define the order of sell orders
func (o SellOrders) Less(i, j int) bool {

    if o.Orders[i].Price < o.Orders[j].Price {
        return true
    }

    if o.Orders[i].Price > o.Orders[j].Price {
        return false
    }

    // same price, check time priority
    return o.Orders[i].Time < o.Orders[j].Time
}

To sort an array of Orders in buy sequence we can now simply call

sort.Sort(BuyOrders{orders})

or alternatively in sell sequence

sort.Sort(SellOrders{orders})

The link shows an example of this in action by inserting orders into an order book and printing the level 1 price and level 2 prices in the correct sequence.

The Reliability of Go

As part of the Canonical Cloud Sprint taking place in San Francisco last week I attended Dave Cheney's talk at the GoSF meetup on the porting and extension of juju. Juju is an open-source cloud management and service orchestration tool that if you haven't heard of yet, you soon will have.

After the talk an audience member asked if Go was reliable. Having used Go in production for coming up to three years now, without incident, this came as a bit of a surprise to me. Prior to moving to Canonical I worked for one of the UK's largest market makers. A market maker is basically a wholesaler for institutional share traders and stock brokers. During my time there I replaced several key systems components with Go.

System monitoring.
The services within the system were monitored by a python script, pinging each node, discovering services, connecting the networking dots, checking health etc. Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results. The script would often stall whilst processing the vast amounts of data produced. After porting the script to Go the runtime was reduced to under one second, and we never saw a single stall when processing.

Data store.
A legacy relational database was replaced with a Go based key/value store to remove bottlenecks at market open. This service is now the key piece of architecture in the system, processing all inbound and outbound quotes/orders to and from the London Stock Exchange, the Multi-lateral Trading Facilities, and key exchanges across Europe. This service processes instructions at an average of 7 microseconds (actually, 6 under Go1.1), and never once failed, even at peaks, processing tens of thousands of instructions per second. Go is currently providing key infrastructure components within the finance industry.

As I left my old position I was in the process of swapping the messaging middleware and the third-party price feeds with services written in Go.

Go's adoption is gathering pace thanks to the terse syntax, straightforward powerful standard library, excellent tooling and concurrency primitives.

Go shows real maturity beyond its relatively young age due to the experience of the core development team and the consideration that is shown when introducing language constructs and extending the standard library.

I changed positions so that I could work with Go full-time. Ask anyone that knows me and they'll tell you that I'm not a betting man; you better believe Go is reliable.

Waiting for Golang channels to drain

Golang's channels easily map onto the producer consumer pattern. Lets assume that everything that is produced needs to be consumed, even if the process receives a SIGTERM.

The following example shows how we can register channels, monitor for a kill signal, and then wait for everything to be consumed.



package main

import (
"log"
"os"
"os/signal"
"reflect"
"syscall"
"time"
)

var (
BufferSize = 512
MaxIter    = 10
monitored  []interface{}
c          = make(chan int, BufferSize)
stopping   bool
)

func RegisterChannel(i interface{}) {
monitored = append(monitored, i)
}

func MonitorSigTerm() chan bool {
s := make(chan os.Signal, 1)
b := make(chan bool)
signal.Notify(s, syscall.SIGTERM)

go func(c chan os.Signal, b chan bool) {
_ = <-c
log.Println("Cleaning up")
// tell the caller
b <- true
for _, i := range monitored {
ch := reflect.ValueOf(i)
if ch.Kind() != reflect.Chan {
continue
}
prev := 0
iteration := 0
for {
if ch.Len() == 0 {
break
}

if prev == ch.Len() {
iteration++
// enough?
if iteration >= MaxIter {
log.Println("Dropping")
break
}
} else {
iteration = 0
}

prev = ch.Len()
log.Printf("Draining:%v\n", prev)
// other goroutines are working, let them
time.Sleep(1e9)
}
}
os.Exit(1)
}(s, b)
return b
}

func main() {
RegisterChannel(c)
stop := MonitorSigTerm()

go func() {
i := 0
for {
if stopping {
break
}
i++
c <- i
time.Sleep(1e9)
}
}()

go func() {
for {
i := <-c
log.Printf("rx:%v\n", i)
// slower read
time.Sleep(2e9)
}
}()

stopping = <-stop

// wait for cleanup to finish
select {}

}

Golang: Overflowing JSON

Go's json.Unmarshal function works perfectly by taking a JSON blob and attempting to create a known structure from the data.

type S struct {
    A int
    B string
} 

var s S

json.Unmarshal([]byte(`{"A": 42, "B": "b","C": "c"}`),&s) 

I recently had to construct a structure in this way, but also needed to store data that overflowed the structure.

I came up with this little function to do just that.

func UnmarshalJSON(src []byte, dst interface{}) (remainder []byte, err error) {
    var m map[string]interface{}
    o := make(map[string]interface{})
    _ = json.Unmarshal(src, &m)

    // put anything that doesnt match dst into a map
    rv := reflect.ValueOf(dst).Elem()
    for k, v := range m {
        if rv.FieldByName(k).IsValid() == false {
            o[k] = v
        }
    }

    // marshal the map to JSON
    remainder, _ = json.Marshal(o)

    // now fill the dst
    err = json.Unmarshal(src, dst)

    return
} 

Now if you set src bytes to the remainder bytes in the call you can use this function to 'consume' structures from JSON blobs.

src, _ = UnmarshalJSON(src,&myStruct)

GOBing Down Secure Websockets

Golang's gob package allows you to do something interesting when designing message protocols. 

Consider these structures:

Now I can construct a message and assign whichever message body is required. 



The gob package handles the passing of the populated and mismatched fields during the encode / decode.

Below is a noddy example of passing such message structures through a secure websocket. The code not only shows the gob package in action but also highlights how trivial golang makes the coding of a secure websocket for both the client and server.

Server:

Client:

Backwards Thinking

I'm a golang retard. I can't help it; I keep thinking backwards. I keep thinking in old paradigms.

I had to serialise a structure into JSON and wanted to suppress nil values.

type Data struct {

    Batch []map[string]interface{}

}

Now, I tried using the omitempty tag and that didn't work as the library only operates on structure fields and not the elements of the array.

So....... I sat there...... and I thought......... right I need a method on this structure that will serialise it into JSON and omit the individual array elements that are not yet populated.

Then I sat there and thought............that's a 'lot' of typing........there must be a better way...........

I sat.....

I sat a bit more......

I got up for a drink........my mind wondered..........to....... a video I had seen a few months back.........

Ken: “The thing I'm most pleased about is slices”.

BOOM!

batch.Batch = batch.Batch[0:pos]
b, e := json.Marshal(batch)

This may have been immediately obvious to many people; but it wasn't to me.

Part of my brain is still stuck in the old world of OOP. Oh, I must have a method to work on an objects data. I can't copy arrays; it's too expensive. I must type pages and pages of code to do 'real work'.

I think it's time for me to re-read effective go.

Perhaps we all should. We're probably missing more than we realise.

Message Hub

At the minute I'm having to push a lot of JSON around. To aid in this I've written msgHub. This utility sets up a TCP server allowing the pub/sub of generic JSON data. I've found it to be extremely useful; you might too.

msgHub -tcpPort=[port] -tcpDelimiter=[ascii code]

e.g. start on 12345 using line feed as delimiter

msgHub -tcpPort=12345 -tcpDelimiter=10

JSON message format:

{"event": "sub", "type": "messageType", "key": "messageKey"}

{"event": "unsub", "type": "messageType", "key": "messageKey"}

{"event": "pub", "type": "messageType", "key": "messageKey", ........ any json}