mirror of
https://github.com/alice-lg/birdwatcher.git
synced 2025-03-09 00:00:05 +01:00
Writeup of the BIRD client/server protocol.
This commit is contained in:
parent
3cdf1c9448
commit
3440667336
1 changed files with 72 additions and 0 deletions
72
docs/bird-client-server.txt
Normal file
72
docs/bird-client-server.txt
Normal file
|
@ -0,0 +1,72 @@
|
|||
Here's a small writeup of our findings in BIRD so far.
|
||||
|
||||
Barry O'Donovan, INEX - the company behind IXP Manager. Wants to do
|
||||
PHP screen scraping of the BIRD client to create an API to BIRD.
|
||||
|
||||
His API design:
|
||||
|
||||
https://github.com/inex/birds-eye-design/
|
||||
|
||||
https://github.com/inex/birds-eye-design/blob/master/v4-show-protocols-all
|
||||
|
||||
We investigated a better way of doing the API so we don't have to run
|
||||
PHP on the routeserver. Is there a specified protocol between the BIRD
|
||||
client and daemon? Daniel and I had a look here:
|
||||
|
||||
git://git.nic.cz/bird.git
|
||||
|
||||
specifically the branch "client-next" which has seen some action
|
||||
regarding the client/server protocol and looked at it. It seems there's
|
||||
not much of a formal definition of the protocol.
|
||||
|
||||
Client connects with a unix socket through, client.c:server_connect(),
|
||||
then they just send whatever commands they get from the CLI and the
|
||||
entire command is parsed by the *server*! Replies are prefixed by a
|
||||
return code but that's basically it for specification of the replies!
|
||||
|
||||
Client connects with a unix socket, client.c:server_connect(), using a
|
||||
global variable server_fd for all communication. The Unix socket is
|
||||
called something like bird.ctl, typically /var/run/bird.ctl.
|
||||
|
||||
A simple
|
||||
|
||||
% nc -U /var/run/bird.ctl
|
||||
|
||||
gives access to the server directly! However, not a well specified
|
||||
protocol. There is, however, client/reply_codes.h:
|
||||
|
||||
/*
|
||||
Reply codes of BIRD command-line interface
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
0xxx Action suceessfully completed
|
||||
1xxx Table entry
|
||||
2xxx Table heading
|
||||
3xxx Internal messages
|
||||
8xxx Run-time error
|
||||
9xxx Parse-time error
|
||||
<space> Continuation
|
||||
+ Spontaneous printout
|
||||
*/
|
||||
|
||||
but no real protocol. You have to parse everything after the reply
|
||||
codes from the position, no better than screen scraping from the
|
||||
client.
|
||||
|
||||
An interesting option might be to look for all the response generator
|
||||
in the code which returns the replies and instead generate JSON
|
||||
directly instead of sending free form text.
|
||||
|
||||
All output through the server/client interface is probably done with
|
||||
cli_msg() and it seems many of command output is from nest/*.c and
|
||||
proto/*.c and sysdep/*.c.
|
||||
|
||||
The actual grammar for the CLI commands is done in Bison .y files.
|
||||
Look for CF_CLI() to see what functions the actual commands run. Then
|
||||
you can go to these command functions and generate, say, JSON as
|
||||
output instead of using the more freeform cli_msg().
|
||||
|
||||
You might use
|
||||
|
||||
% git grep -A 1 "CF_CLI("
|
||||
|
||||
to find them all.
|
Loading…
Add table
Reference in a new issue