[Coco] OT: new territitory for me

[Aaron Wolfe]

When writing a program to work with the new DW server, TCP/IP
connections are presented to your program as a serial port, and data
is sent and read using exactly the same calls as a terminal program or
BBS would use.  There are some special commands that can be sent over
this port that cause DW to make an IP connection  Not too different
from talking to a modem and telling it to dial, in fact if you want to
use existing telecom software, DW includes a Hayes compatible mode
where you can 'dial' internet addresses using ATD.

Using these virtual ports is actually much easier than writing
software for a real serial port, because there are no baud rate or
parity settings to worry about, and no flow control in necessary.  The
DW server has an effectively infinite buffer for both incoming and
outgoing data.  All your program has to do is read and write to the
port when it wants to do so.

There are a number of tried and true strategies for dealing with
incoming data that can happen at unpredictable times (keyboard input,
an IRC message from the server).  The simplest is called polling.  In
a program that is dealing with a small, fixed number of potential
inputs, this is probably the best technique to use.

To use a polling design, you must find some may to determine whether
or not an input source has data ready for you.  Your program has a
small loop that checks all possible inputs for data, and hopefully
sleeps for a while to avoid what's called "busy waiting", basically
wasting lots of CPU waiting for something to happen.

You can check whether the virtual port has data waiting for you with
the os9 system call GETSTAT and the argument SS.Ready.  It will return
E$NotRdy if there is nothing, or set the calling routine's B register
to the number of bytes available if there is data waiting in the
buffer.  I don't know how you access this from basic09, but I'm sure
it's possible.   There should be a way to check for a keystroke in a
similar manner, I am not familiar enough with OS-9 to tell you how
though.

The key is that you never do a READ unless you already know there is
data ready to be read.  This avoids "blocking", your program won't
grind to a halt waiting on input from one stream while missing input
from the other.

In this strategy you must also read and process input very quickly.
While you are handling input from the virtual port, you aren't reading
keystrokes.  They'll be buffered and waiting for you when you get
there to read them, but you need to be quick about it so that the user
has a good experience.  I've found in testing the DW routines that
100ms is pretty acceptable for a response to a keystroke.  Coco can do
a lot in 100ms, but keep that in mind when writing code that handles
input.

In a polling design, any processing that going to take more time than
is acceptable must be started in a separate process so that the
polling loop can continue handling input.  chances are this won't be
an issue in an IRC client.

Hope that helps,
-Aaron




On Fri, Jan 1, 2010 at 1:27 AM, Wayne Campbell <asa.rand at gmail.com> wrote:
> One of the things that I have not understood in the past, and am not sure I understand even now, is network communications. I've never actually tried to write a terminal, or bbs, or message-board, or a server or client of any kind before. I know how to parse text-based messages, which is what the internet is based on, and which irc is based on, but knowing how to handle the incoming and outgoing data streams has been elusive. In trying to do something with it, I am finding myself remembering another thing I have never really understood, event-driven programming, as opposed to procedural, which is what I am most familiar with.
>
> I find myself looking at the streaming issue, and seeing where I need to be able to handle things in a similar manner to the event-driven style. Because I have to constantly read and process the incoming stream, while at the same time processing the messages being typed by the user. In addition, I have to manage the output so that each thing appears in the appropriate place on the screen, or is held in the right table for access as a sub-menu. I really don't understand how this is done, even though I did learn something about it when I had my old Mac Quadra 605. I do know that, if I don't do it right, the interface will be slow and kludgy.
>
> Parsing character streams usig strings, and building message strings, is easy in comparison. I may have questions, as I go. Aaron Wolfe is a great help, and has already given me a few clues to build on. I am working on them now, to see if I can produce something that will communicate with a irc server.
>
> Wayne
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>