Mailing-List: contact directory-cvs-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: directory-dev@incubator.apache.org
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: directory-cvs@incubator.apache.org
To: directory-cvs@incubator.apache.org
Subject: 
 =?iso-8859-1?q?=5BApache_Directory_Project_Wiki=5D_Updated=3A__Asn1Home?=
Date: Tue, 15 Feb 2005 18:36:25 -0000
Message-ID: <20050215183625.16947.27237@minotaur.apache.org>

   Date: 2005-02-15T10:36:24
   Editor: EmmanuelLecharny
   Wiki: Apache Directory Project Wiki
   Page: Asn1Home
   URL: http://wiki.apache.org/directory/Asn1Home

   no comment

Change Log:

---------------------------------------------------------------------------=
---
@@ -6,7 +6,7 @@
 =

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

-''Layers'' are just used to facilitate the implementation of this communic=
ation. From the developper point of view, working on a specific level, he j=
ust has to know the two layers above and under.
+''Layers'' are just used to facilitate the implementation of this communic=
ation. From the developer point of view, working on a specific level, he ju=
st has to know the two layers above and under.
 =

 {{{
 =

@@ -31,7 +31,7 @@
      +----------------+
 }}}
 =

-It allows many differents implementations, as of :
+It allows many different 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
@@ -44,7 +44,7 @@
 =

 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 tr=
ansmission of this data :
+Each layer may implement its own strategy to fulfill the reception and tra=
nsmission of this data :
  * emission
   * asynchronous push
   * synchronous push
@@ -63,7 +63,7 @@
 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 cra=
fted.
+Ideally, they are generated by an '''ASN.1''' compiler, but can be hand cr=
afted.
 =

 =3D=3D=3D Tuples =3D=3D=3D
 =

@@ -83,19 +83,19 @@
 =

 =3D=3D=3D Performance =3D=3D=3D
 TODO : performance against memory/scalability/failover
-TODO : which kind of performance shoul we deliver? Maximum throughput =3D =
bandwith/average PDU size. For instance, with a 1Gb network connection, ass=
uming that we have an average PDU size of 100 bytes, the system should deli=
ver 1 M Pdu/s, not to mention TCP/IP overloading (typically, a TCP/IP packe=
t size is 1500 bytes, so the previous number is to be divided by 15 : 66 00=
0 PDU/s)
+TODO : which kind of performance should we deliver? Maximum throughput =3D=
 bandwith/average PDU size. For instance, with a 1Gb network connection, as=
suming that we have an average PDU size of 100 bytes, the system should del=
iver 1 M Pdu/s, not to mention TCP/IP overloading (typically, a TCP/IP pack=
et size is 1500 bytes, so the previous number is to be divided by 15 : 66 0=
00 PDU/s)
 =

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

 =3D=3D=3D Memory consumption =3D=3D=3D
 =

-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 determin=
ated amount of memory. In case of memory lack, the system '''may''' discard=
s some entering requests, or discard greedy requests, or flush to the disk =
those greedy request for a post-poned treatment.
+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 fixed am=
ount of memory. In case of memory lack, the system '''may''' discards some =
entering requests, or discard greedy requests, or flush to the disk those g=
reedy request for a post-poned treatment.
 =

-This mechanism '''should''' be ligh, to obtain an acceptable level of perf=
ormance.
+This mechanism '''should''' be light, to obtain an acceptable level of per=
formance.
 =

 A possible mechanism could be to allocate some instances, and associates t=
hem 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 server will contains a limited number of codec threads, each one with it=
s 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.
=20