Bester: Progress update

Tristan B. Kildaire


New things

Adding multiple listeners

Something I wanted to add badly and have as a nice little extra feature, not something that was inherent to the bester protocol itself, was to add support for IPv6 to the bester daemon. Therefore last night, after most of my university work had been completed I decided that it was time to slightly refactor the way the server listened for incoming connections. Instead of the accept-and-dispatch loop being a part of the BesterServer class I decided that that class should, yes, still be the central point of coordination in terms of keeping track of **all** connections but that connections should be appended to the BesterConnection[] ` array via the listeners that were running. I wanted to allow the user to be able to let their server, if they wanted to, be able to bind to TCP over IPv4 along with binding to TCP over IPv6 as well and even, maybe, UNIX domain sockets!

The way I worked this out in the code was by creating a class named BesterListener which ran on its own thread and had an already implemented connection accept-and-dispatch loop for dispatching new connections to BesterConnection thread objects. Then for implementing specific protocols like TCP over IPv4 or over IPv6 or using UNIX domain sockets, all I did was to create several other classes that extended the BesterListener class and justset the super-class’s socket object to the one created for that specific protocol.

And it worked like a charm!

The configuration for something like this looks like this in server.conf :

network" : { 
    "types" : ["unix", "tcp4", "tcp6"], 
    "unix" : { 
        "address" : "besterUNIXSock" 
    "tcp4" : { 
        "port" : "2220", 
        "address" : "" 
    "tcp6" : { 
        "port" : "2221", 
        "address" : "::" 

So all you need to do is specify that you want certain socket types and then just provide their binding informations.

A new addition to the sendClients sendServers response commands

As I was discussing bester with a friend of mine, he indirectly gave me an idea for something interesting I wanted to implement. Normally if a user wants to get some processing done by a handler, we currently have it working as follows. Client sends a message to the server, server gets it and dispatches it to the message handler. The only part that we haven’t done is handling of the reply that the server receives back from the message handler. We have the reply working in that it comes back but we haven’t done much with regards to that. So sendClient and sendServer are essentially not implemented. But in the example where say now a user wants a message A to be processed by a handler for messageType1 but then wants the response it gets back from the handler (indirectly via the server) to be processed again by another handler, then the user must send another message (the processed one, back). Now, I don’t mind this and of course you can still do this after the next feature I am going to mention gets implemented, but the thing I was thinking of doing was implementing a command named sendHandler , which means after the server received a message from the client and dispatched it to the messageType1 message handler that it (the handler) can then generate a response message that commands the server to push that message to another handler and then somewhere down the line the server gets a response with a command that is not sendHandler and the message ends back at a client or another server (sendClients and sendServers respectively).

Take it for a run yourself!

All you have to do is clone the repository here and then cd into and run the following.

Firstly cd testing/ and then run python3, this starts a bogus message handler. Now, start the bester daemon by running dub, and then lastly run a client example code by running cd testing and python3!

You should see some output!

And that’s all for now!