[MUD-Dev] Modular Design Issues RFC

[Kwon Ekstrom]

----- Original Message -----
From: "Ryan Rhodes" <ryanshaerhodes at hotmail.com>

> Kwon Ekstrom wrote:

> Say I wanted to protect link dead players from entering combat, but
> I wanted to make it so if you drop link while already in combat then
> you don't get the protection.  Now say Joe Blow loses link in the
> trapped after the attack he won't get protection, even though you
> lost link before entering combat.

I suppose that could pose a minor problem in some systems.  What I'm
writing generates the victim's fighting data after they are hit, so it
would be possible to check for the disconnect after the first hit
during the constructor.

> method do the majority of servers use for catching link death, input
> or output?

I imagine most servers use a little of both... in Java, all of the
read methods block the thread, so you can only use that if you wanted
a thread for io for each user logged in... that imho isn't worth it's
own thread.

> When you say a non-blocking system, are you refering to input or
> output.  This is a big question I've been having in general.  I have
> been under the impression that all output was immediate
> (non-blocking)

Output is non-blocking in the sense that it always returns in a short
amount of time, what I'm talking about by non-blocking is the fact
that I check for data in the input stream before pulling from it.  The
read methods in java will block the thread until the stream receives
enough data for it to return.

> Also, you say the PrintWriter adds extra overhead, but theres a
> slight bit of extra overhead in doing that conversion to a byte
> array and appending the newline you did above.  In essense, this is
> being done for you by the PrintWriter, but I assumed it would be
> faster to use the precoded PrintWriter than to basically code this
> yourself.  Where is the extra overhead your talking about in
> PrintWriters and PrintStreams coming from?

All IOstreams, Readers, and Writers are synchronized in java, the
extra io comes from checking for locking objects.  The conversion to
binary has to come at some point whether you're using a pre-defined
writer or not.

Here is how the String class handles byte conversions:

  while (i < n) {
      dst[j++] = (byte)val[i++];
  }

It's simply retyping each value in the char array as a byte.
PrintWriter it seems, after checking for synchonization eventually
calls the write(byte[] b, int off, int len) method of the output
stream.

  public void print(String s)
  public void write(String s)
  public void write(String s, int off, int len)

Here it passes the String up to it's parent class, Writer, the code
reads as follows:

  public void write(String str, int off, int len) throws IOException {
    synchronized (lock) {
        char cbuf[];
        if (len <= writeBufferSize) {
            if (writeBuffer == null) {
                writeBuffer = new char[writeBufferSize];
            }
            cbuf = writeBuffer;
        } else { // Don't permanently allocate very large buffers.
            cbuf = new char[len];
        }
        str.getChars(off, (off + len), cbuf, 0);
        write(cbuf, 0, len);
    }
  }

  write(char buf[], int off, int len)
  out.write(char[] buf, int off, int len)

I didn't see the point of generating a 5 function stack when a single
call to the output stream would do it, a call that was the last
position in the stack afterall.

I don't know about your installation, but my installation of the
jdk1.3 came with a file called src.zip which contained the java files
for all of the java classes.  If you're curious (as I am) of how they
did certain things, take a peek.  I've spent a fair amount of time to
reading through some of these, especially the IO streams... I was
trying to find a way to detect disconnect without blocking.

-- Kwon Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev