Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


henrietta edited this page · 6 revisions
Clone this wiki locally


Hosts, to communicate with Vanad, need to utilize it's specific protocol. It's aimed to be fast, does not require any security as Vanad is assumed to run in a secure environment.

Please mind to ensure proper ports are firewalled from the world!!!


Client, upon connecting to database, sends a request. It's form is:

byte RequestType
byte TablespaceID
dword KeyLength
dword ValueLength might be zero if it doesn't make sense
byte[KeyLength] Key
byte[ValueLength] Value

Requests may block for awhile. Protocol frame is made so as to be fast-scanned by receiver. Server responds with this:

byte ResultCode
dword DataLength might be zero if it wouldn't make sense otherwise
byte[DataLength] Data

Server might now drop the connection, depending on flags set by client

Request codes

Here is a list of request codes, depending on code of RequestType

  • 0x00: GET - Returns value of given Key. Will return with ResultCode=1 if Key could not be found, because it's either NULL or deleted. Will return ResultCode=0 and non-empty Data upon success. Value ought to be NULL.
  • 0x01: ASSIGN - Sets Value to Code. Obliged to return with ResultCode=0.
  • 0x02: DELETE - NULLs given Key's Value. Obliged to return with ResultCode=0. Value ought to be NULL.

Take note that if most significant bit of RequestType(ie. 0x80) is set, server will close the connection upon receiving successful reply. Otherwise, connection continues to stay open.

Keepalive logic

It is advised that user uses open-transact-close paradigm. Vanad is meant to be very fast as far as those types of connections are concerned and uses thread-pooling where multiple threads accept() on blocking server socket.

Next request is expected to arrive within a timeout period(4 seconds), otherwise connection will be discarded. As needs arise, I may implement some other type of logic - but that would complicate the server a bit, as it would need to dynamically spawn threads in response to connection load.

Something went wrong with that request. Please try again.