directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <>
Subject Re: [asn1] Stateful Decoder question.
Date Wed, 05 Jan 2005 17:04:11 GMT
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 <CRLF>.  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 
<CRLF> 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 <CRLF> 
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.


View raw message