Re: ADTPro beta - protocol change

["BLuRry" <brendan.robert@gmail.com>]

On Apr 2, 1:35 pm, "schmidtd" <schmi...@my-deja.com> wrote:
> On Apr 2, 1:37 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:> Because this changes the protocol, could I suggest another?
>
> > Since, once communication is established, it tends to be pretty
> > solid, and since missing packets can now be detected by block
> > number discontinuity, how about replacing ACKs of correctly received
> > blocks with NAKs of missing or incorrectly received blocks?
>
> > This would reduce the reverse traffic to practically nil without
> > damaging reliability.
>
> Glenn Jones and I have talked about a similar change where the server
> blasts a buffer-full of blocks, then the client sends back a bitmap of
> blocks it still needs to complete the buffer.
>
> The current state of affairs uses the return trip as a pacing
> mechanism.  The client uncompresses and checksums each block after it
> receives it, then sends the reply when it's ready for the next one.
> So there's a bunch of processing that happens in between - and would
> get overrun without that pacing.
>
> We can't keep the current processing model and just change the
> protocol; it would require a fairly big processing change to defer the
> decompression and feedback.  Another thing to watch out for: a 256-
> byte half-block can actually expand by another 50% or so in the worst
> case with RLE encoding, so we have not-quite-deterministic space
> available in the buffer when staging the received data.

Hmm... very tricky.  As for the ACK problems, I was able to avoid that
slightly with apple game server by just keeping the checksum avail in
memory on the apple at all times.  The AGS process is:

1) The server sends a command telling the apple it is about to send x
number of bytes to be stored at a specified base address

2) The apple clears its stored checksum and waits for x bytes to be
received

3) The server, after sending the data, asks the apple to acknowledge
it is no longer waiting for data and is ready for more commands.  If
this does not produce a response, it sends the ACK request several
more times (this is in case a byte got lost along the way)

4) Once the apple sends its ACK, the server then sends a command
requesting the last checksum.  The apple sends its checksum.  If the
apple checksum is not correct, the server starts over at the same
start address with a block half the size.  If that block is correct
then the next block is then sent as a full-size block

5) After each correct block, the server then repeats step 1 for the
next block, etc

6) Upon the final block, the server sends a command to the apple
telling it to do a JMP to a specific address.  This concludes the
transfer and the program is started on the apple.

So, really, the main logic and error handling is server-side.  The
apple's program is a very simple command-driven affair.  In this
manner, if I wanted to add support for disk operations, I could send a
chunk of program data containing disk logic to a specific location in
memory.  Then if I wanted to call that routine, I could tell the
driver to perform a JSR to that memory location.  I'll know it is done
when the apple responds to ACK requests again.

This design allows the primary apple program to be < 256 bytes (hence,
fits on a disk boot sector or in slot rom) while still being flexible
to support other needs.  It does require the server to manage the
overall application state, treating the apple almost as a dummy
terminal.  But, in an odd way, it gives you some rudimentary control
over the apple from a high-level language!  (you can store values
anywhere in memory, load additional programming, and change the PC to
anything -- so by extension you can load status messages into the
display ram and so on)

If you find it at all useful, you're welcome to repurpose it to suit
your needs by all means!  :-)

-B