RLM Internet Activation Interface
Posted by Yi in Uncategorized on April 23rd, 2012
RLM Internet Activation allows us to deliver a pre-generated activation key to our customers, and when they are ready to use our product, a transaction with the activation server running at http://www.obj-sys.com site allows the license to be fulfilled without manual intervention.
In the case of a node-locked product, a typical scenario would be that our customer runs the product on the desired machine, and if the license had not been fulfilled earlier, the product asks for an activation key. Once the activation key is supplied, the license is retrieved transparently and saved in the directory where the application executable resides. From this point on, the product runs with its license in place.
Sometimes the internet activation is not completed successfully. If there is a proxy server in the environment that ASN1C or ASN1VE is unaware of, the customer may see an error message, such as
Read error from network (-105) or
Activation server version too old (-145)
To help with our customers activating a license via internet, we create a web activation interface at
http://www.obj-sys.com/rlm_activation.php.
The user enters the license key and host ID to get a license. The host ID is the MAC address or physical address, for example 0019d1e7802f . The license will be generated and displayed in the web page. It should be saved into a license file with an extension .lic and copied to the bin/ subdirectory of the ASN1C or ASN1VE installation.
Time-Limited Licensing Option in ASN1VE
Posted by Yi in Uncategorized on April 9th, 2012
We have observed that a number of users have a need to use ASN1VE for a certain project and then no need for its use after that. For this reason, we have introduced a new licensing option: time-limited license.
We provide 4 kinds of time-limited licensing in ASN1VE at a lower price than the permanent ASN1VE license. Those are :
- Node-locked 3-month license
- Node-locked 6-month license
- node-locked 12-month license
- 10-user unrestricted (anyhost) 12-month license
The Node-locked license can only be installed on one system, and the 10-user unrestricted license can be installed on any host (up to 10 systems).
A time-limited license is good for a project for a relatively short period of time. Support is included for the licensed time period. License can be renewed at full current price upon expiration. If you provide credit card information, you an choose to automatically renew your license at expiration.
64-bit Windows Kits in ASN1C 6.5.1
Posted by Doug in Uncategorized on March 8th, 2012
With ASN1C 6.5.1 separate 64-bit kits for Windows will be available. For a while versions of ASN1C prior to 6.5.0 have included 64-bit libraries for Visual Studio 2005, Visual Studio 2008, and Visual Studio 2010. The 64-bit Windows software development kits for ASN1C 6.5.1 include these libraries also, but they also include a 64-bit version of the ASN1C compiler itself, which is something that wasn’t offered before.
If you’re familiar with the folder hierarchy of an ASN1C Windows installation prior to version 6.5.0, you’ve probably seen folders with names like c_vs2005_amd64, cpp_vs2008_amd64, c_vs2010_amd64, etc. In the 6.5.0 installation those amd64 folders aren’t present. That’s because 6.5.0 kits are 32-bit kits, and starting with 6.5.1 you can get either 32-bit ASN1C kits or 64-bit ASN1C kits.
The 32-bit kits will have folder hierarchies named c, cpp, c_vs2005, cpp_vs2005, c_vs2010, and cpp_vs2010 (among others). All of these hierarchies contain 32-bit libraries and DLLs. The c and cpp hierarchies contain Visual Studio 2008 libraries and DLLs starting with 6.5.0.
The 64-bit kits will have folder hierarchies named c_64, cpp_64, c_vs2005_64, cpp_vs2005_64, c_vs2010_64, and cpp_vs2010_64. The amd designation is gone. All of these hierarchies contain 64-bit libraries and DLLs.
Anyone who has a Windows ASN1C license and has active support can get a 64-bit run-time kit. So customers with active support who have Windows versions of ASN1C prior to 6.5.0 that have both 32-bit and 64-bit libraries can still have both sets of libraries when they move to 6.5.1.
Introducing EXTENDED-XER
EXTENDED-XER (specified in X.693) allows you to vary the XML encoding of ASN.1 by using XER encoding instructions. For some time, ASN1C has supported EXTENDED-XER indirectly by allowing you to directly compile XSD. When compiling XSD, ASN1C does an implicit transformation to ASN.1 with XER encoding instructions, as specified in X.694. As of version 6.5.1, we now partially support EXTENDED-XER when compiling ASN.1 having XER encoding instructions.
If your ASN.1 contains XER encoding instructions, ASN1C will automatically generate code for EXTENDED-XER instead of BASIC-XER. This is true whether you use -xer or -xml on the command line. If, however, any unsupported encoding instructions are found, ASN1C will ignore all XER encoding instructions, since it would not be capable of supporting EXTENDED-XER for that specification.
ASN1C currently (as of v6.5.1) supports the ATTRIBUTE and BASE64 instructions. The ATTRIBUTE instruction causes a component of a sequence to be encoded as an XML attribute. The BASE64 instruction causes octet strings to be encoded in a base64 representation, rather than in a hexadecimal representation.
Working with code generated for EXTENDED-XER is essentially the same as working with code for BASIC-XER. The details vary a little here, depending on whether you are working with C, C++, Java, or C#. Refer to our documentation for details on this, and also for a discussion of the limitations to our EXTENDED-XER support (see here for C/C++; here for C#; here for Java)
You can see EXTENDED-XER in action using the Employee EXER sample program, available for C, C++, Java, and C#.
We’d like to hear about how you are using EXTENDED-XER, and what other XER instructions you would really like to see supported. You can post a comment here, or send email to support@obj-sys.com.
Consolidation of XER and XML for C/C++
For some time, ASN1C has supported two XML-based encoding rules and associated runtimes. One of these we have simply called “XER” and the other (perhaps confusingly) “XML”. “XER” stands for XML Encoding Rules, as specified in X.693. What we have called “XML” we might have called (and will call here) OSys-XER, standing for Objective Systems’ XML Encoding Rules, since we basically defined our own variation of XER. The XER decoders used SAX based parsing while the OSys-XER decoders used a proprietary XML pull parser.
As of version 6.5.1, these two approaches have been merged together. We now use the “XML” runtime for both XER and OSys-XER. Also, the generated code now supports both XER and OSys-XER at the same time, using a context flag (OSASN1XER) as a signal (to both the generated code and the runtime layer) to indicate which set of encoding rules should be followed. Thus, you can now choose at runtime which set of encoding rules to use. The differences between the encoding rules are documented here.
An additional advantage of the consolidation is that table constraint support is now available for XER (it was previously available only for OSys-XER). (Note that only the new style of table constraint support is supported: you must use -table-unions and not -tables.)
If need be, the old “XER” style of code can still be generated using -compat 649, but you are strongly encouraged to migrate to the new, consolidated style. The changes required to your code to upgrade should be relatively minimal and some tips for doing this have been included in our documentation, for both encoding and decoding.
As a result of this consolidation, compiling ASN.1 using “-xer” or “-xml” yields essentially the same result. The only difference is that the generated PDU encode/decode functions will set OSASN1XER for you, if you generate code using “-xer”.
Alternatives to Print to String Functions
void (*rtxPrintCallback)
(void* pPrntStrmInfo, const char* fmtspec, va_list arglist);
void writeToStdout(void* pPrntStrmInfo, const char* fmtspec, va_list arglist) {
FILE *fp = (FILE *)pPrntStrmInfo;
vfprintf(fp, fmtspec, arglist);
}
void writeToString(void* pPrntStrmInfo, const char* fmtspec, va_list arglist) {
char *dest = (char *)pPrntStrmInfo, buf[1024];
vsnprintf (buf, sizeof(buf), fmtspec, arglist);
strncat (dest, buf, sizeof(buf));
}
The -strict-size option in ASN1C v6.5
A new option has been introduced in ASN1C v6.5 for C/C++ that allows for the creation of more optimized structures for types containing size constraints. This is mostly true for items of fixed-size, for example OCTET STRING (SIZE (10)).
If this option is not used, the C structure generated is the standard C structure for OCTET STRING containing a numocts and data field:
struct {
OSUINT32 numocts;
OSOCTET data[10]
}
However, one might observe that the numocts field is not necessary in this case, the size should always be 10. In the early days of ASN.1 when only BER encoding existed, it was not uncommon for a user to interpret a constraint such as this as meaning a maximum size of 10 as opposed to a fixed size. This is similar to how one would interpret an array declared in a computer language as having a max size of 10. Hence the need to have a numocts (or other size field) to allow for the case when the field was not strictly interpreted to contain “10 and only 10″ items.
With the advent of PER encoding, this lax interpretation was no longer possible as a size of 10 truly meant 10 only and length in the encoded data would be optimized away to take advantage of this fact. But the way ASN1C did code generation never evolved in the same way up until this release. Now, if -strict-size is added to the command-line, the generated structure will be as follows:
struct {
OSOCTET data[10];
}
The numocts field has been removed completely. A similar optimization has also been done in this case to use the smallest sized integer to hold the size value for a particular range. For example, if SIZE (1..10) is specified on a certain type, the compiler will use an 8-bit unsigned integer (unsigned char in C) as opposed to a standard 32 or 64 bit integer to hold the value.
New PER options in ASN1C v6.5
ASN1C version 6.5 introduces the -perindef and -uper options for PER encoding.
The -perindef option is used to specify that indefinite (fragmented) lengths must be supported in the generated code. Past versions of ASN1C added this support automatically, but it was observed that the performance overhead in supporting these lengths was significant and they were not used very often (PER messages tend to be small in practice). By creating a separate option for their use, the standard case could be supported more efficiently.
The -uper option is used to indicate that only unaligned PER needs to be supported (the -per option allows both aligned and unaligned forms to be supported). This removes generated code checks for alignment which adds efficiency to the unaligned case.
Updated 3GPP/LTE ASN.1 API’s now available
We have updated the 3GPP/LTE ASN.1 API’s we have available for use with ASN1C. These API’s are extended sample programs that contain the complete ASN.1 specifications extracted from the relevant 3GPP standard documents. The API’s are available at the following URL:
http://www.obj-sys.com/lte_3gpp_apis.php
There are now API’s available for 3GPP release 8, 9, and 10 of the different specification types. API’s are currently available for the LTE-RRC, S1AP, andX2AP LTE ASN.1 specifications. Updated API’s will soon be made available for 3G ASN.1 specifications as well such as NBAP and RANAP.
ASN1C 6.5 Preview: The Visual Studio Wizard
One of the new features in the upcoming ASN1C 6.5 release will be a Visual Studio wizard for Windows SDKs. This wizard will allow you to create a Visual Studio 2005 or higher project from the Visual Studio IDE by specifying the .asn or .xsd files for which you want code generated.
The wizard will be invoked from the Visual Studio IDE, and it will run up the ASN1C GUI to allow you to define the project in much the same way that you would use the GUI currently. When you finish using the GUI, it will generate the code and the project file, and the Visual Studio Wizard will load the generated project into your workspace.
The wizard will work for C, C++, and C# projects. In the ASN1C 6.5 distribution there will be a vswizard folder. This folder will contain a README.txt file that describes the steps to take to set up the wizard. Basically the set up involves just editing one file and then copying a few files to the correct place in your Visual Studio installation hierarchy. Once the set up is done, you can invoke the wizard by clicking either Visual C++ or Visual C# in the Visual Studio New Project dialog and then choosing ASN1C as the project template.