directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Apache Directory Project Wiki] Updated: TLVPageInfo
Date Thu, 17 Feb 2005 00:49:43 GMT
   Date: 2005-02-16T16:49:42
   Editor: EmmanuelLecharny
   Wiki: Apache Directory Project Wiki
   Page: 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 :
-We also have two '''TLVs''' with a zero '''Length'''. It's ok as we don't have any '''Value'''
 ==== Value ====

View raw message