[ANN] SimpleWebsockets - renamed from `Websocket`

Package Announcements
1

SimpleWebsockets.jl

Build Status Coverage Status GitHub Repo stars

This is a rename of Websocket in order to avoid confusion with the existing WebSockets package.

using Pkg
Pkg.add("SimpleWebsockets")

Basic usage server:

using SimpleWebsockets

server = WebsocketServer()
ended = Condition() 

listen(server, :client) do client
    listen(client, :message) do message
        @info "Got a message" client = client.id message = message
        send(client, "Echo back at you: $message")
    end
end
listen(server, :connectError) do err
    logWSerror(err)
    notify(ended, err.msg, error = true)
end
listen(server, :closed) do details
    @warn "Server has closed" details...
    notify(ended)
end

@async serve(server; verbose = true)
wait(ended)

Basic usage client:

using SimpleWebsockets

client = WebsocketClient()
ended = Condition()

listen(client, :connect) do ws
    listen(ws, :message) do message
        @info message
    end
    listen(ws, :close) do reason
        @warn "Websocket connection closed" reason...
        notify(ended)
    end
    for count = 1:10
        send(ws, "hello $count")
        sleep(1)
    end
    close(ws)
end
listen(client, :connectError) do err
    logWSerror(err)
    notify(ended, err.msg, error = true)
end

@async open(client, "ws://localhost:8080")
wait(ended)
2

This looks very nice. What would you say is the biggest difference to the WebSockets package in terms of use and development philosophy you applied?

3

Thanks @Jon_Norberg

I started out on this package because I needed a WS client that could deal with high frequency (ms) market data streaming.

It was also very important that I was able to reliably, instantly reconnect on requests from the server, data frame errors and network errors. As such, I needed informative error reporting and event hooks at an API level to decide what actions my application should take.

I started by trying to wrap an API around existing solutions, but it became apparent that Julia Async behavior is a powerful, tricky, fickle beast… Existing solutions had pretty dense, monolithic architectures.

This prompted me to start from scratch and port a WS architecture I was familiar with from the Node.js websocket package. This is predominantly OOP with a well documented and flexible high level API - something which is mirrored in SimpleWebsockets.jl

What I have now is working well for me. I hope that over time a few more souls will find it handy and start refining these particular points of development:

  • Memory allocation. I have done my best to allow for minimal IO buffer allocations and reuse of these allocations under all circumstances. This may still be sub-optimal in the server context, especially a generous incoming message buffer for each connected client instance. I have no idea how well this is going to scale.
  • Better test coverage - async, tricksy tricksy. I am at 86%, but with better thought this can improve a lot. I just don’t have the immediate resources.
  • Autobahn testing - again, time and resources.

Also - websocket extensions are not implemented. This is mostly because I need to research what these are and exactly how they work. I have had no need for them in my work yet.

1 Like