[OpenTRV-dev] Christmas secure protocol joy!

[Jeremy Poulter]

That sounds good to me. That being said I guess one advantage of separating
the size from the data could be enable a quick way to discard the packet
with minimal processing. eg if the first bytes where
 - total size
 - id size
 - body size

you could very quickly work out if these where sane eg
 - total <= max packet size
 - body+id < total

but I am not really sure I like the idea of that, I think it will make the
protocol less extendible without introducing inconsistencies.

Jeremy

On 29 December 2015 at 13:24, Damon Hart-Davis <dhd at exnet.com> wrote:

> Hi,
>
> Thanks for the analysis.  Yes, all variable-length fields are immediately
> preceded by their length.
>
> Rgds
>
> Damon
>
> > On 29 Dec 2015, at 12:49, Jeremy Poulter <jeremy at bigjungle.net> wrote:
> >
> > If I am reading it correctly you have the total packet length (including
> the body) as the first byte so I am OK with the body size immediately
> proceeding the body data and in general this should be the same format for
> all variable length fields (no checked this is the case in detail).
> >
> > Just my 2p worth.
> >
> > Jeremy
> >
> > On 24 Dec 2015 10:27, "Damon Hart-Davis" <damon at opentrv.uk> wrote:
> > Hi,
> >
> >
> http://www.earth.org.uk/OpenTRV/stds/network/20151203-DRAFT-SecureBasicFrame.txt
> >
> > Matthew W suggests that parsing (etc) might be significantly easier if
> the body length field was moved up somewhere in front of the
> variable-length ID field (or if the ID length was fixed, but I’m pretty
> certain that I don’t want to take that path).
> >
> > I’m loathe to separate the body length from the body, but I’m interested
> in other views on this.  Simplicity in parsing/generating is very valuable
> for the sorts of small systems that this protocol is aimed at.
> >
> > Will Santa bring us a working protocol?  B^>
> >
> > Rgds
> >
> > Damon
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20151229/ac832753/attachment.html>