[Apache Directory Project Wiki] New: Asn1Home

[di...@incubator.apache.org]

   Date: 2005-02-03T16:48:02
   Editor: EmmanuelLecharny
   Wiki: Apache Directory Project Wiki
   Page: Asn1Home
   URL: http://wiki.apache.org/directory/Asn1Home

   no comment

New Page:

##language:en
== ASN.1 encoder/decoder ==
This page is just a blackboard, to throw ideas. They may be duplication of other pieces of documentation.

== Components ==

Communications between clients and server can be seen as a two ways / multi ''layers'' system. The client submit a request to the server, which reply.

''Layers'' are just used to facilitate the implementation of this communication. From the developper point of view, working on a specific level, he just has to know the two layers above and under.

{{{

   CLIENTS        SERVERS

    STUBS <......> STUBS
     | ^            | ^
     V |            | |
   Tuples <......> Tuples
     | ^            | ^
     V |            | |
    TLVs <........> TLVs
     | ^            | ^
     V |            | |
   Buffers <....> Buffers
     | ^            | ^
     V |            | |
     IO <.........> IO
     | ^            | ^
     | |            | |
     | +------------+ |
     +----------------+
}}}

It allows many differents implementations, as of :
 * smart stubs, that are able to generate directs IO;
 * dumb stubs, that communicate with dumb Tuples, ...;
 * semi-smart Stubs, that communicate with TLVs, avoiding the Tuples layer
 * pre-built elements for standards queries or replies (errors, ...)
 * semi-built elements that just need a single modification (Message Id, ...)

One can also imagine inter-layers used to trace debug informations.

Debugging is easier : you can analyze the upper level, then the lower one, and so on.

Inter layer communication rely on a pipe-line : each layer push some piece of information to the net layer (up or down), which will do the same.

Each layer may implement its own strategy to fullfill the reception and transmission of this data :
 * emission
  * asynchronous push
  * synchronous push
  * established and dedicated channel
  * multiplexed channel
 * reception
  * listener
  * established and dedicated channel
  * multiplexed channel



=== Stubs ===
'''Stubs''' are Java classes that contain high level infomations.

A client create an ''instance'' of a stub to communicate with the server, which create an other one to reply. They implement a kind of ''application layer'' between clients and server.


Idealy, they are generated by an '''ASN.1''' compiler, but can be hand crafted.

=== Tuples ===

=== TLVs ===

=== Buffers ===

=== IO ===

== Processing ==

=== Encoder ===

=== Decoder ===

== Bottlenecks ==

=== Performance ===
TODO : performance against memory/scalability/failover
TODO : which kind of performance shoul we deliver? Maximum throughput = bandwith/average PDU size. For instance, with a 1Gb network connection, assuming that we have an average PDU size of 100 bytes, the system should deliver 1 M Pdu/s, not to mention TCP/IP overloading (typically, a TCP/IP packet size is 1500 bytes, so the previous number is to be divided by 15 : 66 000 PDU/s)

So, ideally, treating a PDU in 15 ns might be enough.

=== Memory consumption ===

Memory is limited by the '''JVM''' parametrization. the '''CODEC''' system should never cause a memory allocation. Clients side is not a problem, but server side is. We '''must''' build a mechanism that works with a determinated amount of memory. In case of memory lack, the system '''may''' discards some entering requests, or discard greedy requests, or flush to the disk those greedy request for a post-poned treatment.

This mechanism '''should''' be ligh, to obtain an acceptable level of performance.

A possible mechanism could be to allocate some instances, and associates them to a thread, which will be in charge of the codec processing.

A server will contains a limied number of codec threads, each one with its codec instances pool (no synchronisation)

A global pool of instance could be allocated on initialization, depending on the global memory. each thread will ask for an instance and will keep it in its own pool.

{{{
instances
 ^X
 |
 | X
 |
 |  X
 |
 |   X                                  2
 |                       2
 |     X       2                      1
 |         2       1
 |      2 X1
 |    12      X
 |  12               X
 | 12                               X
 |12
 +----------------------------------------> time

 X : instance in the global pool
 1 : instance in the thread-1 pool
 2 : instance in the thread-2 pool
 ...
}}}

=== Network consumption ===