Hi, I assume everyone is aware that GRASP limits its message size to 2000 bytes. In case anybody thinks that could be a problem, I don't think it is. Or at least, it's easily overcome for objectives that might become large.
Recently I've coded a pair of demonstration ASAs to check the feasibility of capturing DNS-SD information in an autonomic node, and relaying it to other autonomic nodes via a GRASP objective. That is fairly straightforward, and allows one "smart" ASA to handle the complexities of DNS-SD lookup for any number of dumb client ASAs that don't want to bother with details of the lookup process. In the course of testing this I managed to generate a GRASP message that significantly exceeded the 2000 byte limit set by the GRASP spec. Then I realised that for a negotiation objective, this can easily and reliably be overcome, by fragmenting the reply at ASA level. The process is as follows: - the client ASA opens a GRASP negotiation by requesting a DNS-SD lookup via a GRASP objective. - the "smart" ASA performs the lookup sequence (which involves some parsing of the results) and prepares the value to be returned. It is a sequence of DNS records (as described in RFC6763), which GRASP of course encodes in CBOR for transmission. - if the result will fit in a single GRASP message, it is returned as the objective value in a single GRASP Negotiate message, and we're done. - if the result is too long, it is fragmented, and the first fragment has a marker appended to it (in my test, I simply appended a dummy DNS record 'MORE'). - in that case, the client continues the negotiation (for example, by sending back an objective that contains the value 'ACK') - repeat until done. Coding this added about 25 lines of Python to each ASA. It's reliable because all the transactions run over a TCP connection. Regards Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
