[erlang-patches] Add specific return for incomplete asn.1 packets

[Vincent de Phily]

Hi Kenneth

On Thursday 23 August 2012 16:55:46 Kenneth Lundin wrote:
> The task to check whether a data packet in this case encoded as PER or BER
> is complete should be done on a higher level instead of
> cluttering all the code with these checks. I think that this is already
> done in most implementations of protocols. What else would you do? Take a
> chance and
> try to decode and try again if you get error, incomplete? I don't think so.
> 
> I think it is always possible to check that you have got the whole PDU
> before starting to decode the data. Then the decoding routines can just
> assume
> that you have all the data.

That's a very reasonable assumption, and I a sure that it is the correct one 
in most cases. But not in our case (call us special :p).

* Firstly, the protocol is already fully spec'ed and implemented (erlang and
  embedded C), and delivered on thousands of devices (soon increasing by an
  orders of magnitude or two). So there is no changing the protocol now by
  adding a byte size before every asn1 packet.
* The reason why this protocol doesn't encapsulate asn1 packets is (appart
  from aestetics) a simple one of mobile data consumption scroogery. A large
  percentage of the packets are fairly small (2-10 bytes), and when you stuff
  many of those inside one tcp or udp packet, the overhead becomes important.
  You don't want to declare the size for multiple packets either, because that
  would delay treating the 5-bytes payload when there is a 2Mb payload right
  behind it.
* Another hint that using the asn1 library to determine the size of the packet
  is a reasonable thing to do is that the functionality exists already in the
  form of the undec_rest option. If you know the size of your packet ahead of
  time, this option is of limited use.

So much for the "this functionality is usefull" argument.

> I am not even sure that it is possible to determine in all places if a
> badmatch is because of incomplete data or faulty data.

We've done our best to catch all cases, anything we've missed is a bug. 
There's no point in worring about the "faulty data mistakenly interpreted as 
incomplete data" case because as soon as you've let faulty data in, you've got 
a bigger problem on your hands than an "incomplete packet" false-positive.

> Another note is that the module asn1rt_ber_bin will soon be obsoleted and
> asn1rt_ber_bin_v2 will be the default. In that module it is possible to do
> a generic check
> for incomplete, and there are also NIF's involved which can get out of data
> and should the return incomplete.
> But you could not know that asn1rt_ber_bin will be obsoleted soon.

Good to hear, the many code paths of the current lib is a maintenace burden. 
We'll be happy to adapt our patch to a leaner codebase, even if there are NIFs 
involved :)

> Even if I am not convinced of the need of this check I might accept it if
> it has no negative impact on performance and does not increase the size of
> runtime modules and generated code significantly, and if it really is safe
> to tell that it failed because of incomplete data.

Thanks :) And I completely agree with the requirements.



Cheers.

-- 
Vincent de Phily
Mobile Devices
+33 (0) 142 119 325
+353 (0) 85 710 6320 

Warning
This message (and any associated files) is intended only for the use of its
intended recipient and may contain information that is confidential, subject
to copyright or constitutes a trade secret. If you are not the intended
recipient you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message, is
strictly prohibited. If you have received this message in error, please
notify us immediately by replying to the message and deleting it from your
computer. Any views or opinions presented are solely those of the author
vincent.dephily@REDACTED and do not necessarily represent those of 
the
company. Although the company has taken reasonable precautions to ensure no
viruses are present in this email, the company cannot accept responsibility
for any loss or damage arising from the use of this email or attachments.