Which medium is this an issue for? As you note, for files and HTTP
responses it's not a problem in practice. i'd guess nor for NFC tags nor QR
codes.


On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> I'm experimenting with BIP70/71 (payment protocol) usage in face to face
> payments (more on that soon).
>
> I've excountered an issue with the protobuf format. Protobufs are not
> self-delimiting. That means if you're reading from an undelimited
> stream, you will read endlessly because you don't know how much to read.
>
> The current BIP70 implementations probably work because they're reading
> either from a file or from an HTTP resource which sets the
> Content-Length header. Trouble is the Content-Length header is optional,
> and also there are many kinds of streams that don't have this built-in
> delimiting mechanism.
>
> The Java protobuf API solves this by offering delimited I/O, like
>
> payment.writeDelimitedTo(os);
>
> This writes the size of the message as a varint before writing the data.
> I don't know about protobuf implementations for other languages but I'd
> expect them to offer something compatible.
>
> However, this leading varint is an incompatible change and would need to
> be added to the spec.
>
> I specifically encountered this with PaymentMessage and PaymentACK, but
> it might be a good idea to apply this to all messages if any. Open for
> discussion.
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>