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.
