Subject: String Elements

From: Evangelos Haleplidis <[email-masked]>
Date: Thu, 8 Dec 2005 14:42:24 +0200

Greetings to the list,

I have a question about the ForCES model that has an impact on the ForCES
Protocol.

In the ForCES Model, there are elements that are Strings.

That is ok for a Model, but for the protocol it poses some difficulties
since a String is of variable length.

For Example:

Let's say we have the following struct:
array1 :
{
name : String - Element ID 1
version : Int - Element ID 2
}

In a FullDataTLV you would have:
T=FullData
L=LengthOf(ValueOfElement1+ValueOfElement2+4)
V=
valueof(ElementID1)
valueof(ElementID2)

The problem here, on the recipient's side, is how do you separate the two
values since the String is not of fixed length!

This problem is solved using SparseDataTLVs, but then why define
FullDataTLVs.

Also there is an encoding problem.

Java(String class) has a different view of Strings than C(array of chars).
How can this be solved?

Regards,

Evangelos Haleplidis.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 8 Dec 2005 09:50:32 -0500

Evangelos,

> L=LengthOf(ValueOfElement1+ValueOfElement2+4)

No, the encoding for fulldata requires you to put any variable length
elements in their own TLVs. So this would be encoded as:

FULLDATA TLV, L = XXXX
      valueof(Elementid1),
      FULLDATA TLV, L = 4+strlen(Elementid2)
             valueof(Elementid2)

> values since the String is not of fixed length!

It is important to notice that all the TLV and ILVs are 32 bit aligned.
It is also important to observe that there is intimate knowledge of the
elements of array 1 at both the sender and receiver.
Using this information, it should be trivial to decode.

> This problem is solved using SparseDataTLVs, but then why define

They are a lot more efficient. We get at least 1.5 more performance
dumping huge IPSEC SADB using FUlldata that using sparsedata and about
2x more if we are delet/adding.
 
> Java(String class) has a different view of Strings than C(array of chars).

You are probably being bitten by the fact you dont do 32 bit alignments.
Check your encoding.

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Thu, 8 Dec 2005 22:58:12 +0800

Evangelos,

I suppose the String type defined by model has been stated as being
Null-terminated, just like normal C dose.  For Java like string type, it may be
matched to byte[N] or octelstring[N], where the length should be included.

Not sure if it is all the model means, and Joel may have more clear answer.

thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 8 Dec 2005 10:50:30 -0500

No, the model does not assume that strings are null terminated.  The model 
explicitly states that strings are associated with a length.
As Jamal explains nicely, all variable length elements (including strings, 
octetstrings, and so forth, must be encoded in a TLV so that we have their 
length available.
Figuring out where to put those lengths was one of the challenges of 
working out the FullData encapsulation.

Yours,
Joel

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 9 Dec 2005 12:44:26 +0800

Joel,

Could you explain then what's the difference between the following two atomic
type definitions and what's the necessary for both in the model?

         string[N]                ASCII null-terminated string with
                                  buffer of N characters (string max
                                  length is N-1)
         string                   ASCII null-terminated string without
                                  length limitation

Thanks,
weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 9 Dec 2005 07:05:19 -0500

Apparently, I had forgotten about the null termination for strings.  Still, 
we always use the length encoding.

The difference between the two is that if a field in an LFB is declared 
string[10], that means that the strings are no longer than 10 
characters.  This can help implementors.  It is assumed that most uses of 
strings will have length limitations.
However, there are some contexts where it makes sense to supported 
unlimited length strings.  To represent that, use "string".

Fields of both types are encoded the same way.

Yours,
Joel