On 08/12/2016 18:19, Israel G. Lugo wrote:
On 12/08/2016 04:42 PM, Martin Mares wrote:
Hello, world!\n
I think that we should expand static protocol to allow adding or deleting
routes interactively. There are some problematic behavioral details in
it; e.g., how we should handle interactive removal of a route from
configuration. Should we have two independent sets of routes, one
added/removed by reconfiguration, one interactively? Or should we allow
to remove interactively one from configuration? If so, should it respawn
during reconfiguration?
Maybe define a separate protocol which exports routes added/removed online?
I really like this idea! A protocol called "interactive" or "runtime" or
somesuch. It keeps the configuration clean, without having to complicate
the static protocol, or having strange unintuituve behaviors. The
"interactive" protocol would only have routes learned online, so its
behavior is well defined. On bootup it has no routes, and during the
lifetime of Bird, it will learn or forget routes manually through the
CLI or other APIs. A few new CLI/API commands, to "add", "remove" and
"clear". This makes the question of reconfiguration simple: it should
not touch the "interactive" routes. If the user wants to clear them he
will use the "clear" command at runtime.
Regards,
Israel
As long as each "record" is at most 512 bytes the protocol could just
offer a named pipe to add new records. That would be crude because there
is simple way to acknowledge writes, but trivial to interface with. A
better way would be to replace the pipe with a unix domain sequential
packet socket and simple protocol to report success/failure.
