directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [Apache Directory Project Wiki] Updated: Asn1Home
Date Tue, 15 Feb 2005 18:36:25 GMT
   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 / 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.
+''Layers'' are just used to facilitate the implementation of this communication. From the
developer point of view, working on a specific level, he just 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 transmission of this
data :
+Each layer may implement its own strategy to fulfill the reception and transmission 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 crafted.
+Ideally, they are generated by an '''ASN.1''' compiler, but can be hand crafted.
 
 === Tuples ===
 
@@ -83,19 +83,19 @@
 
 === 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)
+TODO : which kind of performance should 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.
+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 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.
+This mechanism '''should''' be light, 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 server will contains a limited 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.
 

Mime
View raw message