Re: [Anima-signaling] else clause in msg processing, or: where are the errors?

[Brian E Carpenter <[e-mail]>]

On 13/10/2016 09:25, Michael Richardson wrote:
> 
> Looking at my rather minimal GRASP ASA implementation I wondered what I
> should do with msg types I don't understand, or for that matter, with message
> types that are not yet defined.
> 
> I don't see any clear statements in grasp-07 about error replies.
> Maybe I missed it.
> 
> What does one do with an invalid msgtype?  Options are:
>      1) ignore (drop msg)
>      2) die: drop TCP connection
>      3) reply with ???-M_INVALID or something.

I'm not completely sure about this. Sending back an M_INVALID might
risk a loop condition. Silent ignore (or local diagnostic and ignore)
avoids that. I think that's what I coded. Certainly if we abort an
operation, I think we'll always drop the TCP session though.

Note that in a negotiotion session, we can in fact send
M_END with option O_DECLINE and an error string at any time.

You are completely correct that this should be specified.

> I would rather (3), including the errant session-id.
> 
> I'm also a bit concerned that we have no statement about maximum message size.
> As far as I can see, one can send [M_NOOP, 2^31-4ish bytestring, ...] and it
> will be processed and ignored, eating bandwidth and CPU. I'd like to be able
> to sanely allocate/limit space allocated for things.

Well, specifically noop-message = [M_NOOP] so anything after the op-code
is illegal and can be dropped. But, yes, there is no defined limit on
an objective, so for example
flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option / []), +objective]
could be any length. But the other Michael wants to distribute Intent
of any length as a single lump. So what is a poor protocol designer
supposed to do? Should we leave it to the designer of individual objectives?

(Hmmm... this is a problem that a Python programmer can pretty much ignore,
since objects grow as desired.)

   Brian