buffering strategies on reading from Socket

[Richard O. Hammer]

I am trying to write code which will consolidate and simplify the 
classes which SMTPHandler uses to read from the InputStream which it 
gets from a Socket.  The code we are using now employs buffer after 
buffer, and I suspect that this redundant buffering may be unnecessary 
(although perhaps not overly costly in terms of performance).  I write 
to ask whether others agree with me on this point.

In James 2.1.3, the method SMTPHandler.handleConnection(Socket) sets 
the variable InputStream "in" like this:
    in = new BufferedInputStream(socket.getInputStream());

So "in" is buffered.  Next "in" is used to construct a command line 
Reader which is itself a BufferedReader.

Although I do not know all that is involved here, I propose that the 
second buffer does not help us any, and I hope to hear a correction if 
someone on this list knows a reason why the second buffer does in fact 
have some value.

If this double buffering is a mistake, I have participated in it too, 
since the class CRLFTerminatedLineReader (which I submitted a few 
weeks ago) extends BufferedReader.  At the time I assumed it was a 
good idea.

Going deeper, if anybody knows or cares, I wonder if even the first 
buffer does us enough good, in the context where we use it, to justify 
its cost in performance.  I guess that the socket InputStream is 
reading out of a TCP packet, and I believe that the underlying TCP 
would not give us access to start reading until an entire packet had 
arrived over the net.  So the packet is itself a buffer sitting in 
memory, and additional buffers on top of TCP's normal behavior may 
only slow things down.  But I am really just making stuff up now.  I 
do not know for sure, and I would like to hear the reactions of any on 
this list who know better.

Thank you,
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]