From directory-cvs-return-3616-apmail-incubator-directory-cvs-archive=incubator.apache.org@incubator.apache.org Fri Feb 04 00:48:06 2005 Return-Path: Delivered-To: apmail-incubator-directory-cvs-archive@www.apache.org Received: (qmail 69191 invoked from network); 4 Feb 2005 00:48:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Feb 2005 00:48:05 -0000 Received: (qmail 9234 invoked by uid 500); 4 Feb 2005 00:48:05 -0000 Delivered-To: apmail-incubator-directory-cvs-archive@incubator.apache.org Received: (qmail 9193 invoked by uid 500); 4 Feb 2005 00:48:05 -0000 Mailing-List: contact directory-cvs-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: directory-dev@incubator.apache.org Delivered-To: mailing list directory-cvs@incubator.apache.org Received: (qmail 9180 invoked by uid 99); 4 Feb 2005 00:48:04 -0000 X-ASF-Spam-Status: No, hits=-9.8 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from minotaur.apache.org (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.28) with SMTP; Thu, 03 Feb 2005 16:48:03 -0800 Received: (qmail 69139 invoked from network); 4 Feb 2005 00:48:02 -0000 Received: from localhost.hyperreal.org (HELO minotaur.apache.org) (127.0.0.1) by localhost.hyperreal.org with SMTP; 4 Feb 2005 00:48:02 -0000 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_New=3A__Asn1Home?= Date: Fri, 04 Feb 2005 00:48:02 -0000 Message-ID: <20050204004802.69137.20314@minotaur.apache.org> X-Spam-Rating: localhost.hyperreal.org 1.6.2 0/1000/N X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 =3D=3D ASN.1 encoder/decoder =3D=3D This page is just a blackboard, to throw ideas. They may be duplication of = other pieces of documentation. =3D=3D Components =3D=3D 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 communica= tion. From the developper point of view, working on a specific level, he ju= st 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 tra= nsmission of this data : * emission * asynchronous push * synchronous push * established and dedicated channel * multiplexed channel * reception * listener * established and dedicated channel * multiplexed channel =3D=3D=3D Stubs =3D=3D=3D '''Stubs''' are Java classes that contain high level infomations. A client create an ''instance'' of a stub to communicate with the server, w= hich create an other one to reply. They implement a kind of ''application l= ayer'' between clients and server. Idealy, they are generated by an '''ASN.1''' compiler, but can be hand craf= ted. =3D=3D=3D Tuples =3D=3D=3D =3D=3D=3D TLVs =3D=3D=3D =3D=3D=3D Buffers =3D=3D=3D =3D=3D=3D IO =3D=3D=3D =3D=3D Processing =3D=3D =3D=3D=3D Encoder =3D=3D=3D =3D=3D=3D Decoder =3D=3D=3D =3D=3D Bottlenecks =3D=3D =3D=3D=3D Performance =3D=3D=3D TODO : performance against memory/scalability/failover TODO : which kind of performance shoul we deliver? Maximum throughput =3D b= andwith/average PDU size. For instance, with a 1Gb network connection, assu= ming that we have an average PDU size of 100 bytes, the system should deliv= er 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. =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 determina= ted amount of memory. In case of memory lack, the system '''may''' discards= some entering requests, or discard greedy requests, or flush to the disk t= hose greedy request for a post-poned treatment. This mechanism '''should''' be ligh, to obtain an acceptable level of perfo= rmance. A possible mechanism could be to allocate some instances, and associates th= em 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 o= n 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 ... }}} =3D=3D=3D Network consumption =3D=3D=3D