Use socket connection to bird instead of calling birdc

[stv0g]

I would propose to use bird's socket interface instead of spawning birdc. The protocol is almost the the same as the stdout of birdc.

There is already a golang package for it: https://github.com/czerwonk/bird_socket

We gain:

• Speed
• Smaller memory footprint (#9, #17)
• Better error handling as the socket protocol adds status codes

We loose:

• Restricted mode (birdc -r)

[stv0g]

Here is an example of the socket protocol:

Output of birdc show memory

BIRD memory usage
Routing tables:    165 MB
Route attributes:  298 MB
Protocols:         495 kB
Total:             466 MB

Socket communication

Sniffed with socat

< 2020/04/26 04:10:38.820683  length=23 from=0 to=22
0001 BIRD 2.0.7 ready.
BIRD 2.0.7 ready.
> 2020/04/26 04:10:38.820889  length=12 from=0 to=11
show memory
< 2020/04/26 04:10:39.302258  length=137 from=23 to=159
1018-BIRD memory usage
 Routing tables:    165 MB
 Route attributes:  298 MB
 Protocols:         495 kB
 Total:             466 MB
0000

See also: https://github.com/alice-lg/birdwatcher/blob/master/docs/bird-client-server.txt

[annikahannig]

Using the socket directly was our first approach back at the hackathon. :)

I'll checkout Daniels bird socket library! Thanks for the hint!

[annikahannig]

Not sure if it will really reduce the memory footprint though...

[johannesmoos]

We loose:

* Restricted mode (`birdc -r`)

Yes, this is exactly the reason why we changed it to use birdc(being aware of the benefits you named). Can we quantify the performance and memory overhead of using birdc?

Maybe we can implement a config option to have the choice of communicating directly with the socket or via birdc?