Re: Api idés

2015-05-15 10:56 skrev Ilya Voronin:
> Take a look at  https://github.com/ivoronin/kadadm [3]

Looks fine for client side.


But on server side we need one socket for many clients, that lead to:
for every new connection a new thread is created.

To server multiple connections a input que is needed and process request 
sequentially.
To service them simultaneously using one thread per each client 
connection.

while (1) {
     accept a connection;
     create a new thread to the client;
}

Also a output que is needed to not slow down other process when large 
data stream sends.

The thread reads from and writes to the client connection as necessary.

That is all behind api interface.

Alex will code to be written in ANSI C.


> On Fri, May 8, 2015 at 5:38 PM, jan <[email protected]> wrote:
> 
>> Hi Patrik,
>> 
>> When checking keepaliveds snmp modul, i found it quit near what a
>> low
>> level api
>> needs !.
>> 
>> Only needed to add abstractions level a bit and restore ascii style
>> api
>> functions in library.
>> 
>> Reuse code from that, and lift out snmp as a separate modul, like
>> cli.
>> and exend with write/config tokens and api developer save some
>> time.
>> 
>> 2015-05-07 14:55 skrev jan:
>>> 2015-05-07 08:16 skrev Patrick Schaaf:
>>>> I think a binary, RLE API would be way over the top. This is in
>> no way
>>>> performance critical. A text stream based API is way easier to
>> develop
>>>> against, and debug.
>>> 
>>> Binary is for one reason speed, think if you get data for graphic
>>> purpose
>>> for every interface, it will be a hug overload to send that in
>> ascii
>>> format.
>>> 
>>> Updates every 1/10 seconds, packet p/s for tx / rx and actual
>> size.
>>> 
>>> 10 interface and 10 graph it would not be optimal to send in
>> ascii.
>>> 
>>> For a CLI applications it's overkill you don't need that
>> performance.
>>> 
>>> Programmer to develop a cli or other tools need a library to
>>> encapsulate
>>> low level RLE to "high level ascii land" and developer never need
>> to
>>> care about any RLE stuff at all, use command/tokens in ascii
>> format as
>>> normal to
>>> library routines instead.
>>> 
>>>> Some rough notes on how that could look:
>>>> 
>>>> 1) Overall structure of communication:
>>>> 
>>>> Transport over UNIX domain socket (no auth required by default),
>> or
>>>> TCP (auth required).
>>> 
>>> Agree
>>> 
>>>> Daemon never sends anything unless provoked (sent a command
>> line).
>>>> What the daemon sends in response to a command, depends on the
>>>> command. All sent commands and replies are n or rn terminated
>> text
>>>> lines (no fancy encoding - or is there any need for that that I
>> can't
>>>> see?).
>>> 
>>> But if you wont to monitor something like logfile you should get
>>> that with a single command, not repeted (like polled),send until
>> "stop
>>> send log file"
>>> or socket close for any reason.
>>> 
>>> should work like "tail -f /var/log/keepalved.log"
>>> 
>>>> Command lines sent to the daemon are space separated token
>> sequences.
>>>> They all start with a keyword, further tokens are interpreted
>>>> accordingly.
>>> 
>>> Agree if its a CLI application,
>>> You need /keyword/next_token ... or /keyword next_token ...
>>> 
>>> If you are in interface level and want to do "/ip ro sh"
>>> to display all routes without to be in top level.
>>> 
>>> 
>>>> Replies, when expected, all start with a keyword (indicating
>> success,
>>>> failure, what it expected next for modal stuff), with the rest
>> of the
>>>> line purely informational. These reply keywords are chosen to
>> NEVER be
>>>> valid first keywords of configuration or status output lines
>> (stuff
>>>> that would appear in show commands that we'd want to be easily
>>>> copy+pasteable)
>>>> 
>>>> Any request or reply keyword is documented and interpreted case
>>>> sensitive. Programmers should not need to do case conversion to
>>>> recognize stuff.
>>> 
>>> Agree
>>> 
>>>> 2) Authentication and Authorization
>>>> 
>>>> When required (*), the first thing a client MUST do is
>> authenticate.
>>>> If the client thinks it does not need to authenticate, but it
>> should,
>>>> its first command, unless it starts an authentication, elicits a
>>>> response, e.g. "AUTH-FAIL", and the daemon drops the connection
>>>> immediately afterwards.
>>>> 
>>>> Authentication starts with a command "auth user <USERNAME>".
>> That will
>>>> always elicit a response:
>>>> * "AUTHENTICATED <AUTHORIZATION-LIST*>" when no authentication
>> is
>>>> required. Client may proceed, and use any of the commands
>> covered by
>>>> the space-separated list of authorization tokens (may be stuff
>> like
>>>> CONFIG, SHOW, SHUTDOWN, ... and all commands should clearly
>> document
>>>> which authorization tokens are required to use them). This kind
>> of
>>>> reply is also used when a user that needs authentication, has
>>>> successfully completed it.
>>>> * "AUTH-NEEDED <SCHEMES+>" when further authentication is
>> needed;
>>>> lists, space separated, authentication schemes permitted. NOTE:
>> this
>>>> list MUST reflect what configuration allows, and MUST NOT vary
>>>> depending on the <USERNAME> from the request.
>>>> 
>>>> When AUTH-NEEDED, client then sends "auth scheme <SCHEME>
>>>> <CREDENTIALS*>". For schemes that don't need further steps, an
>>>> AUTHENTICATED reply (see above) is sent when the credentials
>> were
>>>> good, or "AUTH-FAIL" and connection close otherwise. For schemes
>> that
>>>> require further steps, a reply of "AUTH-CHALLENGE <SCHEME>
>>>> <whatever*>" is sent, and the client is expected to send another
>> "auth
>>>> scheme <SCHEME> <CREDENTIALS*>" line to complete.
>>>> 
>>>> Once the client successfully authenticated, it knows that it can
>> do
>>>> (via the AUTHORIZATION-LIST from the AUTHENTICATED reply.) Maybe
>> the
>>>> client further would like to authenticate the daemon - that
>> could be
>>>> requested with an "auth yourself <...>" command, won't go into
>> details
>>>> now.
>>>> 
>>>> Auth _configuration_ should be only possible with suitable
>> privilege,
>>>> only shown (when listing config) with suitable privilege; auth
>>>> credentials ALWAYS separate from online modifiable configuration
>>>> (separate config file - no need to be easy to change on the fly)
>>> 
>>> Need only 3 level: write access, read access, both read/write
>>> in low level api.
>>> 
>>> Always send salt value in reply cmd with a plain login
>>> 
>>> Login with name and password a second time and you have access
>>> read/write/both
>>> 
>>> 
>>>> 3) Command Discovery
>>>> 
>>>> For the benefit of CLI clients supporting autocompletion, it
>> might be
>>>> interesting to implement a discovery mechanism regarding
>> commands
>>>> supported by the daemon. Thinking along these lines:
>>> 
>>> Agree
>>> 
>>> CLI program should ask all cmds and argument from low level api
>> in
>>> initialization task.
>>> 
>>> 
>>>> * "info commands" would result in a multiline reply. Each line
>> starts
>>>> with "COMMAND " followed by a single valid command syntax.
>>>> Placeholders there, e.g. <IP>, would indicate variable parts of
>> the
>>>> command. The list is terminated by a line starting / reading
>>>> "COMMAND-END".
>>>> * "info version" would result in a single line reply "VERSION
>>>> <daemon-version-number>
>>>> <hash-of-valid-command-defining-config-parts>". This would be
>> good for
>>>> the benefit of CLI clients to be able to cache "info commands"
>> replies
>>>> - the CLI could keep the command list for the given
>> authenticated user
>>>> for as long as the daemon-version-number and hash doesn't
>> change.
>>>> 
>>>> 4) Configuration Changes
>>>> 
>>>> Using a "configure" command, the client indicates it wants to
>> change
>>>> configuration. This mail is already too long, though, so I'll
>> stop
>>>> here :)
>>> 
>>> 
>>>> best regards
>>>> Patrick
>>> 
>>> --
>>> 
>>> best regarding
>>> 
>>> /Jan Holmberg
>>> 
>>> 
>> 
> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across
>>> Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable
>>> Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y [1]
>>> _______________________________________________
>>> Keepalived-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel [2]
>> 
>> --
>> 
>> mvh
>> 
>> /Jan Holmberg
>> 
>> 
> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across
>> Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable
>> Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y [1]
>> _______________________________________________
>> Keepalived-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel [2]
> 
> 
> 
> Links:
> ------
> [1] http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> [2] https://lists.sourceforge.net/lists/listinfo/keepalived-devel
> [3] https://github.com/ivoronin/kadadm
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across 
> Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable 
> Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel

-- 

mvh

/Jan Holmberg

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y