Crypto Trading Framework

In my free time, I’ve been messing around with cryptocurrencies. Bitcoin, Ether, Litecoin as well as a couple of other, lesser known altcoins. I am mainly using GDAX and Bitfinex for my trades. It’s a lot of fun!

Pretty much all exchanges offer some sort of API. I created a simple .NET client for the GDAX and wrote a simple trading framework. I decided to learn the actor model for this project, as it makes writing trading bots easier. Speed is not an issue, as I’ve noticed GDAX’s position tracking system cannot keep up with my apps.

Today I have open sourced my framework on GitHub under revised BSD license. You can clone it from here. It ships with a simple “buy low sell high” strategy which illustrates how to consume prices and interact with orders.  More exchange backends to come (or feel free to contribute more).

SafeBuffer and UnmanagedMemoryStream

At work I have a situation where I have some binary data allocated in the native code. It’s pretty much a raw char*. I then would like to access that same information from the managed side. But how? Of course I can just copy the data to a byte[] but that’s just wasteful.

I did some googling around and found the obvious solution – UnmanagedMemoryStream. It can take pointers, or a SafeBuffer. The latter is basically a smart wrapper around memory handle. Take a look at the code I came up with. I hope somebody will find it useful. It’s still work in progress and can use some love, so any comments are welcome.

I needed to pass the std::unique_ptr as r-value, otherwise the linker complains (thunks for non-existent copy constructor). I still need to clean this code up to handle custom deleters. But it serves my needs for now.

Edit: There is a bug in this code. Can you spot it? 😉

Async Patterns with C# – Handling Requests

This is a continuation of my earlier blog post regarding asynchronous operations in .NET. We are now going to discuss the various ways of issuing and receiving results from asynchronous requests.

There are three main ways of issuing an asynchronous request and later receiving the result. They are described in the sections below.

Callback methods

The pattern of specifying a callback method goes way, way back. And it is still being widely used today. The idea is simple:

  • Call a method that starts an asynchronous operation
    • Pass in a delegate to the function you want called when the operation completes
    • Optionally specify user data
  • The specified callback methods gets called asynchronously. The arguments passed to it usually contain:
    • The result of async operation
    • Error indication (Exception object or error code)
    • User data

Depending on the needs the callback method could be a simple delegate or an interface.


The approach of passing delegates is convenient, because one could easily take advantage of closures/lambdas. That way objects in scope become available to the “callback” method.

A main disadvantage would be that it is difficult to “cancel” the asynchronous operation. There also is no “identity” to the operation (unless we consider the pair <delegate, user data>).

Although there are no technical reasons, in practice only 1 delegate gets passed as a callback.


When viewed simply as “collections of methods,” interfaces could be considered a special case of “callbacks” or, as Java folks like to call them, listeners. In Java it is convenient to pass interfaces to receive callbacks, because Java allows for creation of inline anonymous classes. This is unfortunately not the case for C#, which is why the “request object” is a more interesting pattern for the .NET crowd. More on that in the next section.

Since interfaces represent concrete objects, they do have identities. This could allow for “cancelling” async requests by passing the same observer instance that was used when making the request.

Request objects

This is a very common pattern that most coders are familiar with. The premise is simple:

  • Create an object representing the asynchronous operation
  • Optionally set properties on the request object, for instance store some user data.
  • Hookup the event handler (or handlers).
  • Call a method starting the asynchronous action.
  • Receive the event with results. Extract the information from event arguments.

The main advantage of using the request object is that the object itself is responsible for emitting the events signaling the completion/failure of the async operation. In other words, the “sender” passed to the event handling function is the request. Users can store custom data with the request and easily get to it from the handler. This could be accomplished via composition (for example by having a Tag property), or by inheritance (by allowing the users to extend the request object).
Depending on the needs, the request object can have multiple events. For instance, one for signaling completion, and one errors.
The request object could also optionally provide a “Cancel” method that would stop the asynchronous action, or at least prevent the events from being fired.

Once can classify the request objects depending on how they are created, and who actually starts the asynchronous operation. Several main categories are briefly described below.

Self-created, self-submitting

The user can create the request object by calling its constructor directly. The method starting the async action is off the request object itself.
This variation of the pattern is convenient as it could allow for extending the request object through inheritance.

Factory-created, self-submitting

The user creates the request object by calling a factory method. Typically the factory is some kind of main “API” object that contains multiple operations. Once created, the request object is self-sufficient and can be “submitted” using its own method.
Since the request is constructed by a factory, it usually means that extending the request object is not allowed.

Self-created, factory-submitted

The user is able to create the request object by calling its constructor. This could potentially allow for inheritance scenarios.
Asynchronous action is started by calling a method on another object, which usually ends up being the main “API” object.

Hybrid – BeginInvoke/EndInvoke

The pattern of BeginInvoke/EndInvoke that is build into the .NET framework can be seen as a hybrid of callback method and request object. The usage is a follows:

  • Call a “BeginInvoke” method to start an async operation
    • The method accepts a callback delegate and user data.
    • The return of the method is an IAsyncResult instance that the caller needs to hold on to
  • IAsyncResult could be used to wait until async operation completes and to cancel it.
  • When the callback function gets called
    • Call “EndInvoke” and pass it the IAsyncResult instance acquired from the “BeginInvoke”
    • The “EndResult” will return the “outcome” of the async operation.

Async patterns with C#

Lately I have been doing a lot of asynchronous development. At work I’m designing a trading API that is very asynchronous in nature, and in my spare time I have been messing around with Silverlight.

I would like to share a few different patterns for retrieving data asynchronously that I have encountered. Hopefully my blog posts will be a good resource for you.