schmidtd wrote:
On Apr 10, 7:08 am, "Steven N. Hirsch" <shir...@adelphia.net> wrote:schmidtd wrote: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.This is basically how the TCP 'SACK' mechanism works, if I understand your proposal.Yes, you're right - RFCs 1072 and 2018. My concern is that it introduces a lot of complexity, and may represent a code fork between serial and ethernet.
Why complex? Presumeably the sending side knows the start and length of each block, so that they can be easily re-sent in ascending order. The receiving side would have no trouble "filling in" the buffer as the blocks are sent, right? Again all the lengths are now known.
Something I'm more interested in right now is seeing Deckard's fast- read code for floppies (http://boutillon.free.fr/Underground/Docs/ Fastdsk/Fastdsk_en.html). Reading can be pretty slow compared to transmission time. One bottleneck at a time...
The fast read routine from Locksmith (which reads 256-byte sectors, but with the bits moved around to allow on-the-fly denibblizing, is in this post from Paul Guertin: >http://groups.google.com/group/comp.emulators.apple2/msg/fe3909783963507d?dmode=source&hl=en I'd also like to see the routine that denibblizes on the fly and decodes into the actual sector contents. -michael NadaNet networking for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."