Date: 2005-02-16T16:49:42 Editor: EmmanuelLecharny Wiki: Apache Directory Project Wiki Page: TLVPageInfo URL: http://wiki.apache.org/directory/TLVPageInfo
no comment Change Log: ------------------------------------------------------------------------------ @@ -41,11 +41,31 @@ So it leads to the third solution : calling the unique decoder with a container. It's quite easy to implement. ==== Length ==== -The '''Length''' value is 0x0C, which is 12 is base 10. If you count the bytes after this '''Length''', you can easily see that there are 12 bytes. Ok, so '''Length''' means the number of bytes that contains the '''TLV'''. You can check for other '''Length''' that it matches. Good ! -So, for each encapsulating '''TLV''', we have the relation : '''Length''' = sum(included '''TLV''' bytes) +'''Length''' gives the number of bytes of the '''Value''', and nothing else. So the total length of a '''TLV''' will be : + +''TLV length = Tag length + Length length + Value length'', where ''Value length'' is stored in the '''Length''' element. + +The '''Length''' may be 0, which means that there is no value following. + +How is length encoded? A '''Value''' may be from 0 to N bytes long, with N < (256 ^ 126) - 1. This limit is purely hypothetic, of course. If we have to deal with huge objects like pictures or movies, their length will not exceed a few MBytes or a few GBytes. Just keep in mind that they will use the network bandwith for seconds or minutes while being transferred, so longer values could produce a total network exhaustion. + +Typically, we will find five kind of '''Values''' length : + * zero length values; + * some of those '''Values''' have a length which is less than 128 bytes long; + * other could have a length between 128 and 256 ^ 4 bytes long (an ''int'' will be able to hold 4 bytes); + * values above this 256 ^ 4 bytes long + * and values which length is not defined by the '''Length''' element. + +The last type of '''Length''' could occurs if the sender does not know the length of the value while it is sending it. '''LDAP''' protocol does not allow those kind of values, which are dangerous because you need to read the full '''Value''' to know its length (you are not anymore able to implements strategy that discard any '''Length''' above a certain number, for instance) + +The fourth type could also be ignored (4 GBytes is quite a huge size for an LDAP element ...), so we can decide that we won't accept those Values. It seems reasonable. + +What about the decoding? We can also represent the decoding as a finite state automaton : + +attachment:LengthStateAutomaton.png + -We also have two '''TLVs''' with a zero '''Length'''. It's ok as we don't have any '''Value''' following. ==== Value ====
