From directory-dev-return-3583-apmail-incubator-directory-dev-archive=incubator.apache.org@incubator.apache.org Wed Jan 05 18:07:00 2005 Return-Path: Delivered-To: apmail-incubator-directory-dev-archive@www.apache.org Received: (qmail 73017 invoked from network); 5 Jan 2005 18:06:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 5 Jan 2005 18:06:58 -0000 Received: (qmail 37678 invoked by uid 500); 5 Jan 2005 18:05:39 -0000 Delivered-To: apmail-incubator-directory-dev-archive@incubator.apache.org Received: (qmail 37630 invoked by uid 500); 5 Jan 2005 18:05:38 -0000 Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list directory-dev@incubator.apache.org Received: (qmail 37578 invoked by uid 99); 5 Jan 2005 18:05:37 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mail.contentconnections.com (HELO contentconnections.com) (65.39.65.22) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 05 Jan 2005 10:05:24 -0800 Received: from [216.185.189.146] (HELO [10.10.10.109]) by contentconnections.com (Stalker SMTP Server 1.8b9d14) with ESMTP id S.0001722461 for ; Wed, 05 Jan 2005 10:08:41 -0700 Message-ID: <41DC1E0B.40604@thewallacepack.net> Date: Wed, 05 Jan 2005 10:04:11 -0700 From: Richard Wallace User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [asn1] Stateful Decoder question. References: <46aeb24f05010420365c4be771@mail.gmail.com> <41DC12CB.7010502@thewallacepack.net> In-Reply-To: <41DC12CB.7010502@thewallacepack.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Richard Wallace wrote: > I think this will work well, the only part I don't like is having to > iterate over the data looking for a . I just seems too > inefficient, because then I'm basically doing two passes over the data > the client sends me (once here and then again in the command parser). > But, I can't always trust the only a single command will be in the > ByteBuffer, so I don't really have a choice. > > I think something similar will work for you're case. If you (or anyone > else) can offer a better solution, I'm more than open to it (I'd be in > your debt ;). > Duh! I think I have a better solution now. Basically, the decoder will check it's state (SMTP really has two primary states, receiving commands and receiving message data). If it's receiving commands, pass the buffer to the command parser and let it look for the command and the and stuff. I'd have to provide a call back to the command parser so that it can notify the decoder when it has a command object to pass along (or should I implement this stuff in the decode() method I wonder? SMTP is simple enough I could probably get away with that) so that the decoder can change it's state accordingly and call the decodeOccurred() callback. That should work well enough and should have less overhead than the way I do things now. The only problem I still have that I don't like is that I need to look for a sentinel when in data receiving state (the client is sending the message) since SMTP doesn't specify the length of the data being sent. I don't think I can get away with needing to scan that for the sentinel, unless I just assume the client won't send anything after the data until it receives an OK or other message from the server, that would make it much easier cause then I only have to check the last two characters of the data that I receive. I'll have to look into that. Rich