On Sat, Apr 5, 2008 at 8:04 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > > On Sat, Apr 5, 2008 at 11:19 AM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote:
<snip> > > #6 uses Buffered streams for IO. > > 6A the buffer size is hard coded. this is ok or does it need to be > > configurable? > > I think the default would have been ok here (which is 512 for Sun Java > 1.4). The advantage of letting the JDK implementation decide is that > future machines (under newer JDKs) might be better off with other > buffer sizes. > The choice people make is probably to achieve that they optimize IP > packets going over the wire. > Don't know if this can be effectively controlled with the buffer size > since the underlying system layers might make their own decisions. > But all this is speculation. yes: better to use the default size if there's a demand for another buffer size then let the user specify it in the configuration > > 6B performance wise, many implementations read character by > > character. > > "performance wise" in this context means "to degrade performance", right? :-) not necessarily: some protocols require octet based decision trees so you pretty much have to read byte-by-byte > > IIRC Andrew C. Oliver posted about that reading or writing > > bytewise from a buffered source is an anti-pattern. can anyone > > explain? is buffering the right choice? do implementations need to > > fill buffers? > > doing bytewise IO on an _un_buffered stream is the anti-pattern. so I > think buffering is the way to go here. it's the reading from and writing to the buffers i meant. andrew opined that byte-wise reading from and writing to a buffered input stream is an anti-pattern. > > #8 each protocol needs to decide whether to use character or bytewise > > streams. so, i think that either in+outs, or out+inReader will be used > > but not both. would it be better to split off subclasses or would this > > be overengineering? > > but you could wrap any stream with a reader, couldn't you (via > InputStreamReader)? so you could see the stream as the low level > choice and the reader as the higher level choice. i'm not disagreeing about the utility it's just that having all four accessible from protected methods seems inefficent and potentially a source of hard to track down bugs with encoding in odd error cases... > > #9 these fields only seem to be used when logging exceptions. reverse > > DNS lookups have a tendency to be expensive and will often not produce > > any useful information. this cost is paid every time that a connection > > is started. is this worthwhile? > > AFAIK, dnsServer uses a cache - but the question remains valid. > probably, in the end, it is worthwhile - even indespensible - in > certain failure situations. ;-) even if they are, would it be better to look them up only when needed? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
